Why not Rust? Zig does not have nearly the same memory guarantees as Rust, I mean, why create a new language and still make the same fundamental errors when we've fixed them in other languages. That's also how I feel about Go and its lack of algebraic data types.
Zig is a completely different language than Rust. Memory safety is just one aspect. I personally find Rust to be very difficult to read and can never manage to be productive in it.
Lacking memory safety is a fundamental mistake in my opinion, not merely one aspect. We have learned much from the days of C and C++, so much that companies are migrating away and finding that many of their bugs are solved with memory safe languages like Rust.
I forgot to follow up on this, I don't know how to make HN give me some kind of a notification on replies to my comments.
I should have been a bit more clear. I love memory safety. But I dislike a lot of other aspects specific to Rust. I would much prefer e.g. C with memory safety (somehow). So that is, for me, why not Rust. Rust is more more than just memory safety.
Zig doesn't have a 1.0 release yet so I'd be hesitant to use it on any production projects. I've dabbled in it for some toy projects just to get a feel for the language and so far I think I still prefer Rust although the simplicity of Zig is something I can get behind.
What does Zig offer over Rust in this use case? It makes lower-level operations easier, but that's not super relevant to most UI work (unless you're Figma)
I will disagree with this list, in part. And I am thinking specifically of PHP. I am an emigrate from PHP ecosystem, I departed from PHP 11 years ago and never looked back. The number one reason that I left PHP is that #1 in your list was plainly false. There were _not_ high paying jobs in PHP, no matter how good you were or not. The whole point of using PHP is to pay as little as possible; and make developers as fungible as possible. And if a certain demographic yielded good quality developers for an even lower price point, I would certainly see whole teams being replaced to fit it. I was actually recruited, more than once, exactly for this reason.
Languages don't die, they ride into the sunset. There is enough inertia in PHP-ecosystem that you can still find jobs, but they are very often just legacy work jobs (at least in my area). No serious technical leader would pick PHP to execute on new work, except of course, if their main driver is to pay as little as possible and the language choice doesn't bubble up to investors' keyword-driven investment thesis.
VB6 and PHP are nice. I am skeptical of the affirmation that there is a lot of money in these ecosystems. The pie may be currently large, but I do not see it growing.
I am not sure any of what you described can be declared a success in any sense.
Failure #1: The language deployed a non-backward compatible change.
Failure #1b: and their ecosystem thinks that's OK.
Failure #2: users only saw the need to upgrade the dependency because the language broke that dependency first. So unless they had some other reason to update the given dependency ahead of the compiler upgrade, they would be hit by the problem no matter what.
Failure #3: downplaying The importance of the breakage by implying the blast radius would've been smaller if the victim of the first two failures was a lesser known dependency.
I can't see any success - of the release process or in any other way.
And finally, framing a failure as success is one central problem I have with Rust ecosystem's toxic positivity. In any other healthy community the answer would be "OK, we made a mistake, let's run a post-mortem and do better", or even plain embarrassment - but Rust's ecosystem is the only one in which there's a failure in the joint of two releases processes and claim it as a "success story for [one of the] release process".
My hope, as bigger games adopt Rust (US Gov, MS, Linux etc) these attitudes will change.
You can make an abstract argument as much as you'd like, but Rust toolchain upgrades cause the least churn of any ecosystem I've worked with in the past 25 years of being a software developer. That includes C projects.
I've spent more time writing Hacker News comments about this than I did dealing with it.
> Failure #1: The language deployed a non-backward compatible change.
I guess I'm trying to understand how this is particular to Rust. Isn't this something that can happen in any language which uses type inference? I wonder how other languages resolve. It may be fair to say -- "if you rely upon type inference, the algo isn't guaranteed not to change" as a caveat on backwards compatibility.
> And finally, framing a failure as success is one central problem I have with Rust ecosystem's toxic positivity.
This just threw a huge wrench in the gears for a spambot detection system I was working on. The kind of content a spambot likes is a great indicator to choose whom to block or not.
In general this is such a good way to assess & browse & evaluate people. Trying to figure out who to follow & who is definitely not someone to follow gets much much harder when the like-feed goes dark.
Try as people might to defend this anti-networking anti-feature I just don't see it. It's an ok option for some I guess, sure, but tearing up your network unilaterally to create a safer space really just sends us into an even darker forest.
