If you have to work in a language or framework with a lot of arbitrary-seeming features, ugly or opaque translation layers, or a lot of boiler-plate, then I absolutely understand the sentiment.
Programming a system at a low-level from scratch is fun. Getting CSS to look right under a bunch of edge cases - I won't judge that programmer too harshly for consulting the text machine.
This is especially true considering it's these shallow but trivia-dominated tasks which are the least fun and also which LLMs are the most effective at accomplishing.
Why not? The individual grunt knows it is more productive and the managers tolerate a non-zero amount of risk with incompetent or disgruntled workers anyways.
If you have clean access privileges then the productivity gain is worth the risk, a risk that we could argue is marginally higher or barely higher. If the workplace also provides the system then the efficiency in auditing operations makes up for any added risk.
The issue with this model in the most general sense is that it is zero-sum, and at the limit it doesn't provide hardly any security.
I delay the use of updated software by a week, and anyone that doesn't takes the risk. Therefore I, the user of the cooldown, enjoys reduced risk at the expense of everyone not implementing a cooldown.
If everyone simply delays their updates, then there is nobody to suffer an attack which notifies users of the cooldown (in this case, everybody).
The blog post makes the argument that the vendors are incentivized to discover these attacks in this time, but that's an entirely different argument and if that were true, they would already be doing that.
In fact, auditing updates for vulnerabilities is the general solution. The whole appeal of the cooldowns is that you don't have to do that - the cost is that it's a zero-sum game reliant on the suffering of those less wise.
Do I have to put the pieces together for you? What is the relevant skill in programming? Problem solving. It's not aim or timing or hand-eye coordination lmao.
Not every single semantic element in the language needs to be a type.
`for i in 0..<10`
This isn't "magic," it's a loop that initializes a value `i` and checks against it. It's a lot less "magic" than Rust. The iterable types in Odin are slices and arrays - that is hardly arbitrary like you imply.
The type system in Rust is mostly useful for its static guarantees. Using it for type-gymnastics and unnecessary abstractions is ugly and performative.
Tasks in Odin can be accomplished with simplicity.
The C++ misdirection and unbounded type abstractions are simply not appreciated by many.
If you want a language with no special cases that is 100% fully abstract then program in a Turing machine. I'll take the language designed to make computers perform actions over a language having an identity crisis with mathematics research, all else equal. Unless I'm doing math research of course - Haskell can be quite fun!
Ginger Bill is a PhD physicist as well -- not that education confers wisdom -- but I don't bet his design choices are coming from a resentment of math or abstraction.
Absolute generality isn't the boon you think it is.
Implying that correctness necessitates a lack of ergonomics is deeply flawed.
The distinction between correctness and safety is that safety is willing to suffer false positives, in pursuit of correctness. Correctness is just correctness.
Your earlier point that languages exist that are safer than Rust but not less ergonomic is irrelevant - that's the point I made.
One can fail, or artificially make a language less ergonomic and that doesn't mean that fixing that somehow has an effect on the safety tradeoff.
So obviously it is when safety and ergonomics are each already maximized that pushing one or the other results in a tradeoff. It's like saying removing weight from a car isn't a tradeoff because the weight was bricks in the trunk.
Anyways I was holding performance constant in all of this because the underlying assumption of Rust and Zig and Odin and C is that performance will make no sacrifices.
Well it is arguably Rust's worst issue and it has remained it for most of its life.
Are you really going to try and convince people that this is completely incidental and not a result of pursuing its robust static contracts? How pedantic should we about about it?
Let me be more clear: the cognitive overhead is real, and does go away with less constraining languages. If that doesn't disagree with your previous point then I misread it.
And I was making a point even more general than prototyping, though I also wouldn't discount the importance of that either.
Because Zig is a better language across the board.
And that includes safety. You can have a language that doesn't do heavy static-analysis like Rust which still makes safety a lot easier than C/C++.
Memory safety is not even a flaw of C/C++, it's a tradeoff. That being said, even if memory-safety was a 'feature' (rather than a tradeoff, and yes, Rust did a better job minimizing the trade than GC or FP languages), it's not the only feature.
To contradict you: avoiding false positives (programmer is correct, compilation fails anyways) by refactoring code into the second or third best design, is exactly the type of cognitive overhead that deserves to be vindicated when complained about. It can fundamentally changes the design of the entire codebase.
I believe that explains why many game developers, who have a very complex job to do by default, usually see the Rust tradeoff as not worth it. Less optionality in system design compounds the difficulty of an already difficult task.
If The Rust Compiler never produced false positives it should in theory be (ignoring syntactic/semantic flaws) damn-near as ergonomic as anything. Much, much easier said than done.
The issue is the underlying and unfair assumption that is so common in these debates: that the memory-unsafe language we're comparing against Rust is always C/C++, rather than a modern approach like Zig or Odin (which will share many arguments against C/C++).
You can prove to yourself this happens by looking around this thread! The topic is Zig vs. Rust and just look at how many pro-Rust arguments mention C (including yours).
It's a strong argument if we pose C as the opponent, because C can be so un-ergonomic that even Rust with its added constraints competes on that aspect. But compare it to something like Zig or Odin (which has ergonomic and safety features like passing allocators to any and all functions, bounds checking by default, sane slice semantics which preclude the need for pointer arithmetic) and the ergonomics/safety argument isn't so simple.
*Under the assumption that you are maximizing both. I often hear complaints that Rust's semantics actually haven't maximized ergonomics, even factoring in the added difficulty it faces in pursuit of safety.
It's totally possible languages as ergonomic as Rust can be more safe, just because Rust isn't perfect or even has some notable, partially subjective, design flaws.
This is incredibly misleading (technically true maybe) and you know it. Rust has slower compile times for the sake of safety, it's a tradeoff you shouldn't be ashamed of.
I didn't narrowly claim the borrow checker (as opposed to the type system or other static analysis) was the sole focus of the tradeoff.
Programming a system at a low-level from scratch is fun. Getting CSS to look right under a bunch of edge cases - I won't judge that programmer too harshly for consulting the text machine.
This is especially true considering it's these shallow but trivia-dominated tasks which are the least fun and also which LLMs are the most effective at accomplishing.