We have all the cool kids like Kotlin, Rust, etc.
However, when it is about finishing a project, beating C++ or Java ecosystems is almost impossible.
Besides that, C++ has improved a lot over time. It still has its warts and knives but you can code very reasonable C++ with a few guidelines and there are also linters, and -Wall -Wextra -Weverything -Werror. That takes you quite far in real life provided you have a reasonable amount of training.
I would choose C++ over Rust any day. The only hope I have for C++ successors are Cppfront and Carbon and they are highly experimental. As successors those two fit the bill.
There is a third one, my favorite. It is this one: https://www.hylo-lang.org/ but I am not sure how compatible it will/would be.
not having to explicitly remember `free` in safe Rust code is amazing. Knowing that if my types are sound that memory will be managed reasonably is great.
I also think that immutable by default, mutable by explicit declaration is pretty great.
I do think there is a lot of room to add better ergonomics on these ideas however
Besides that, in real life you end up having C in most of your software, so I am not sure how Rust behaves compared to well-written C++ with all warnings and linters on and using smart pointers. But my hypothesis is that they do not stay very far apart in safety.
There are many ways to achieve safety, and the most promising, IMHO, is the path that Hylo programming language is taking. It sticks to Generic programming and mutable value semantics.
The language base draws from Swift and it has very strong people behind that know what they are doing. For example David Abrahams and Sean Parent. This is an implementation in a language of many of the ideas from "Better Code" from Sean Parent. It has a very solid foundation.
Besides being a solid foundation for generic programming, value semantics, and concurrency, what I like the most is how much it simplifies the model by not escaping references all around and preventing unnecessary copies. This removes the (IMHO) mess that is to have to manage reference escaping constantly in Rust, reason why many patterns such as Linked lists are not even possible.
And Lists are not just an academic exercise, as I was told sometimes by Rust proponents. Linked structures (Inmutable linked structures actually) are important in scenarios such as TelCo backend where you need replication, fast moving of data and history versioning, rollbacks and so on.
Being able to offload all that busy work to the type system is just nice. There are definitely ergonomic improvements that could be made around this.
All the rest? I'll leave that to someone else to talk through, as I'm no expert here.
It disallows many valid patterns. That is why I recommend to take a look at Hylo programming language (before called Val lang) to see what I think it is a very good example of how to make a language safe without making the learning curve so steep and without a need for a GC.
It's difficult to have this discussion in any sane way when Rust (or C) comes up. I tried Rust, but I have projects to deliver on strict timelines and I have yet to find a client who is prepared to pay me for the (what I found to be) very large onramp time to gain deep Rust expertise.[1]
The argument of "just get gud" whenever you point out the deep learning curve of Rust is pointless; I have noticed that Rust experts only come when your employer is rich enough to pay the team to not deliver while they learn it: Basically only FAANGs and startups flush with VC money.
[1] When I have a small project I reach for C. When I need something bigger for which C is not suitable, I don't reach for C++, or Rust, I rather take the tiny performance hit and move to Go. On extremely large projects, where I work with others, C# and Java seem to hit the sweet spot.[2]
[2] Although, C# and Java are also getting a bit too complicated for my tastes too. Seems to me that every language follows C++ evolution towards complexity, because the people stewarding the language are experts in that language and/or in programming language theory.[3] They are comfortable with the changes they propose because they have no need to upskill (they are already at that skill level).
[3] I propose that a language designed by your average corporate developer who has 15 years of experience but not CS degree will have much higher adoption than languages designed by PL purists.
Because I said:
>> C# and Java are also getting a bit too complicated for my tastes too.
I abhor complications.
> And why not go for the large projects?
Because I said:
>> where I work with others, C# and Java seem to hit the sweet spot
Yeah yeah, I know it sounds like I am whining (Maybe I am :-), but at least I am complaining about all of them.
Java and C# do appear to have been battle-tested for very large projects that aren't microservices.
Go? I dunno. I've only ever seen very large projects in Go using microservices. I like its simplicity.
My main complaint is that programming languages have too much minutiae to track that I really shouldn't have to be tracking.
Take, for example, asynchronous builtins:
Why are all the explanations wrapped in jargon that only an expert in the language would grok immediately? Promises? Futures? You gotta explain those, with examples, before you can explain what to do with a value from an async call. Go look at the popular introductions to async (say, on MDN for js, or Microsoft for C#, etc) and count how many times they have to explain something because of their leaky abstraction implementation rather than explaining the concept.
How about simply saying "calling async functions only schedules the function for later execution, it doesn't execute it".
That naturally leads into "So you need to check if it is finished using an identifier to identify which scheduled call you want to check"...
Which itself naturally leads to "The identifier you need was given to you when you scheduled the call"...
Which leads to "Using that identifier from `id = foo();`, you wait for the result like this: `result = id.wait()`".
You can even add "You can return that id, or pass it around so some other code can do `id.wait()`".
Now they don't explain it this way, because their implementation(s) is more of a leaky abstraction exposing irrelevant information about the compiler, than of a straightforward implementation of the concept. They are unable to separate the concept from their implementation.
The common implementation of async is so counterintuitive that they have to explain their particular implementation instead of the concept, because it has almost nothing to do with the concept. If they just explained the concept, programmers would still be confused because the implementation needs things like colored functions just to work poorly.
The concept of scheduled functions (which may return once, or may yield multiple times before returning), which is a simple path to understanding asynchronous calls, is completely divorced from the implementation which will produce errors like "cannot call asynchronous function from a top level"[1] or "cannot call await in a function not declared as async".[2]
So, yeah, I'm kinda upset at how programming has evolved over the years (I wrote my first program in 1986, so had a good seat for the later part of this particular movie), from "simple and straightforward", to "complex for complexities sake".
[1] Why? Because their abstraction is an abstraction of their implementation, and not an abstraction of asynchronous calls.
[2] Se [1] above.
This is not always true.
Can C++ compilers + linters reliably detect all misuses of unique_ptr? Because that sounds like a halting-problem kind of problem, and as soon as you can't guarantee memory-safety, you're definitely not in the same ballpark in terms of safety. I mean, memory-unsafety is the number one vulnerability cause in software. C++ has many qualities, but safety certainly isn't one of them.
Is C and assembly the same level of memroy safety? Probably yes... but no, it is not in practice.
And C and C++? Yes, in theory, in practice... C++ is safer.
How about Rust? In theory Rust is safer. In practice, you are going to use C libraries here and there, so... in practice not as safe as advertised.
Well-written C++ with -Wall -Werror, -Weverything, -Wextra... that is very safe, including detecting even dangling stuff. If you stick to `shared_ptr` and `unique_ptr` no matter how much you complain about it: Rust with its C shims and C++ with all linters and a good environment are practically at similar levels of safety.
This is the practical, real thing that happens. I do use C++ for every day use for around 14 years professionally and 20 years in total.
You are all in the terrain of theory, but how much Rust and C++ have you really written?
Of course, the CVEs data about memory safety, well, those are true. And they are a real problem. But with a reasonably good use of C++ those would be much, much, much lower than they have been so far.
Yet, somehow people do this with python, perl, and ruby. Google hires professional python people too.
https://charliereese.ca/y-combinator-top-50-software-startup...
C++ gives more return when you start to save in infra because you have a more efficient language, if coded properly. Same goes for Go vs Python.
The right tool for the right job. I would use (and will, I am on it) Django for a SaaS that I have for the backend. If things start to work relatively well, then, I will keep identifying, if there are, bottlenecks and migrate with a hybrid architecture parts of the workload to C++.
This allows me to save in infrastructure bills.
IIRC, Val has been mentioned on HN sometimes earlier.
I remember trying to compile GTK+ on a solaris system a decade ago, and remembering how terrible it was to even to get it to compile.
You're really deluding yourself if spending your time in compiler dependency hell is so much better than python.
I see this argument a lot, but people often forget that Python is very concise (yet readable) compared to other languages.
100k LOC in Python typically contains way more business logic than C++, so it is only natural to be harder to maintain.