- cross-posted to:
- technology@lemmy.world
- cross-posted to:
- technology@lemmy.world
You must log in or # to comment.
Maybe if that had happened sooner, we wouldn’t have ended up with a barking mad mess.
This would not happened with Rust.
/s
Off course this is a joke reply. Because with Rust it could not be a C++ Standard.
This is a sign that C++ is (still) struggling with its governance (see a previous article on cultural issues within C++ here). This is a big deal even if you do not care about programming languages. C++ is arguably the most important programming language in existence.
Your computer runs on C or C++. The web browser you are using to read this is written in C++. ~All programming languages depend on C++ (often through LLVM). Likewise, ~all websites with performance requirements (e.g. YouTube) depend on C++, ~all data storage, game engines, finance, etc.
In a world that is drowning in exciting new vulnerabilities in ~all software, the ability of C++ to change and adjust to changing times affects you.
[ …]
Why are Contracts authors so obsessed with getting Contracts into C++26? Why not wait for the next release?
Well, C++ has this funny “release train model” (also known as “the frame rule bus stop analogy” in Super Mario Bros. speedrunning). A new version of the C++ standard releases every three years. If your work gets voted into the standard in time, it becomes part of it. If it doesn’t, you have to wait another three years for the next release.
Three years is a long time, and it’s an especially long time to work on a single C++ feature. Getting a C++ paper accepted into the standard is a process so notoriously draining that ~all of the “C++ people” I know just stopped bothering, and stopped working with WG21. It’s bad.
If Contracts don’t get in this cycle, there’s a good chance they never will. They will be nitpicked over the next three years, endlessly litigated, and frankly, I think there’s a good chance several of the people working on Contracts just won’t want to deal with that, and might instead drop out of the process entirely, leaving Contracts dead and buried.
Not being intimately familiar with modern C++ these days it is almost refreshing to see the process turn down a feature. One of the criticisms of the language is that its so multi-paradigm that you run a real risk of spaghetti codebases if you are not careful to enforce a house style of features used for a given project.
Maybe all long lived languages see this in the end? My day to day is in plain old C and the recent versions of the standard are much more incremental with what they add.
We’ll see how the upstart new languages like rust and zig deal with these issues as they mature. Maybe it’s a case of those who do not learn from the mistakes of C++ are doomed to repeat them?
Maybe all long lived languages see this in the end?
A counterexample would be Common Lisp. Not as widely used, but also used for industrial-strength systems.
Isn’t there a joke about all languages becoming half baked implementations of lisp?
If you want to have some fun, compare the features that newer Python 3.x versions have, with the features Scheme has, for example Racket or Guile.
The overlap is large: Doc strings, garbage collection, list comprehensions, lambdas, dynamic vectors, a numeric tower with arbitrary long integers, rational, floating point and complex numbers, a string formatting language, “with-form” resource guards, pattern matching, Generators, Exceptions, OOP frameworks, … it is a long list.
What is missing in Python, but Lisps do have, are JIT compilation to native code, much better speeds of compiled code, Common Lisps superb error handling with conditions and restarts, Common Lisps inheritable global variables, Common Lisps much more detailed boolean operations, and Scheme’s tail call optimization and continuations.
And still, Scheme manages to be a much smaller language than Python, and Common Lisp, while really large, is tiny compared to the specification of contemporary C++.
I really must play with some of the modern lisps. I’m afraid most of my experience is with elisp which while it has it’s charms I wouldn’t call a general purpose lisp.
I think the most friendly modern Lisps are Clojure, and Racket, which is a superset of Scheme. Clojure is arguably the most elegant one, extremely well documented, very good for learning, and a pleasure to work with. Due to its larger start-up time and its fantastic approach to concurrency (with built-in immutable collections), It is more geared to be used in server implementations, but it has now implementations for many platforms, not only the JVM.
On the other hand, the more powerful Common Lisp implementations, like SBCL, are seriously under-hyped. One thing that is special about Common Lisp is that one can easily debug the running program. This is not possible in the same way in other languages, since exceptions usually destroy the call stack - in Common Lisp, you can handle the error at the location it is thrown, and re-start operations.
From the Schemes, I think Guile has the best debugging experience, quite similar to SBCL. It is also very well integrated with a Linux/POSIX OS, and can with little effort call system library routines in C.
C++ has been moving away from the needs of its user base for too long now.
See also this, on a correctness checker for Rust.
Is it really necessary to keep adding features? Where is the place for C++ anyway when rust exists?
There are more experts and code in C++ than Rust. The entire world runs in C and C++. So working on those languages and expanding or refining them makes sense. Even if Rust takes over the world and is more used than C++ in the future (if that happens ever), it would still make to maintain and refine the language. Not everyone likes or wants to use Rust.
Even if we include LLMs porting code, the sheer amount of c++ code makes it not worth porting, and some legacy code just need occasional updates, especially embedded.
I expect that even if porting becomes free, perfect and instantaneous, there will be plenty old c/c++ code around for decades.
Even if we include LLMs porting code, the sheer amount of c++ code makes it not worth porting, and some legacy code just need occasional updates, especially embedded.
It is more effective not to port old working code, which would cost a lot of resources, but to write new code in Rust, where this is possible. There have been a few studies on this, even from companies like Google. The thing is that new code is more likely to have bugs than working old code. So, spending effort on new code gives more safety for a given amount of effort and resources.
On the other hand, it absolutely makes sense to write completely new projects in Rust, if the needed library support is there, since Rust tends to be more productive.
Also, in embedded systems, space systems, systems with certification requirements and so on, Rust is making inroads. Though these are rather conservative areas where tools are not changed quickly.
