eh, i really did look for a joke. all i see is a “well actually” opinion that somebody here probably holds

Yes if you remove all frivolity I’m sure the joke will be funnier

I definitely agree on the last point. Personally I like languages where I can get the compiler to check a lot more of my reasoning, but I still want to be able to use all the memory management techniques that people use in C.

I remember Jonathan Blow did a fairly rambling stream of consciousness talk on his criticisms of Rust, and it was largely written off as “old man yells at clouds”, but I tried to make sense of what he was saying and eventually realised he had a lot of good points.

I think it was this one: https://m.youtube.com/watch?v=4t1K66dMhWk

That’s what std::move does, and you’re right that it’s quite an ugly hack to deal with C++ legacy mistakes that C doesn’t have.

I say move semantics to refer to the broader concept, which exists to make manual memory management safer and easier to get right. It’s also a core feature of Rust.

Also I’m talking about parametric polymorphism, not subtype polymorphism. So I mean things like lists, queues and maps which can be specialised for the element type. That’s what I can’t imagine living without.

I would have said the same thing a few years ago, but after writing C++ professionally for a while I have to grudgingly admit that most of the new features are very useful for writing simpler code.

A few are still infuriating though, and I still consider the language an abomination. It has too many awful legacy problems that can never be fixed.

The only conceivable way to avoid pointers in C is by using indices into arrays, which have the exact same set of problems that pointers do because array indexing and pointer dereferencing are the same thing. If anything array indexing is slightly worse, because the index doesn’t carry a type.

Also you’re ignoring a whole host of other problems in C. Most notably unions.

People say that “you only need to learn pointers”, but that’s not a real thing you can do. It’s like saying it’s easy to write correct brainfuck because the language spec is so small. The exact opposite is true.

I’m not a fan of C++, but move semantics seem very clearly like a solution to a problem that C invented.

Though to be honest I could live with manual memory management. What I really don’t understand is how anyone can bear to use C after rewriting the same monomorphic collection type for the 20th time.

They are both doomed because neither is transformative enough to justify adoption. They are going to need to solve much harder problems to do that.

Take Rust as an example. It solved a problem that most people weren’t even paying attention to, because the accepted wisdom said it was impossible.

Mojo’s starting point is absurdly complex. Seems very obviously doomed to me.

Julia is a very clever design, but it still never felt that pleasant to use. I think it was held back by using llvm as a JIT, and by the single-minded focus on data science. Programming languages need to be more opportunistic than that to succeed, imo.

The github blurb says the language is comparable to general purpose languages like python and haskell.

Perhaps unintentionally, this seems to imply that the language can speed up literally any algorithm linearly with core count, which is impossible.

If it can automatically accelerate a program that has parallel data dependencies, that would also be a huge claim, but one that is at least theoretically possible.

I don’t want to be mean, but this is quite a lot of misinformation. For the benefit of other readers: this post makes a large number of specific claims very confidently, and almost all of them are wrong.

It takes time to make sense of this subject and it’s normal to get things wrong while learning. I just don’t want other people to go away thinking that closures have something to do with memory safety, etc.

Out of the ones you listed I’d suggest Julia or Clojure. They are simple and have interactive modes you can use to experiment easily.

Experienced programmers often undersell the value of interactive prompts because they don’t need them as much. They already have a detailed mental model of how most languages behave.

Another thing: although Julia and Clojure are simple, they are also quite obscure and have very experimental designs. Python might be a better choice. From a beginner’s perspective it’s very similar to Julia, but it’s vastly more popular and lots of people learn it as their first language.

Based on the languages you found, I’m guessing you were looking for something simple and elegant. I think Python fits this description too.

How did they ask all these random people and not bother to ask a single software engineer?

“Hi is this excuse real, or is it just a sign of an inappropriate relationship between the local council and a dodgy software company that pays more dividends than developers? Oh it’s the latter? Okay, thanks.”

Why is this? Did they introduce breaking changes to the language or something?

Wait until this guy finds out that Elon doesn’t actually build the cars

What a whirlwind!

Also, Rust is perhaps, the shittiest, slowest compiled language out there. Even TCC has a leg up on it.

TCC is written exclusively to compile quickly, not to do any real optimisation. There is no conceivable situation in which TCC output will outperform equivalent Rust code.

If you really like how Rust handles its syntax, use a real functional language like OCaml

Rust takes inspiration from OCaml in almost every area except syntax. Close to zero syntax similarly.

In fact, SML compilers like MLton are sometimes faster than Rust.

Lmao, this is a classic line from ~2009 message boards, but with “C++” swapped out for Rust.

Almost every single thing you said is wrong, but in a way too precise to be attributed to random noise. Like scoring zero in a multiple choice exam. I don’t know if you are some kind of performance art troll, but please continue. I’m an instant fan of your work.

Is it really fair to say retain doesn’t compose as well just because it requires reference-based update instead of move-based? I also think using move semantics for in-place updates makes it harder to optimise things like a single field being updated on a large struct.

It also seems harsh to say iterators aren’t a zero-cost abstraction if they miss an optimisation that falls outside what the API promises. It’s natural to expect collect to allocate, no?

But I’m only writing this because I wonder if I haven’t understood your point fully.

(Side note: I think you could implement the API you want on top of retain_mut by using std::mem::replace with a default value, but you’d be hoping that the compiler optimises away all the replace calls when it inlines and sees the code can’t panic. Idk if that would actually work.)

I mean, let’s be real, Rust is really called out because it causes high drama between C devs and Rust advocates, which drives engagement.

It’s probably all kicking off in about 10 different comment sections right now

5 years ago everything was moving to TypeScript. Now everything has moved. Developers are still catching up, but it will be one-way traffic from here.

I’m guessing your manager thinks TypeScript is like CoffeeScript. It is not like CoffeeScript.

Also, TypeScript is only the beginning. In the halls of the tech giants most devs view TypeScript as a sticking plaster until things can be moved to webassembly. It will be a long time until that makes any dent in JS, but it will also be one-way traffic when it does.

The specifics of C’s design could barely be less important. In the 70s it was one of countless ALGOL derivatives churned out on-demand to support R&D projects like Unix.

Unix succeeded, but it could have been written in any of these languages. The C design process was governed by the difficulty of compiler implementation; everyone was copying ALGOL 68 but some of the features took too long to implement. If Dennis Ritchie had an extra free weekend in 1972, C might have a module system. But he didn’t, so it doesn’t.