Oof. Looks like this affected some other languages as well - somebody at Microsoft needs to up their documentation game, methinks.
Your friendly local programmer, uni student and *nix addict.
Oof. Looks like this affected some other languages as well - somebody at Microsoft needs to up their documentation game, methinks.
I liked GalaxQL.
Can’t beat Iosevka in my opinion. I use the Term variant for my shell as well.
Well, that’s to be expected - the implementation of map
expects a function that takes ownership of its inputs, so you get a type mismatch.
If you really want to golf things, you can tack your own map_ref
(and friends) onto the Iterator
trait. It’s not very useful - the output can’t reference the input - but it’s possible!
I imagine you could possibly extend this to a combinator that returns a tuple of (Input, ref_map'd output)
to get around that limitation, although I can’t think of any cases where that would actually be useful.
It wouldn’t be as relevant, since passing a function or method instead of a closure is much easier in Rust - you can just name it, while Ruby requires you to use the method
method.
So instead of .map(|res| res.unwrap())
you can do .map(Result::unwrap)
and it’ll Just Work™.
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.
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.)
And for what it’s worth, no I did not RTFA
I thought you had up to this point. I guess that just goes to show how shallow and predictable this AI boosterism is.
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.
OP is definitely a masochist.
Care to clue me in? I spend my time far, far away from the web dev sphere :p
True, but it’s uniquely bad in the JS world. Developers tend to rely on libraries in almost cartoonish excess.
At some point, npm
supply chain attacks are going to stop being news and start being “Tuesday.”
… JS on the backend was a mistake.
Well, there’s just not much reason to switch yet. If it ain’t broke, don’t fix it.
(Well, maybe Copilot training, but I’m sure those dipshits at OpenAI scrape Gitlab too.)
Just use WASM
If only…
I’m pretty sure I can’t even connect to my university’s network without installing a custom certificate.
What brainlet at Google thought this was a good idea?
I’m also a big fan of raw SQL. Most ORMs are fine for CRUD stuff, but the moment you want to start using the “relational” part of the database (which… that’s the whole point) they start to irritate me. They also aren’t free - if you’re lucky, you pay at comptime (Rust’s Diesel) but I think a lot of ORMs do everything at runtime via reflection and the like.
For CRUD stuff, I usually just define some interface(s) that take a query and manually bind/extract struct
fields. This definitely wouldn’t scale, but it’s fine when you only a handful of tables and it keeps the abstraction/performance tradeoff low.
> online gambling
Cry harder