They may not be intrinsically more sacred than anything else, but ads in general are still something to avoid. The difference in reaction when adding a new ad to the web vs the CLI is analogous to dumping trash in an abandoned building vs in the middle of the forest. They're both bad, but the CLI/forest feels worse because it's mostly untouched, whereas the web is already thoroughly infested with ads.
Depending on what syntax constructs are available, it's possible to achieve clarity without the verbosity or "line noise factor." For example, in Rust you could write that same code as:
It's easy to see what the possible outputs are and what is produced in each case. The compiler even checks it to make sure you didn't forget any situations.
The clarity comes at the cost of some verbosity, but there's only 4 lines of functional code (not counting the closing brace) here compared to the article's 10. You'd get around the same number if you added line breaks to make the ternary example more readable.
WSL fails in a lot of use cases due to the NT kernel's poor performance when creating processes, slowness in the translation layer when accessing files, and the like.
It's essentially the reverse case of telling Windows users to "just use Wine" - the emulation isn't perfect and some programs won't work well or at all. In a sense, WSL is worse than Wine in this regard since there's usually a Linux-native alternative if something doesn't work in Wine. If something doesn't work in WSL, you don't have a lot of options.
> WSL fails in a lot of use cases due to the NT kernel's poor performance when creating processes, slowness in the translation layer when accessing files, and the like.
But it's still the NT kernel either way, right? How does having binaries compiled with cygwin or MinGW improve upon what WSL offers here?
It isn't the "NT kernel either way", as you are going through the filesystem translation layer; AFAIK it is implemented as a subsystem, so you are accessing the kernel through an entirely disjoint mechanism.
So like, Microsoft may have fixed this recently, but WSL processes were essentially stuck inside of a filesystem sandbox that uses some inane mechanism to access files via mountpoints that fails to correctly translate the few flags that are supportable by the underlying Windows filesystem, so if you try to do basic things like use WSL's copy of git to manage a git repository stored outside of the WSL sandbox, it just doesn't work correctly.
On the flip side, you also can't run a native Windows process whose binary is sitting inside of the sandbox, as native Windows processes do not have direct access to WSL files. Checking, they seem to have finally added the ability to mount new paths, so that's helpful (if you have network shares or removable media like USB keys, these were previously not accessible via WSL).
The great thing about cygwin and MinGW is that, by and large, it _is_ "just the NT kernel", with nothing more than a userland library sitting between the process and the same kernel interface used by any other Windows application, so tons of stuff "just works" that WSL is having to slowly reimplement.
(FWIW, it could be that Microsoft has fixed some of these filesystem showstoppers since I last tried to seriously use WSL; if so, that's exciting, but it doesn't change the reality of why people are looking at these are very different ways of running programs.)
> In the latest Windows Insider build, the Windows Subsystem for Linux (WSL) now allows you to manually mount Windows drives using the DrvFs file system. Previously, WSL would automatically mount all fixed NTFS drives when you launch Bash, but there was no support for mounting additional storage like removable drives or network locations.
> Now, not only can you manually mount any drives on your system, we've also added support for other file systems such as FAT, as well as mounting network locations. This enables you to access any drive, including removable USB sticks or CDs, and any network location you can reach in Windows all from within WSL.
I don't really like it either, but the "future use for expression-oriented operators" aspect makes it easier to swallow. I'd rather deal with some slightly odd notation that accurately represents what's going on than have a bunch of different syntactic constructs for different postfix operations.
I built a workstation with a Threadripper earlier this year, and I couldn't be happier so far. The single-core performance advantage of Intel parts isn't that big, and you get a ton of cores and PCIe lanes in exchange.
fn leak() {
// Create a 1KiB heap-allocated vector
let b = Box::new(vec![0u8; 1024]);
// Turn it into a raw pointer
let p = Box::into_raw(b);
// Then leak the pointer
}
Obviously that's kind of blatant, but there are more subtle ways to leak memory. Memory leaks aren't considered unsafe, so even though they're undesirable the compiler doesn't guarantee you won't have any.
Reference cycles when using Rc<T> are a big one, but generally it's pretty hard to cause leaks by accident. I've only run into one instance of leaking memory outside of unsafe code, and that was caused by a library issue.
The most obvious ways to leak are calling `Box::leak` which is also a very useful API and `mem::forget` (the latter is mostly useful for working with unsafe code).
Switching distros seems a little drastic given the problem. Why not just fix the AUR package? That'd probably take less time than reconfiguring everything.
You're considering network transmission time, by which cached JS is indeed free, but ignoring parse/JIT time and CPU usage as factors. Processors aren't getting any faster, and all that client-side rendering code has a very real cost in terms of compute-bound work for the user's hardware. Processors aren't getting any faster.
The usual answer I've heard here is to use an SPA, but those have problems of their own. They chew up huge amounts of memory if you use tabs, their UX is worse than if you'd just built normal webpages, you have to deal with making it indexable, and so on.
Honestly, I'd be ecstatic if most pages loaded in two or three network round-trips. A cold request takes maybe 100ms when I'm on a cell connection, but JS-heavy pages I've seen tend to have load times measured in seconds.
At the time, your 3 round trips would have cost about a full second, which is roughly the same as the worst case JITting time for jQuery in those same tests. That worst-case result was on a slow Android 2 device.
Cellular network speeds have gone up, but certainly not as much as mobile processor speeds, so if you re-did those tests today with modern networks and devices, it’s probably a net benefit to pull the jQuery once, then JIT it on each page load, as compared to making even a single extra round-trip per page load.
> Processors aren’t getting any faster.
That’s true on the server side as well.
The article talks about externalized costs, but if you just shift the computing burden to the server, how do you pay for that?
You could load the page with more ads, which eats up the network bandwidth and JIT savings you just bought by moving the processing to the server.
Or, you could charge the users more than you currently do, which is economically little different than shifting the computing burden to the users, implicitly requiring them to buy faster mobile devices and better mobile data plans.
Consider also that the number of bugs created per line of code is roughly constant for each pairing of developer and programming language, so who pays for the costs of the extra bugs you’d expect to find in 2-3x more LOC?
TANSTAAFL.
> JS-heavy pages I've seen tend to have load times measured in seconds.
I doubt you’re comparing apples to apples.
There certainly are many very fat JS-heavy pages on the Internet, but what’s your comparison? If the JS-light alternatives aren’t accomplishing the same ends, then it’s not a fair comparison. You can’t compare, for instance, a web IRC gateway app to Facebook, even though you can use both to transmit plain text to another person.
Not that I’m defending Facebook. I’m just pointing out that they’ve got a wholly different thing going on there than the IRC gateway.
