... Why are you digging up random drama from nearly a year ago?
Also, this guy isn't affiliated with the Rust team AFAIK. And even if he was, this is his crate, not rustc - he can do whatever he wants with it, and you can fork it if you disagree.
I don't know about dangerous, but case-insensitive Unicode comparison is annoying, expensive and probably prone to footguns compared to a simple byte-for-byte equality check.
Obviously, it can be done, but I guess Linux devs don't consider it worthwhile.
(And yes, all modern filesystems support Unicode. Linux stores them as arbitrary bytes, Apple's HFS uses... some special bullshit, and Windows uses UTF-16.)
Unfortunately, it's not that simple. The Remote* extensions rely on the (proprietary) VSCode server, and nobody has managed to hack it to work with e.g. Codium.
Mostly just Visual Studio Code, alongside the usual constellation of Git + assorted language toolchains.
It's plug and play at every level - no need to waste hours fucking around with an Emacs or (Neo)Vim configuration just to get a decent development environment set up.
(And yes, I would use Codium, but the remote containers extension is simply too good.)
Most of them, yes. The reddest stars (like Proxima Centauri) are too cool and dim to be visible to the naked eye, but if you go somewhere with no light pollution and let your eyes adjust you should be able to perceive some differences between stars.
After all, the discipline has always been about more than just learning the ropes of Python and C++. Identifying patterns and piecing them together is its essence.
Ironic, considering LLMs can't fucking do that. All they do is hallucinate the statistically likely answer to your prompt, with some noise thrown in. That works... okay at small scales (but even then, I've seen it produce some hideously unsound C functions) and completely falls apart once you increase the scope.
Short of true AGI, automatically generating huge chunks of your code will never end well. (See this video for a non-AI example. I give it two years tops before we see it happen with GPT.)
Also... not hating on English majors, but the author has no idea what they're talking about and is just regurgitating AI boosterism claims.
This is what we in the business call a "skill issue."
There are ways around it, yes. But none of them are plug-and-play unless you're lucky, and a reliable solution will require a combination of technical ability, stealth and social engineering.
True, but it's uniquely bad in the JS world. Developers tend to rely on libraries in almost cartoonish excess.
The language is shit in general, leading to an endless parade of frameworks and packages designed to paper over the sore spots.
The lack of a well-rounded One True Standard Library™ means lots of trivial functionality needs to come from somewhere.
Micro-dependencies are commonplace, leading to bloated dependency trees. I'd guess this is caused by a combination of both culture and the fact that you often want your JS artifacts to be as lean as possible.
The GNOME text editor or Nano.
I appreciate Vim, but when I just need to inspect something or change a single line, the former are easier.
As for Neovim and Emacs... I don't have eight hours to set aside monthly to keep them configured and working.