Rust is eating it in systems and Go for applications.
IMHO nothing but Rust or Go has any merit as a replacement unless it also bring the same safety. A fully unsafe language in 2022 is dumb. (Fully unsafe, not optional unsafety which may be needed in a systems language.)
I think this is a subtweet at Zig, and while I am not a zig developer, I will point something out that everyone forgets (to defend C++ and Zig and the like): Some apps don't need memory safety.
For example a single player game or application that runs just on your own machine, memory safety would just be another type of bug.
If dealing with Rust's ownership rules is annoying and you don't want a GC, then you can certainly use an unsafe language. Not all apps are websites and browsers.
I would also add (I could be wrong here) but I think things written in web assembly can also be unsafe, as the memory is in a sandbox. I think I heard this once, but I could be wrong.
Even setting security considerations aside, as soon as you have users, using a non-memory-safe language means having users reporting very unhelpful “bun crashes at startup with "segmentation fault"”and good luck to figure out what's going on.
> I think this is a subtweet at Zig
Why do you think it's especially aimed at Zig? Zig is only one among others, like Carbon, or Cppfront discussed here.
I would agree that seg faults are not fun to debug, but if you think you can be speed up production and get the product done several orders of magnitude faster without ownership rules AND you can't use a GC, I do think it could be worth the trade-off.
> Why do you think it's especially aimed at Zig?
I honestly don't use zig so I really don't have a horse in the race, but when I read:
"nothing but Rust or Go has any merit as a replacement unless it also bring the same safety. A fully unsafe language in 2022 is dumb"
That seems to be targeted at replacing C++, which both Carbon and CppFront are not doing per se. Zig is the next big "low level replacement language" (that isn't Rust or Go) that HN seems to chat about so I took a guess.
Again, I don't think that's too relevant to my point (although I am curious if OP wants to weigh in on what they meant).
> but if you think you can be speed up production and get the product done several orders of magnitude faster without ownership rules
If you genuinely believe that Rusts rules slow developers down by “several ordrers of magnitude” (which litterally means: “makes you 100 times slower or more”) then you've probably listened/read way to much anti-rust discourse for your own good…
Rust has a learning curve and in the beginning you're obviously going to be slowed down by the learning process, but for 99% of the tasks[1] once you've gone past the initial learning period, the rules aren't slowing you down since you've internalized them, and compiler errors end up being mostly about things that would have caused a memory bug in other low-level languages.
[1]: that is, everything but custom graph data structures, which are really hard to get right without a GC anyway.
I actually have started learning rust and I do like it. I am hoping to get to a point where the ownership structure becomes obvious in my mind.
If I had to make a game right now though, I would be way faster in C++.
That said though, I do hope as I learn rust everything becomes obvious. I would be very happy if I get equally as productive (since that means I can use rust for everything).
I guess I just worry that certain things are like custom graph data structures, where suddenly ownership is a huge issue.
> If I had to make a game right now though, I would be way faster in C++.
I've no doubt about that, learning Rust sometimes feels like having to swim with your hands tied in the back.
> That said though, I do hope as I learn rust everything becomes obvious. I would be very happy if I get equally as productive (since that means I can use rust for everything).
Good luck:), don't be afraid to stop and try again a few weeks later if you get too frustrated: I struggled a bit to learn rust early 2016 and after a few weeks of night hacking, I had no more free time to carry on and I was still very confused about all of that. Then, I stopped for almost 6 months, having read of few blog posts in Reddit in the meantime but nothing especially eye opening or anything, and when I got back to Rust for some reason everything sounded clear and I completed my first project in Rust very smoothly, as if my brain had been slowly digesting the concepts in a background thread during that time.
> I guess I just worry that certain things are like custom graph data structures, where suddenly ownership is a huge issue.
Advice: avoid them as much as possible (most of my former use of graph-like structures where in fact related to programming patterns and not strictly necessary for what I wanted to do) and if you're really manipulating graphs, you should probably use a dedicated library (I think petgraph is the most popular but these kind of things can be workload dependent so you might need to go for another one).
Even apps that run locally and don’t talk to the net can be vulnerable. How many break ins happen via bugs in PDF viewers, office packages, and media players? Look it up. PDF and spreadsheet vulnerabilities are very common.
Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs. The latter are not ruled out in Go or Rust but they are profoundly less likely to occur, making code that actually takes advantage of modern hardware much easier to write.
After learning Rust and after having used C++ very heavily for years I can say that Rust is far more productive.
> PDF and spreadsheet vulnerabilities are very common.
True. The issue is that they operate on complex input that can arrive from anywhere. So if you download a malicious PDF file it can exploit you.
But GP's other example is valid: A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program.
There is room for languages like Zig. There is also the potential for it to be used in improper places, but so far the majority of applications I've heard of seem reasonable to me.
> Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs.
Also true. But there are the other usual tradeoffs, such as that a language focused on simplicity and correctness, like Zig, might reduce other sources of bugs.
Some developers might be more productive with Rust, others with Go, others with Zig. I don't think there's a single answer here. As an example of another related tradeoff, fast compile times often help debugging, which is an advantage of Go and Zig.
> A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program.
Nothing is that isolated anymore. Can you find a modern single-player game on Steam that doesn't talk to the network for analytics or DLC or sending crash reports to the developer? I'm sure they exist, but they're likely exceptionally rare.
For Zig to be helpful in the modern world, it will need memory safety guarantees and it will need them on by default. It's totally OK if those are easier to switch off than in Rust so that you can do the low-level things performantly and easily. But you have to start from a default position of safety.
Even if a game sends crash reports etc., it could be safe enough. Making a secure connection to a known remote server isn't a major source of exploits. (Look for example at the list of exploits against Firefox and Chrome - stuff like that isn't even noticeable.)
I disagree every language needs to start with the same defaults as Rust. Rust proved its approach is a useful one, and Rust is a huge asset to our industry, but we also benefit from exploring other approaches.
Maybe not, but it's still a big pain in the butt to avoid bugs in that area. I imagine that static analysis for memory safety would be something that most developers would use in existing unsafe languages if they could.
A single player game still accesses the network. Consoles that trust their game code regularly get jailbroken through eg overflows in a game's save file formats.
Plus it's only single player until they decide to add multiplayer…
Only because liability is still not a thing in software as in other regulated domains.
> Many years later we asked our customers whether they wished
us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions
would have long been against the law.
-- C.A.R Hoare on his Turing award speech in 1981.
Against the law cause if you do this on a bridge, people die.
If a play Civ V and it crashes, I just a bit mad.
I will acknowledge though good engineering practices are important, maybe my perspective of "tolerance" of these bugs when they are isolated is missing the point.
Not refunding a customer for selling a broken product is against the consumer law in plenty of jurisdictions.
People still don't do it because they have been taught that software is special, they have to put up with broken products, that is just how things are with computers.
Removing type checking from your running programs is like wearing a life jacket for your practice emergency drills and then taking it off as soon as your ship was really sinking
https://www.youtube.com/watch?v=YYkOWzrO3xg
Maybe that was right in the 70-80s, but I feel like he's not giving enough credit to modern static verification / type-checking.
A bug that can be costly to reproduce and fix and has the affect of terrible UX and losing unsaved progress. If I had to choose a category of bugs to tolerate memory safety bugs would be near the bottom of the list.
It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them?
I know that in the domains that I'm interested in, I would be way miserable programming in something like e.g. Java, because I've figured out certain patterns that I know will work in a memory-unsafe language with very little friction, but that cannot be simply be translated to Java because of e.g. reference semantics.
The same probably holds for other approaches to safety, like Rust. I'm not interested anymore in tight opinionated approaches to problem solving. I _love_ void-pointers and memcpy'ing stuff because these let me do abstraction with very low friction. Getting the job done very quickly, with very very low rate of bugs, and those get quickly fixed. (I'm not making a statement about multi-million line projects in corporate environments. This is about the situations that I run into, personally).
> It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them?
Honestly? And this might be a hot take - exactly the same way as I'd explain people rejecting structured programming way back in the day. It was the new thing on the block and people were not used to it, and preferred to just sprinkle GOTOs in their program just like they always used to do rather than learning a new paradigm.
As someone who used to professionally program in C++ on an expert level in the past and now has completely switched to Rust I can tell you that (at least subjectively for me) Rust is way more productive than C++ ever was. Once you internalize how the language works the limitations of Rust just disappear. You learn how to instinctively write code that's idiomatic, and it just stops slowing you down. But it also gives you a ton of new features that end up speeding you up compared to C++, e.g. sum types, pattern matching, cargo, great standard library, destructive moves, proper modules, #[derive], good error messages, etc. Memory safety can also be significant productivity boost because you can (or at least I do) just churn out code without thinking about it too much and just rely on the compiler to make sure that it's memory safe. Can this code trigger use-after-free? Is this iterator valid? What's the lifetime of this pointer? Instead of thinking about all of these you can use those brain cells for something else.
It’s also a dumb macho thing. “Real programmers…” Yeah and I bet real home builders don’t use nail guns, prefab sections, or tape measures. They just eyeball it all and use wooden pegs and hammers.
IMHO nothing but Rust or Go has any merit as a replacement unless it also bring the same safety. A fully unsafe language in 2022 is dumb. (Fully unsafe, not optional unsafety which may be needed in a systems language.)