5C5C5C

joined 2 years ago
[–] 5C5C5C@programming.dev 1 points 1 year ago* (last edited 1 year ago) (1 children)

This has to be the stupidest take on the term "plant based" I've ever heard. I swear, "plant based" is just the "No true Scotsman" of vegans.. anything that a non-meat-consumer does that a vegan doesn't like makes them plant based instead of vegan. It's so asinine and intellectually dishonest.

Vegan people can be assholes too. Assholes will inevitably exist in any demographic that gets sufficiently large. I have known people who identify as vegans who insist that it's preferable for humans to die than for non-human animals to die.

[–] 5C5C5C@programming.dev 1 points 2 years ago* (last edited 2 years ago)

The ideas in the article are great, I'm just a little confused by some aspects of the author's tone where it sounds like there's an assumption that the Rust community isn't interested in expanding the scope of the language to every conceivable use case domain and height.

For the 4 years that I've been paying attention the Rust language is advancing faster than I ever thought a language is able to, but more importantly that advancement has been sound and sensible. So far I haven't seen a language feature make it into Rust stable and thought "Oh no that was a mistake", even as features roll in at an incredible rate.

Compare that to the C++ ecosystem where I feel like almost every new language feature is arriving very slowly while also being poorly executed (not that I think the ISO committee is doing their job badly; I just think it's effectively impossible to make new language features in C++ without gross problems so long as you demand backwards compatibility).

I fully expect everything in this very sensible list to make it into the language at a reasonable pace. I don't object to the "bikeshedding" as much as the author here seems to because I'd appreciate if Rust can avoid painting itself into a corner with bad language design choices the way C++ has. If we're talking about language ergonomics, I'd rather suffer some tedium now while waiting for a feature to be polished than be stuck in a corner forever in the future because a bad decision was made.

One example I can think of is I'm not convinced that his proposal around kwargs for function arguments is a good thing, at least not without some serious thinking. For example should it support the ability to reduce foo(a, b, x: x) to just foo(a, b, x) like what's done for struct construction? If so then the optional arguments start to look too much like positional arguments and the syntax starts to get questionable to me. On the other hand if that simplification isn't supported then that becomes inconsistent with other parts of the language. So this is something that I believe requires a lot of serious thought, and maybe the better answer is to have built-in macros for generating builder structs

That being said, the edition system of Rust could afford us some leeway on not being forever trapped with a bad language design choice, but I don't think we want to rely too much on that.

[–] 5C5C5C@programming.dev 1 points 2 years ago* (last edited 2 years ago)

You're thinking of faculty. This is referring to administrators. If you don't know the difference then you know nothing about how institutes of higher education function.

[–] 5C5C5C@programming.dev -1 points 2 years ago

The only way to fix C++ is if you're willing to break backwards compatibility and invent C++2.0.

But that already exists, and it's called Rust.

[–] 5C5C5C@programming.dev 0 points 2 years ago (2 children)

The post is literally describing existential nihilism, whoops.

view more: ‹ prev next ›