It's much easier to fight when you don't care about what kind of damage it'll do.

I'm not saying this to defend the Democrats, just to point out that Republicans have a massive natural advantage on this stage. I don't think their success comes as much from competence as it does from being naturally aligned with doing harm.

This is the most sober take in this thread. I was bothered by all these things you mentioned for the first two weeks of using the language. I begrudgingly accepted them for the following two months because I felt the benefits of the language were worth it. Now all of these things feel natural and I don't give them a second thought.

So you are in fact the opposite of this meme.

Did the software industry learn nothing from Y2K? Was it too long ago already for people to remember the mess we made for ourselves?

Saving two characters in a file name is not worth the hell you are leaving in your trail by shoving this nonsense in an obscure corner of production code that people are going to forget about until it's too late.

Or he's a pragmatist who is concerned with both harm reduction and the likely reality that the only takeaway that Democrats will ever have from losing an election to someone right wing is that Democrats need to go even further to the right to win.

If leftists give the impression that nothing will ever be good enough for them then

1. Democrats have no incentive to court the left
2. Democrats have no estimate for how many votes they would even be able to pick up from the left relative to how far left they might try to reach

I personally believe that if the Democrats had taken on a progressive populist anti-genocide platform they would have won the election handsomely, but I am left with no way to empirically prove that to anyone because so many leftists opt out of voting entirely.

I think this is a stopped clock situation.

It'll still be nice to get the "small government" party saying in writing that they support the presidency having unlimited power.

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.

Weird how this notion of "personal responsibility" applies to every person except for those people who choose to intentionally misrepresenting the product by branding it in ways that are misleading. The people running this company aren't responsible for their role in misleading the public, just because the fine print happens to indicate that the product isn't actually what it's marketed as?

Now you'll probably say something to the effect of "I never said that! You're putting words in my mouth!" except what other motivation can you have to jump to the defense of the liar and blame people for being misled, except that you want to put all the responsibility on individuals for being misled and not on the company that is systematically and intentionally misleading them? Maybe you just manage to derive a smug sense of superiority thinking of yourself as someone who is invulnerable to this kind of tactic so blaming the victims lets you feel good about yourself.

Different species may have different ages of brain maturity at which point alcohol won't pose as much of a risk of stunting their mental development. Elves for example settle into adulthood at around 100 years of age.

So a responsible legislature would codify in its laws what the minimum drinking age is for each species based on science's best understanding of their physiology.

Maybe Rust isn’t a good tool for massively concurrent, userspace software.

This conclusion is a very weak one.

The only argument the article successfully makes is that using the raw async/await mechanisms of the Rust language leads to situations where it's tricky to figure out how to structure your code, and that the raw async mechanisms of some other languages don't have that friction.

But why would we only consider the strengths of the pure out-of-the-box Rust language and forget that it has an enormous robust ecosystem of crates? For any given use case there will be suitable frameworks that make async Rust programming both natural and performant. Or if such a framework doesn't exist it is possible to develop one on top of the async mechanisms of the raw language because those mechanisms are so unopionated by design.

My colleagues struggle with async Rust as-is. I did too for quite a while. But that's why I'm developing two different async Rust frameworks for two different software architecture paradigms (one that fits nicely into an ECS and one that fits nicely into a deterministic scheduled worker pool) each of which we have different use cases for. If the Rust async design was more opinionated and imposing (which is what this article is recommending) then I likely wouldn't be able to produce frameworks that are as effective for each of these use cases.. one or the other would have suffered, likely both.

It only took me ~2 weeks of playing with Rust before it became my scripting language of choice over Python (which I had been using casually for ~5 years by that point).

The initial setup for Rust can be whipped up with $ cargo init. You're right that there's more setup boilerplate because of the mandatory Cargo.toml and directory structure, but cargo init will provide all that in a snap.

As for the domain specific boilerplate, I actually find that Rust is better at that than Python in almost all cases. I feel that Rust's clap is much simpler, more reliable, and less boilerplate than Python's argparse. Python might win in cases where there's a very mature domain specific package that you need which isn't available in the Rust ecosystem, but that's becoming rare as crates.io grows.

And then when it comes to the actual "scripting", very often my IDE's intellisense can practically fill in the Rust code for me. One keystroke per word and it knows what function I want, or I can quickly scroll through the recommendations until I find what I'm looking for. Meanwhile with Python I always have to consult docs to find any API that isn't part of the basic standard library. As a result I'll often get the scripting done faster in Rust than in Python.

It does absolutely take some time to reach that point, though. Most programmers will definitely feel significant discomfort with Rust initially, but that's just because you need to deprogram your brain from the bad habits that other languages encourage. There's a tipping point in that deprogramming where all the other languages start to feel uncomfortable because you know it won't let you write as good quality of code as Rust would.