Seems like C++ is having an identity crisis lately
Perl had Ruby, Python, and PHP attacking it. C++ has Rust, Go, Nim, and Swift (albeit that only Rust is a direct challenge, the others are taking market share for things that used to be C++). I've even seen people using Vala in new places.
Perl was hard to use. The new languages addressed many of the ergonomics, semantics, and design concerns. Rust addresses a lot of C++'s dangerous baggage.
Perl had novel tooling at the time, but eventually wound up behind. Newer languages brought more to the table. Rust has Cargo.
Perl tried evolving for a long time. Eventually birthed a new language altogether (Raku), albeit that the old language still receives updates. (Python also saw this.) Google recently unveiled Carbon. Now there's Cppfront. The C++ language committee is doing different things...
It's a question of which ecosystem evolves faster and ultimately which ecosystem attracts more fresh blood as old timers age out. AFAICT, younger developers are flocking to Rust instead of C++. There are a bunch of Rustlang streams on Twitch.
As someone who did a lot of Perl in web 1.0 times, and haven't really been a full time programmer in a long time but occasionally have since written Ruby, Python, and PHP, but never really felt those languages were that huge of improvements over Perl (certainly now their ecosystems are, but I'd love a much better entrant to successfully "attack" Python), and would sometimes wonder what if Perl had just managed to evolve significantly instead...makes me appreciate and even root for efforts to "make C++ 10x simpler, safer, and more toolable" like this one or perhaps Carbon, even though Rust does seem like a huge improvement.
I think the C++ analogy makes sense. How many programmers entering the field today are choosing to learn C++ when they have so many other choices without all of C++'s baroque complexity and footguns?
However I see one similarity between C++ and Perl: for decades, they evolved a lot from there ecosystems and nowadays, both C++ and Perl could be difficult to learn just because you can't figure out what module to use to get the job done. Also Perl suffers the lisp curse http://winestockwebdesign.com/Essays/Lisp_Curse.html (I don't know about C++).
The language complexity was famous and eventually grew into several subsets before UNIX adoption wiping out most systems languages that sprung as PL/I alternatives.
Many of us don't agree with the way the committee has been "evolving" the language and then mandating "the one true way to do Modern C++". At least with this "syntax 2" thing they will leave the language alone.
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.
> 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).
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.
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.
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.
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.
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.
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.
Plus it's only single player until they decide to add multiplayer…
> 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.
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.
Thankfully App stores are already making this point clear to the industry.
Second, I think data shows most people don’t return games after 1 crash. In fact, I think getting to market fast is a bigger factor for profit.
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
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.
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).
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.
Lack of education + Legacy software / programmers / education material.