mattwilsonn888

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.

Except, and you would know this if you skimmed the article, this headline query is being used sardonically.

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.

As if you can make that judgement for others. Don't do this next time.

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.

It's called simplicity.

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.

Because a primary function of the chair is the same to programming languages: ergonomics.

That is obviously true, otherwise we'd code in assembly and type in UTF-8 byte codes.

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.

I don't use Zig, but I can answer your questions:

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.

I would be interested to read the debates that stems from this point.

I think you are clearly good-faith.

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.

Try and appreciate the humor in what you're replying to without fully discounting the point of it.

We're talking about Zig not C. Same argument will apply to Odin.

These modern approaches are not languages that result in constant memory-safety issues like you imply.

This is true for every language. Logic bugs exist. I'll take good OS process isolation over 'written-in-Rust' though I wouldn't mind both.

That being said, you've missed the point if you can't understand that safety comes at a real cost, not an abstract or 'by any means necessary' cost, but a cost as real as the safety issues.

It's an amazing piece of marketing to corner anyone who dislikes a certain hassle as being mentally deficient - that's what "skill issue" means in this context.

No. It is not an invisible safeguard - it yaps and significantly increases compile time and (a matter of great debate) development effort.

It is a helmet, just accept it. Helmets are useful.

As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound.

"This chair is guaranteed not to collapse out from under you. It might be a little less comfortable and a little heavier, but most athletic people get used to that and don't even notice!"

Let's quote the article:

> I’d say as it currently stands Rust has poor developer ergonomics but produces memory safe software, whereas Zig has good developer ergonomics and allows me to produce memory safe software with a bit of discipline.

The Rust community should be upfront about this tradeoff - it's a universal tradeoff, that is: Safety is less ergonomic. It's true when you ride a skateboard with a helmet on, it's true when you program, it's true for sex.

Instead you see a lot of arguments with anecdotal or indeterminate language. "Most people [that I talk to] don't seem to have much trouble unless they're less experienced."

It's an amazing piece of rhetoric. In one sentence the ergonomic argument has been dismissed by denying subjectivity exists or matters and then implying that those who disagree are stupid.

"Performing something like this is definitely expensive"

That is false. A 51% attack is only expensive to the degree to which the hashpower required to exceed 50% is obtained at negative margins.

If an attacker can collect the total 51% or more hashpower at what would be a profitable rate despite the attack, then the attack is not "definitely expensive" - no, the attack is definitely profitable and the expense falls sorely on the minority.

It's not that people shouldn't have a minimum standard of living, it's whether we are going to take easy and ineffective routes to solve the problem that look good on paper and in commercials or whether we can have the adult discussion about the monetary system and how it affects citizens.

Why is 90% for each step such an insurmountable probability?

Maybe it's completely unreasonable for you to assume the causation for each step isn't on the order of 99%. Your argument is too abstract to be a relevant rebuttal.

You're completely off base on the focal length argument.

A traditional camera has the choice and can choose the most appropriate length; an Iphone is locked in to a fish-eye clearly put in there to overcome its inherent limitations.

So it doesn't really matter "if it's fair" or not, because it's not about a fair comparison, it's a demonstration that a traditional camera is just better. Why should the traditional camera use an inappropriate focal length just because the Iphone is forced to?

I'm not going to argue you or anyone should find the value aforementioned.

But I think the "it's been 15 years" argument is hollow. Clearly Bitcoin has an every-growing community of dedicated holders, and Bitcoin has surely increased the general skepticism of the monetary system.

I think you are conflating a speculative vehicle with an inflation hedge. Bitcoin is surely great for both depending on your timeline, but you strawman it a bit by appealing to the lowest common denominator who doesn't get and doesn't hold it.

It's provably scarce, it's highly locally securable (big job, but possible for most) and as a scarce asset, it's relatively cheap and easy to transfer. Yes, it failed as money (on the base layer), and that was its stated goal, but I'll readily give credit where it is due.

You should appreciate that the trust assumptions in your example have been minimized to a point not before possible for digital transactions; in principle removing all possible third-party interference in remote transactions.

If you're going to argue about failures in practice, I'm not interested, because I agree (likely in a way more open-minded to moving forward than your mindset of giving up).