> online gambling

Cry harder

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.

Yeah, the Copilot ad in the source viewer smacks of desperation.

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.)

I’m surprised C is so low. I feel like I need to write 5x more code (compared to C++/Rust) to do the exact same thing.

Here’s my most recent one… from last year, LOL.

Built using Hugo, hosted on some Hetzner server in Virginia. I would have more, but I’m still working on implementing my own site generator.

I’m not a fan of Go from a language design perspective, but it does have plenty of technical merit (cheap coroutines, compiled) compared to using a scripting language for your backend.

Some pointers on other languages:

• Don’t sleep on Java/Kotlin or C# for your backend. They’re good languages with powerful, well-developed ecosystems. Kotlin even compiles to JS!
• TypeScript is saner JS. Highly recommended.
• If your backend is CPU-bound, Rust will let you squeeze out every ounce of performance at the cost of a relatively steep learning curve.

copilot is terrible in general.

I concur. I took the free trial and was not impressed - most of the time the suggestions aren’t any better than LSP autocomplete.

And if I asked it to implement something or let it autocomplete part of (say) an expression, it tends to go tits-up completely. (Which is especially odd considering I use languages with abundant static context - It’s not like JS where the type of a function parameter is “who the fuck knows until runtime.”)

Spend your $10 a month on supporting OSS devs/projects.

Why in God’s name would you use a 6-bit signed integer for anything on a spacecraft? I know space-certified chips are pretty barebones, but surely not that bare bones…

I’d bet five bucks some desperate Haskeller or Rustacean has implemented exactly that. You could also probably use nested functions for GCC C or lambdas in C++ to move everything inline?

Actual unpopular (but not extremist) opinions.

This is why I can never get into microblogging/Twitter-type platforms. Character limits and one-click reposting mean that what little discourse you get is shallow, and ragebait is consistently pushed to the top.

I’m not going to say that Lemmy or (especially) Reddit completely avoid this, but you generally get much more insightful conversation and can opt-in to political communities.

There was a thread on [email protected] recently asking people for their unpopular political opinions, and it actually wasn’t a total shitshow!

I would consider language support essential for “good” sum types. AFAIK, stuff like exhaustive pattern matching can’t be accomplished by a library. Perhaps you could do some cursed stuff with compiler plugins, however.

(There was a library that implemented non-exhaustive pattern matching that eventually morphed into an ISO C++ proposal… so we won’t see it until 2030 at the earliest /hj)

It’s a shame that sum type support is still so lacking in C++. Proper Result types (ala Haskell or Rust) are generally much nicer to deal with, especially in embedded contexts.

As is, there’s only std::expected (which can and will blow up in your face if you forget to check has_value) and std::variant, which I have heard nothing but complaints about.