C++ at the End of 2022
cppstories.com
cppstories.com
The document ends with “I call on WG21 to make a conscious and explicit choice here, with the clear awareness that status quo is an endorsement of indefinite ABI stability. If we wish to be the systems language known for performance, we have to act now. If not, we have to be aware that we are giving up on some important user bases.”
The committee chose an endorsement of indefinite ABI stability. A defensible technical choice, certainly. However, not one that works for Google.
That explains why they’re going ahead with the development of Carbon, as well as their endorsement of Rust. They don’t think the future of C++ development at Google is bright.
This has other effects too. Someone in this thread pointed out clang is lagging behind in implementing C++20 compared to MSVC and GCC. This might be because Google is committing fewer resources to the maintenance and improvement of clang.
Further reading: Difficulties improving C++ (https://github.com/carbon-language/carbon-lang/blob/trunk/do...)
If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. Unless, of course, you're using undocumented APIs. And even then, you can solve all those issues by statically linking against your dependencies.
In 20+ years of building distributed C++ systems I've just never seen inter-compiler ABI compatibility being an issue in practice.
I somewhat agree with the parent's point if we broaden "compiler" to include all of the ecosystem tools that care about the ABI.
E.g., debuggers really benefit from knowing about the ABIs being used.
That's not true in my experience. Sometimes it's helpful to see the call stack even without symbols. And sometimes there's benefit in debugging at the disassembly level, even without access to the source code.
> And if you have the latter, re-compiling to match the new ABI is easy.
I think we're talking about the scenario where the code was already compiled to the new ABI, but the debugger doesn't understand the new ABI.
A few thoughts on this:
1) Depending on circumstances, even if you have access to the source code, you might not be able to recompile it for the sake of better debugging.
2) If the code is linked against libraries that use the new ABI, or uses compiler features that require the new ABI, you can't necessarily produce a build that uses only the old ABI.
Mature people/organizations are willing to give up their local minimum for greater good of the community (global minimum). This would include staying with a language where the standards don't always go your way.
Immature people/organizations say "I'm going to create my own language! With blackjack and hookers!". And the programming landscape fragments further...
Is that really so? I really can't imagine that "recompiling the world" when the ABI is changed would be considered a normal thing to do or expect from users. Like, all of the sudden all the software that we use on our machines becomes subtly broken since, well, new version of C or C++ runtime library is now out.
I really don't see how this can be considered as a reasonable thing to do and therefore I understand and support the slow and careful ABI increments because the language is there to serve the goal which is beyond being a hostage to a handful of big players.
> I really don't see how this can be considered as a reasonable thing to do […]
Well, Linux distributions do exactly this, since decades, and it works just fine.
It's not like some dude needs to operate a crank for it to happen…
The computer does the actual work.
You know, a computer, this machine that can automate tedious tasks.
What do you think the reasons are that ABI transition didn't happen already?
Of course things are more complex. Not everything is a Linux distribution where it's simple to rebuild the world.
But as the history of C++ shows people managed to life with this issue for a very long time. So it's not a show stopper in any way.
Even other very conservative languages like Java found a balance for breaking changes. The "problem" C++ has is more of a mental one, imho.
Also C++ could easily introduced the "editions" concept form Rust. This would give you all form both worlds. You could improve future version (or editions) but stay compatible to old ones at the same time.
So, I don't think it's a "C++ mentality" but its rather a difficult problem to solve.
> Also C++ could easily introduced the "editions" concept form Rust. This would give you all form both worlds.
We'll see in about 20 years time if "editions" will solve this problem and if Rust becomes as widespread as C++ is. LoC deployed in Rust is currently a statistical error in comparison to C++. FWIW C++ also had similar proposal and it didn't went through AFAIK.
It was mentioned already that Linux distributions are doing exactly this. On every major compiler update.
> So, I don't think it's a "C++ mentality" but its rather a difficult problem to solve.
Sure it's not trivial to set up. But it's possible and done so for a long time already.
Sure, things could be made simpler. For example by using some stable intermediate representation that gets compiled on the target to the appropriate machine code. Oh, wait, all big platforms starting with mainframes do exactly this already… (Mainframes, the JVM, .NET, Android, Apple stuff, etc.)
> > Also C++ could easily introduced the "editions" concept form Rust. This would give you all form both worlds.
> We'll see in about 20 years time if "editions" will solve this problem and if Rust becomes as widespread as C++ is. LoC deployed in Rust is currently a statistical error in comparison to C++. FWIW C++ also had similar proposal and it didn't went through AFAIK.
That's not an argument against the "editions" idea. Actually what you've said doesn't even go into the proposal.
I guess you're aware not everything runs on Linux neither are all Linux deployments vanilla Linux deployments. At this point I think you're just intentionally ignorant or completely unaware of the world outside your bubble environment.
> For example by using some stable intermediate representation that gets compiled on the target to the appropriate machine code. Oh, wait, all big platforms starting with mainframes do exactly this already… (Mainframes, the JVM, .NET, Android, Apple stuff, etc.)
Eh?
> That's not an argument against the "editions" idea. Actually what you've said doesn't even go into the proposal.
It is an argument because suggesting to "easily introduce" the idea from another immature language which (1) is not proven and (2) which will take long long time before it does is wishful thinking, if not nonsense and far from reality. Rust "editions" do not solve the problem because, well, to begin with Rust doesn't have the problem of the same scale that C++ does.
We'll see what C++ will do in this regard but I wouldn't hold my breath. Disadvantages of breaking the ABI frequently currently outweigh the advantages and my opinion is that it will stay the same way for unforeseeable time.
The outcome: https://github.com/cplusplus/papers/issues/631#issuecomment-...
> FWIW C++ also had similar proposal and it didn't went through AFAIK.
The reasons why the ABI transition hasn't happened already is because C++ has a historical position of breaking the ABI only very very rarely. This is, in part, a legacy from a world where it really was going to be frustratingly difficult to get new builds of their libraries.
Also the OS ABIs are usually C ABIs because there is no C++ ABI at all…
https://faultlore.com/blah/c-isnt-a-language/
That's why I worded it with "ABIs". ;-)
Previous ABI would still be provided for running proprietary software on Linux just like you can still install libstdc++5. On windows apps ship the c++ runtime along with them so nothing changes for old apps. MacOS users are used to compatibility breaking every 3/4 years and went through actual architecture changes once every decade so obviously changing c++ abi is minor in comparison
I don't agree with your sentiment as I read it as a little bit narrow-minded and I also consider the examples given to be bad, with design choices not quite feasible to be applied to generic and widespread community language such as C++.
> On windows apps ship the c++ runtime along with them so nothing changes for old apps
That combination is probably the worst from the both worlds so not exactly a shiny example.
> MacOS users are used to compatibility breaking every 3/4 years
Apple has always been special and I wouldn't consider their choices, which are almost exclusively aligned with what their business wants to achieve, to be something to be followed. They can do whatever they want because they're under total control of almost everything on their platform. Unless when they aren't and when they start to develop their own programming languages. Pretty much the same story as with Google.
> That combination is probably the worst from the both worlds so not exactly a shiny example.
I really disagree, Windows's model of shipping DLLs along the app is the only one that works and does not cause headaches for the end-users who want to run their software from 15 years ago (e.g., me, my parents, my non-technical neighbours, etc) ; this is the only thing that matters, the end-user experience.
How about server-side code powering virtually any service that we're using? I think that your 99.9% would quickly become 0.01%. Desktop is important but irrelevant in this regard.
> I really disagree,
I beg to differ. I think it's really terrible for reasons I have no time to dig in through right now. Many of them are in fact quite obvious.
the huge huge huge majority of the software I use for doing, like, useful stuff, are offline. Internet could loose all interactive features tomorrow and be restricted to just displaying fixed hand-written HTML pages like it's 1993 and my day-to-day activities on my computer would not meaningfully change - making music with the software I develop, editing photos in Krita and Darktable, writing papers in TeXStudio, the occasionnal 3D / CAD project with Blender / KiCad / LinuxCNC, etc etc
If you don't have the ability to rebuild or otherwise get updated dependencies, you've got problems beyond ABI stability. "I cannot rebuild my dependencies" is unacceptable from a vuln management perspective, for example.
This process is called evolution.
There are only the two options when trying out new things: You fragment your language, or the language landscape.
Most languages don't want to have incompatible versions so as a result new languages get created during the evolution process.
I am involved in scientific programming, and it's getting kind of crazy. This is a domain where programming is purely utilitarian, and what you are programming is more important. Unfortunately, new languages are driven by people who love programming for the sake of programming, and are often employed in big corporations that can absorb the financial cost of ecosystem duplication and fragmentation.
The time scientists spend on 'infrastructure' is increasing, and I'm not sure that's always a good thing. (Some is good, of course).
In my experience this leads to a lot of bad programming by people who only care about the utilitarian aspect, not about maintainability, user experience or failure modes.
Scientific programming would benefit the most from a stricter language that catches errors early on. Especially because most of the participants are usually not software engineers that have some semblance of a chance to catch errors in C++. Even they make a lot of mistakes.
I would concur.
This shows actually nicely that the analogy to biological evolution matches well.
Google is building some kind of cave fish. Biology did also such things when they were right for a given ecosystem niche.
It actually didn't. It chose to further delay an actual decision here. The effect is almost the same but it means different things when it comes to understanding how the committee thinks and whether they largely agree or not.
The remaining members are increasingly likely to vote in favour of stability, despite that meaning performance overhead. By induction, the expected result should be that stability is chosen over performance in the future as well.
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
It’s a fallacy to think that there’s some idiomatic C++, there isn’t in practice.
Office and Windows teams love C++ and COM too much to use anything else.
Agreed, but collaborative efforts like C++ language steering, Clang development, etc. can benefit from a large pool of contributors.
So IMHO, Google reducing investmentin Clang could be a net loss for most Clang users.
C++ can do all kinds of wacky stuff, all of which feels bolted on as the language tried to grow support for each passing paradigm and fad. The syntax is arcane and makes PHP look downright delectable. Pointer sigil placement and const correctness (dangerously) matters, template compile errors look like alien machine code, and no amount of new best practices will save you from old C++ codebases.
I can't see new people reaching to learn C++. It will die with its current users. It's difficult to learn anyway, mostly because the materials and community are inaccessible and stuck in the 90's. And the important lessons on how to actually properly do memory management aren't enforced and only come from painful failures, direct tutelage, or reading an entire book on the subject twice over.
If all Rust had going for it was Cargo, an improved syntax, and the better docs and compiler messages, it would still win. Thankfully it's got so much more than that, and it fixes many of the systemic problems that C/C++ can't address.
[1] (in production, generating revenue)
I guess you wrote this while knowing very well that it's just whishful thinking. People will keep learning C++ for the foreseeable future, in order to reach the job market that this language opens up.
And if "people" in this sentence meant the companies using it, then again not a chance in the short term. Most companies using C++ have huge codebases that will only be ported to something different when it makes financial sense for them to do it (which is something that almost never happens for an already existing codebase)
Just like FORTRAN.
(Sorry for the snark! I do agree with your points.)
> Most companies using C++ have huge codebases that will only be ported to something different when it makes financial sense for them to do it (which is something that almost never happens for an already existing codebase)
Again, not disagreeing with you, but this is why it's good when companies get eaten by more nimble startups without the baggage. Legacy systems die due to business failure.
You mean like in the case of COBOL? ;-)
OK, admitted, banks can't fail. They're protected by law of nature. (Or something like that).
That's true.
But at some point maintaining this code will give you your weight in gold on a daily basis. Like it's currently for COBOL.
No, I'm not looking for such a job. I fear C++ and especially the legacy code. But there will be likely people willing to look after this code.
> I can't see new people reaching to learn C++. It will die with its current users.
Successful languages don't "die". They fade out. Very, very slowly…
I think this process in some way resembles nuclear decay and the concept of half-time.
> If all Rust had going for it was Cargo, an improved syntax, and the better docs and compiler messages, it would still win.
Well, yes, but the syntax is no real improvement. Rust is as ugly as hell. (Which does not say anything about the actual language as such. Syntax is "just syntax". But Rust has chosen deliberately an ugly syntax to attract C/C++ people, I guess).
All the unnecessary syntax noise everywhere. Unnecessary braces, unnecessary semicolons, unnecessary commas, angle brackets, some wild mixture of symbols and words (where clauses in types, WTF…), ill lambda syntax, etc.
A modern language shouldn't be designed to be foremost convenient for the machine, but instead convenient for the human in front. Parsing is cheap nowadays. Very cheap.
But OK, syntax is much of a personal opinion based thingy. It wouldn't be a show stopper, at least for me, if the actual language has merit.
By all means specialize in a legacy language if that is what you enjoy, but you are setting yourself up for disappointment if you do it for the money.
I think there is no other software developer role even remotely paying as well as COBOL in Europe. You get mid level FANG salaries, which are twice or trice what you get for the usual development gig in the EU.
EU is banking land. And they locking deliberately for people with COBOL and mainframe skills.
> By all means specialize in a legacy language if that is what you enjoy, but you are setting yourself up for disappointment if you do it for the money.
I guess this is very true.
Even the money looks interesting I would not enjoy such a job, I guess. (It would be fun to find out about the mainframe but that's nothing I would like as a day job. It would be more historic interest. And COBOL, naa, there are more terrible things likely but it's not nice either).
The novel parts are lifetime specifiers (infrequent), reference/slice sigils (not a big deal), and the weird macro language.
Assuming the best intentions, one should think how misguided it is to look up to amoral entities like corporations as role-models. At a macro level, Google does what brings them money. At a micro level what brings the engineers promotions and improves their reputation.
I've written about this before, there's a tendency to insist that if you just asked surely future C++ can accommodate whatever it is that is needed. What a bunch of people (many but not all from Google) did was write a C++ Proposal which says "This is what C++ needs" and the committee said "No". P2137 "Goals and Priorities for C++"
That finally means you can have the next conversation, instead of "Surely C++ can do that" we can get to "OK, C++ won't do that - what are we going to do instead ?"
The answers include a lot more Rust, as you have seen from Google and other entities.
I'm presumably part of the "guerilla marketing" you're talking about, although I don't think it's useful to imagine a community as engaging in "guerilla marketing" when they do what people naturally do, communicate. When people whose first language is Spanish speak Spanish to each other on the bus and you overhear them, that's not "guerilla marketing" for Spanish by any useful definition.
Here's the thing: If you think of this point as "guerilla marketing" then C++ has been riddled with "guerilla marketing" for Rust for several years. Vittorio's (failed) Epochs proposal for C++ 20 more or less just says "Look, Rust has this cool feature [Editions], we should do that too".
Even I agree with all the rest, it's known that grass roots marketing is very strong in Google.
There are people who's job includes to write on high impact channels like HN to promote things.
The Rust hype does not come from thin air. It gets generated in part with the help of a lot of money in the background.
Of course this time the task isn't difficult as Rust sells itself in large parts just on the ground of it's features. But this process gets accelerated with money of course.
There are not much languages that made it purely by (or despite ;-)) their virtues.
One honorable exception is Scala. It made it into the Top20 even it does not have a marketing division, only a small team behind, and a community that seems to love to produce bad publicity consistently (even the language excels at quite some things!).
And there are cases like PHP, C, Objective-C (and for some likely, JS)… But let's not talk about those, …, historical accidents…
I have learned a great many languages (and forgotten some of them, a while back I was prompted to re-discover that last century I wrote a bunch of Scheme, my name is on the work and the timeline checks out but I don't remember it) over my lifetime. Rust is the first language where I want to go back and rewrite stuff in Rust because of how nice it is.
But I'm also quite excited by Rust lately.
But coming from Scala my feeling is constantly: Rust is missing so much still!
I would really like a language more like Scala but with the performance of Rust.
Of course other people get very excited when using Rust because for many this is the first proper language they've ever encountered.
But I'm quite unimpressed in general regarding "hyped" Rust features. I had immutable values, HOFs, ADTs, type-classes, pattern matching with exhaustivity checks, macros, and all that "since forever". But I miss HKTs, implicits, proper macros, and some other things in Rust. It will take at least a decade for Rust to catch up. But than Scala will be even farther away…
But OK, at least one can say that the ML family of languages is finally succeeding. (Scala and Rust are both descendants of ML).
In particular I want a stable niche (my nook crate uses the unstable niches because that's the only way to do it, the intent is to use a stabilised mechanism when one exists), I want a stable way to write const implementations of traits which aren't necessarily const (and thus const for loops) and on the same lines I want const panic.
A strong macro system is very dangerous. I use and like Rust's declarative ("By example") macros, and I appreciate the need for proc macros or other technology but it's very dangerous. Are Scala's macros somehow less dangerous? Or you just prefer how they work?
Rust has come a pretty long way since 1.0. Once upon a time u8::MAX couldn't exist. There was no way to express the idea that a type has an associated constant, so that's why std::u8::MAX is (deprecated but) there.
It's probably never going to be as comfortable to write Rust as Scala, but on the other hand it's definitely never going to be possible to deliver the performance of Rust in Scala.
Most of stuff Scala has fill me with dread. "proper macro", implicits, custom operator overloading, etc. Are extremely powerful concepts. Too powerful if you ask me.
They tend to make code utterly unreadable (without an IDE).
Why is `int` a `Date`? Don't know. Use an IDE.
What does the ~%+# operator does? ¯\_(ツ)_/¯ [2]
But I'm a bit conservative in language syntax. I'm against async and its in most languages already (it makes debugging more convoluted).
[1]https://lprakashv.medium.com/how-to-keep-your-sanity-working...
From [1]:
> While this can be really disheartening, this is not enough of a reason to move away from an amazing programming language, just because of a really abused feature!
Please also note: The blog post talks only about implicit conversions. That's actually the most uninteresting part of implicits. (Watch the video there to learn what implicits are actually for).
Also the post is about the old version of Scala. Implicits got redesigned in Scala 3. They're not even called implicits any more.
https://docs.scala-lang.org/scala3/reference/contextual/inde...
All problems mentioned in the blog post are solved. For example you can't import `given`s (like implicit definitions are called now) by accident. You need to do this explicitly. They got removed form the normal import scope.
Implicit conversions are btw. now heavily guarded, with very explicit declarations in form of a type-class instance & lang imports, besides the other changes that make application much safer so less surprises possible:
https://docs.scala-lang.org/scala3/reference/changed-feature...
But anyway, everybody know since years that you should not overuse them.
Also other languages like C# have this feature (and I'm not even talking about dynamic languages where this is the "normal" way everything works without safe guards by a static type system). Nobody ever complained about C# in this regard.
Besides that: The Rust people are looking envious. I've read about some ideas that were more or less a direct copy of Scala's implicits. And I'm quite sure, if Rust would introduce something like that most people would love it! Because it would solve some issues in Rust, and would also allow to remove complex boilerplate code.
Than, [2] is a pure obscurity. Never heard of.
But even the "WTF-operators" defined in this library look very strange (this is not usual Scala code!) I would not know without lookup what a `WLkUnDiEdge` is, even when spelled out…
And to stress it once more: This external lib is not part of Scala. Something like that wouldn't be ever accepted into the std. lib!
The BDFL wants to even remove unrestricted operator syntax. But I hope this does not happen as it would only make the language more complex for no gain. Someone who defines a `~%+#` operator would likely still do it even when you would have to write it as ` ~%+# `. So nothing won. [The operator method is written without the spaces around the back-ticks of course. But this does not render well here]
> Too powerful if you ask me.
If you don't like powerful languages with modern features I guess Rust is also not for you.
It wasn't my language by choice. Neither was the version.
> If you don't like powerful languages with modern features I guess Rust is also not for you.
I like Rust's pragmatism. Allow limited operator overload. Eschew HKT for a simpler abstractions. Don't go in the deep end with type power, nor too much in opposite direction and avoid any complicated feature.
The more powerful feature the more abusable it is, and Scala loves the power at all cost.
Why would anyone care? The more flexible/powerful something is the harder it will be to parse by humans and tooling.
Plus Scala has the big deal breaker. GC and no custom primitive types.
> Besides that: The Rust people are looking envious. I've read about some ideas that were more or less a direct copy of Scala's implicits.
What do you mean exactly?
Me too.
But Scala is also a very pragmatic language. If you want something academic go for Haskell.
> Allow limited operator overload.
Nitpick: Scala does not have any operators. So it doesn't have operator overloading at all.
Scala simulates operators by infix method syntax.
Instead of writing `1.+(2)` you can just write `1 + 2`. But the later is the same method call as the first one!
> Eschew HKT for a simpler abstractions.
AFAIK HKTs are more or less "just postponed" in Rust, AFAIK.
People would like to add them of course. The discussion goes on forever by now. Some small insight (there is much more when you look for it):
https://github.com/rust-lang/rfcs/issues/324
https://internals.rust-lang.org/t/higher-kinded-types-the-di...
> Don't go in the deep end with type power, nor too much in opposite direction and avoid any complicated feature.
While having a full ML style type system with afine types on top, and quite some other type level mechanics up to singleton types?
Sure sure, no power in here. :-)
> The more powerful feature the more abusable it is, and Scala loves the power at all cost.
Everything is "abusable". This is not an argument.
But that Scala loves power at all cost is simply not true. The contrary is.
Just to cite one of the most influential post in Scala land of all times:
https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL...
This, and the BDFL constantly complaining about unnecessary complex code people write speaks for itself.
Scala lately even reduced the power of some features just to prevent "abuse". (Which is partly an overreaction; but that's another story).
> Why would anyone care? The more flexible/powerful something is the harder it will be to parse by humans and tooling.
That's also not true.
Scala has a very small and simple syntax (despite all the language features).
Scala is on the surface much much simpler and much more regular then Rust!
https://github.com/e3b0c442/keywords
(You could also compare the language grammars. This would be even more in favor of Scala in this regard).
Scala 3 looks even almost like Python!
https://docs.scala-lang.org/scala3/book/scala-for-python-dev...
> Plus Scala has the big deal breaker. GC and no custom primitive types.
What a "deal breaker"?
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
You've seen this here in the thread?
Also:
https://docs.scala-lang.org/overviews/core/value-classes.htm...
As soon as Valhalla lands in JVM-land this will be full blown value types without any limitations.
And in Scala Native you can have of course native structs today. (Only that Scala Native isn't ready for prime time just now).
In the long run Scala Native could also run without GC. The Caprese project will bring something that is more powerful than Rust lifetimes. Lifetimes will fall out as a special case of a more general concept.
> > Besides that: The Rust people are looking envious. I've read about some ideas that were more or less a direct copy of Scala's implicits.
> What do you mean exactly?
Implicits get discussed every now and than in Rust land. Even the above Rust internals discussion start with them.
Or this here:
https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capa...
Also I've once read something that looked like a brain storming for future Rust features. They came up with more or less implicits (only that they didn't call them like that, so I can't find this any more, didn't bookmark it).
Someone even once proposed directly Scala's implicits for Rust. But this went nowhere as the other people on the forum actually didn't understand them (which was no wonder as the example was quite terrible and the proponent was not really experienced with Scala so couldn't explain it well). People came than to quite wrong conclusions (some of them even mixed implicits in general even the dreaded implicit conversions, which were in fact mostly overused and caused trouble in Scala; but things got redesigned exactly because of that).
The parent is not fanboying Rust much. Instead this looks like an interesting exchange of insights and opinions.
I actually want to learn why people seem to really like Rust even it's "just" like a "Scala light".
What was deemed "too complex" or "academic" in Scala is now everybody's darling in Rust. This is actually quite interesting.
I'm looking for hints how to resolve the marketing issue with Scala.
The other comment was meant more lighthearted and shouldn't be read out of context.
As does Scala.
Scala has even formal and machine checked proves for large parts of the language. Something that almost no other languages have. Especially no mainstream language.
> A strong macro system is very dangerous.
In which way? What do you mean exactly?
> Are Scala's macros somehow less dangerous?
Hard to say without knowing what is meant by "dangerous". :-)
But I guess you can judge for yourself:
https://docs.scala-lang.org/scala3/reference/metaprogramming...
The new meta-programming features are at least type safe.
(Also this is most likely the most advanced macro system out there. Fresh form top notch research, after many years of experimentation in the field).
> It's probably never going to be as comfortable to write Rust as Scala […]
As long as Rust doesn't change it's syntax (very unlikely) and adds a garbage collector (actually likely as there are some explorations already done in this direction) this will stay true, yes.
> […] but on the other hand it's definitely never going to be possible to deliver the performance of Rust in Scala.
I see no technical reason for that.
Rust doesn't do magic.
It just optimizes things quite well.
Key is aggressive erasure, specialization, and monomorphisation. Things that every compiler can do, if implemented.
Scala on the JVM can't do that really as this would break the expectations and semantics of the JVM. But Scala Native can do that!
It would "only" take someone to build this stuff…
Scala had already almost a quite advanced optimizer. But the dude who was building this left as soon as he got his PhD for that project and didn't finish it at all. Someone would need to pick up the remains and push this over the finish line.
As long as you would write code like in Rust (which is perfectly possible as Rust is kind of a subset of Scala) performance could be very close. (Of course you would need to avoid some features, like dynamic dispatch, and also excessive OOP patterns, but there is no technical reason why this shouldn't be possible at all).
Creating all the desugarings like the ones used in Rust would be of course some work. The optimizer that was almost there did not do that. It "only" optimized user level code, not the implementation of base types and build-in language features. (But still it could generate code that was en par with Java written by hand in the best possible way; the performance of such code is almost on the C level; the JVM suffers from issues with memory, not with performance, which is actually very competitive; there are even cases where the JVM beats C/C++ code regarding performance; but usually with one to two orders of magnitude more memory used). But like I said, Scala Native could take even one step further and optimize things in a way C/C++/Rust compilers do.
In case you missed Scala Native:
https://scala-native.org/en/stable/
Please bear in mind when comparing to something else: It's still pre v1.0 and still needs quite some love.
But it has partly better performance than GraalVM, and is much more stable than Kotlin Native (which is still alpha quality).
But for example the manual region based memory management in Scala (which can be used along the GC) would need improvement.
To keep up with Rusts borrow checker the whole capture checking stuff needs to land first; and this could take some time. But with this features Scala could do also completely without GC in the long run! (Only for dedicated "no GC code" of course).
https://www.slideshare.net/Odersky/capabilities-for-resource...
https://docs.scala-lang.org/scala3/reference/experimental/cc...
Yeah, so when I say strong, I don't mean the sort of minor nibbling Scala is doing in the linked metaprogramming feature or that C and C++ have in their "pre-processor".
The published nightly_crimes! procedural macro for Rust mostly "just" replaces your running compiler process with a new one that thinks it is compiling itself (or its standard library) and so it's allowed to provide the unstable nightly features even though it's a stable compiler.
But it's clear that if you said "Aha we fixed the compiler to stop that happening" Mara could write a new macro which finds say a WiFi connection, guesses your password, and uses it to download an actual nightly Rust build, and installs it so that it can replace the running compiler with that.
You can't stop Rust's proc macros from seizing control of everything and doing whatever they want, they're full blown code execution during your build process, that is what dangerous means. Rust proc macro authors must exercise extreme care as a result.
This is probably too much power, but when people talk about a "real" macro system they clearly are expecting less power than this, and so lets agree we're talking about a less powerful macro system, not a more "real" one.
The described issue gets actually neglected until now. It's like people are waiting that something happens (like just opening a project in an IDE installs malware. VSCode will at least ask whether is should trust build tasks. But nothing is in place for full blown code-gen through macro systems triggered by a mere compile).
As someone in the Scala community also pointed out once the code generated by macros or multi-stage compilation could do "anything", and some sandboxing mechanism would be required. But the discussion went nowhere. People just said you need to trust the code anyway…
In case the Rust community tackles this problem it would make also a nice reference for Scala. I think I should look how this is handled in Rust and maybe point to that in some discussion on the Scala forums.
Thanks for the pointer. I would agree that something like that is indeed dangerous!
Sadly, my Rust evangelism comes purely from the heart. I've been so impressed by the language -- how more than worthy it is as a replacement for C[++], how it managed to break the ancient yet false dichotomy of "fast but dangerous"/"safe but slow (garbage collected)".
I'm convinced that switching to Rust will lead to less losses in both dollars and lives (as in actual deaths) than C[++] bugs have and will continue to account for.
Heck, if someone spins up a bunch of GPT bots to flood every discussion with pro-Rust propaganda, I can practically read that activity as humanitarian.
I think the zealotry is due to people who have come to the same conclusions I have (and who probably know the pain of CMake vs. Cargo) rather than shady corporate Nakatomi space psyops.
If they have one thing in common is that they don’t want to invest in creating reliable products. They re-invent the wheel all the time, invent products that nobody wants and cancel them after a few years, create their own tools and languages and then shove them down everyone’s throat. They continuously churn new software, new features and updates because they don’t know when to stop growing, like tumors.
The software industry is a swindle. Rust is the band-aid solution to bad practices that companies don’t want to reform because it’s not profitable to do so.
Perhaps saying guerrilla marketing is being too lenient when it’s more like hustling and insinuating themselves in nearly all language discussions and trying to sell Rust. I’ve seen this in threads about C++, but also Go, Nim, C or even Python.
See the self-declared Rust programmer replying to the parent comment for a good example.
It doesn’t even matter if Rust is good, these people are as likable as pushy bazaar salesmen. If every time you wrote a comment here in English someone asked if you considered writing it in Spanish because it sounds more exotic, you’d get tired of that pretty fast.
If someone tries to "sell" their language I will start to sell "my" language, which is btw. Scala.
Have you actually seen the new major version of Scala?
Scala 3 is once again way ahead of the pack when it comes to modern language features!
Rust looks like a little stripped down (but fast!) toy in comparison.
Now you may beat me. ;-)
Google is using Rust on Android and Fuchsia.
Carbon is for C++ code that they can't write from scratch in Rust, given its size.
Azure Sphere SDK only supports C and Rust is now in preview mode. No C++ support planned.
So while it is decades away from reaching C++ adoption level, it isn't as if the big names aren't making use of it on key projects.
[0]:https://security.googleblog.com/2022/12/memory-safe-language...
> Safe by default: Val’s foundation of mutable value semantics ensures that ordinary code is memory safe, typesafe, and data-race-free. By explicit, auditable opt-in, programmers can use unsafe constructs for performance where necessary, and can build safe constructs using unsafe ones.
Versus Carbon:
> Carbon's premise is that C++ users can't give up performance to get safety.
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
It would of course be helpful if all the many, many, many, build systems for C++ have 'integrating sanitizers' in their "hello world" tutorials, rather than buried in some arcane man page.
However it isn't for it being there (VC++ can even do analysis per build), that people are rushing to adopt them after all these decades (lint was born in 1979).
So the social aspect matters a lot, and we keep losing there.
> So the social aspect matters a lot, and we keep losing there.
Unfortunately.
For example, there's a "cmake" starter on github, that is everything including santizers, but it is, frankly, inaccessible to newbies that just want to learn C++ "from scratch". Compare that to... Rust. You create a new crate from the cli in one command, and then you never have to mess around with the build system. Or even java/kotlin... `gradle init`... and you're mostly done. C++? "Spends 15 minutes reading "build system X" docs...".
Valgrind on the other hand, I struggle to imagine writing working C++ without it.
MSVC's stdlib has been open-sourced, and MSVC is used by plenty of companies writing games, native Windows software, etc.
If you look at the C++ versions being used across Apple's platforms, they are more than happy staying with C++17 (Metal Shading Language is even lower, based on C++14).
Almost everyone else seems to care only about LLVM, otherwise how to explain that LLVM gets almost as many contributions per year as the Linux kernel, while clang is lagging so much behind?
I've been using c++ for a while, and this comment is perhaps the best and funniest description of what I think about the language but was never able to put into words. Kudos for the laughs!
* absl strings provides the same compile-time guarantees that <format> does
* absl date/time libs have integrations with the proto time types
* google3 has many threading & synchronization primitives that it prefers over the STL types (all of which already has integrations with fleet-wide performance monitoring and other toolchain customizations, e.g. deadlock detection), so there isn't much reason to move the threading libraries forwardSo are C++ language updates.
What bothers me most about C++ is that it's mostly old people now. All the young people who are actively involved in language design, tool development, ... are putting their effort into other languages.
Or see how WinDev is so resistent to change, instead of providing .NET like tooling for C++, like Borland/Embarcadero have done for the last 25 years, they stick to their ways of manually editing IDL files and COM.
In 10 years, there won't be many people left working on C++ as a language and on the tooling.
And if it changes, so be it, I am not coding today as I was in 1986, when I typed my first LOAD "".
At least Microsoft started to do exactly this. They started to touch the Win API even to create Rust bindings. Because MS saw that this is the only way to future prove this stuff.
Other big players, like IBM, don't look like they're moving, though. But OK, IBM moves so slowly as a pitch drop falls. So maybe we just don't see them moving.
If you feel like C++/WinRT development experience is bad, good luck with Rust/WinRT.
And since it is the same team leads, which clearly have proven that they don't care about developer productivity, given how they have managed the C++/CX to C++/WinRT transition, I wouldn't wait too much out of it.
And I've heard rumors the Win team is an issue in general. (As the product they ship).
But they're at least moving. And the direction is clear.
The problem are people that don't want to change anymore. But this trait is independent form age in my experience.
But nevertheless, that C++ doesn't attract new developers may have reasons indeed. C++ refuses to get substantially modernized. In the long run such a stance will attract less and less people I think.
C++ would need a fresh start without all the baggage collected through several decades of backwards compatibility. A C++v2 is overdue, imho.
Only then it would find itself eventually competing with other new languages, without the current killer feature that reads "we can run ancient code". I'm not sure most people behind C++ are keen on such a challenge.
Nothing is wrong with old people. That's not what I was trying to say but people in their 50s or 60s will not be working for much longer. I don't think there will be many people left working __on__ C++ and its tooling in 10 years.
> But nevertheless, that C++ doesn't attract new developers may have reasons indeed. C++ refuses to get substantially modernized. In the long run such a stance will attract less and less people I think.
I think there are some pretty nice additions in the recent standards but all the backward compatibility is definitely a problem for the development of the language.
C++ is basically a "do it all" language and it feels like newer languages have rather specific use cases which they excel in.
I would also extrapolate this form how things look now.
But in a sense the language has deliberately chosen that way.
> C++ is basically a "do it all" language and it feels like newer languages have rather specific use cases which they excel in.
Yes, I also see this.
I'm not really happy with that as I think it's easier to learn one "real general purpose language" properly than have shallow knowledge in two dozens of glorified DSLs.
But C++ isn't this language for me either. I personally would love to see Scala (v3) to become a better general purpose language. It's modern with a lightweight syntax, it's powerful (up to compile time verification of your code), it can embed all kinds of DSLs (which makes dedicated external DSLs superfluous), now it starts even to "run everywhere", but it's slow(er) and fat(er) compared to C++, Rust, and the other contenders in some very important areas, which sadly rules it out for many tasks.
Agreed, which is a pity but it is what it is.
> But C++ isn't this language for me either. I personally would love to see Scala (v3) to become a better general purpose language. It's modern with a lightweight syntax, it's powerful (up to compile time verification of your code), it can embed all kinds of DSLs (which makes dedicated external DSLs superfluous), now it starts even to "run everywhere", but it's slow(er) and fat(er) compared to C++, Rust, and the other contenders in some very important areas, which sadly rules it out for many tasks.
I have been doing C++ for the last 6 years now for scientific computing so safety wasn't the first priority, but chasing pointers while debugging is certainly no fun.
Recently, I have been getting into Rust and I really like what I have seen so far, at least for my use cases.
At least GCC has Red-Hat supporting ISO C++ improvements.
[0] - ARM, Intel, Embarcadero, IBM, NVidia, IBM, Nintendo, Sony,...
Also AFAIK IBM is one of the most dedicated supporters of C++ in general.
Not in what concerns ISO C++ support, and if it was up to IBM, trigraphs would still be supported.
See what ISO version their xl compilers support, across all mainframe, Aix and Linux deployments.
Even that's true, it's now IBM's money that gets invested.
> Not in what concerns ISO C++ support, and if it was up to IBM, trigraphs would still be supported.
I know about the trigraphs. That they were fighting for that shows imho exactly that IBM is heavily invested in C++. They have a shitload of old but hightly important code that can't be migrated realistically.
So IBM will keep throwing money on C++ to extend its live infinitely, I guess.
As someone much more experienced in other languages like Python and Swift, my biggest surprise when using C++ is that the language standard and the compiler are two different things. In Python, the default CPython interpreter is the standard - if it's not in CPython, it's not standard Python. But in C++, there's like 3 different compilers, all of which implement different subsets of the latest C++ standards. IIRC, the latest standard that all compilers implement fully is C++ 14. I understand C++ is a broad and complicated language, and I actually have liked using it in the few times I've had the chance, but the compiler/standard situation seems like complete lunacy from where I stand.
Yes, that's because C++ is a formally standardized language, and Python and Swift are not. C++ is an ISO standard, and it is published in text form. You are free to create your own compiler, and if it works according to the rules written in the official standard, you may call it a standard-conforming compiler. There are of course other languages which are also officially standardized like this (does not have to be ISO), for instance Common Lisp, Scheme and of course Javascript (ECMA). If a language is defined by a reference implementation, then this is an informal way of standardizing your language, and if you want to create your own compiler/interpreter for such a language, you have to carefully evaluate what the reference implementation does.
> I understand it has to do with breaking ABI, but what exactly does this imply?
Very roughly, it means that you cannot link object code with the current ABI with object code that was generated by older compilers with the old ABI (well, it's usually worse: you can link just fine, but your program might or might not crash). This is not unprecedented in C++, we had this when switching from gcc4 to gcc5, it was definitely pretty painful and I'd rather not have this again.
The C++ standards committee is a body of people from different backgrounds, different companies and different needs from C++. Moreover, they kind of have to cater to everybody. There may be people programming microcontrollers, there may be game developers, there may be people supporting/porting decades-old software which uses old versions of Qt, there may be people wanting all the modern bells and whistles in C++, and there may be people using pre-compiled third-party libraries from a long gone vendor or vendor not willing to upgrade their compiler.
These needs may contradict each other. ABI (Application Binary Interface) in C++ can be thought of as a `.pyc` file in Python. You don't expect _any_ compatibility of `.pyc` files between Python versions, so all libraries are distributed in source code in `.py`, and it's up to Python to process them into `.pyc` files as it wants. In C++ world, lots of libraries (including all OS libraries, actually) are distributed in a pre-compiled binary form only. The way your program interacts with the library is the ABI. If you upgrade your compiler, but the library does not, you can no longer use the library.
One example is the memory layout of standard library types. E.g. a release version of `std::vector` (the standard dynamic array container) may only need three fields: a pointer to the allocated memory, maximal capacity of the vector, and its current size. A debug version may also include stuff like "where this vector was created". If one part of your program (or an external library) expects a vector to be 24 bytes and have such and such fields, and another part expects something else, Everyone Dies(tm). To make things worse, everything breaks silently: there are little to no checks for ABI compatibility, and reading a byte almost always works.
As to why the standard is affected by this, even though "ABI" is not mentioned anywhere in the text: you cannot add/remove fields or virtual methods within the standard library in the next standard. If you do, the newer standard library _must_ become incompatible with all the pre-compiled code expecting the older version. (Almost) no way around it. A similar thing in Python would be if one has tried to use both Python 2 and Python in the same project simultaneously, in the same process.
So if everyone starts building all their code and dependencies from the source code, there will be no ABI concerns anymore. I don't see it happening any time.
> IIRC, the latest standard that all compilers implement fully is C++ 14.
Not even than, garbage collection from C++11 was never implemented by any compiler: https://en.cppreference.com/w/cpp/compiler_support/11
Not a big problem though, as it's never used by anyone. I've heard of people using non-standard garbage collection extensions instead, long before C++11. That's another thing with the standard and compilers: not everyone needs every feature, so some are given a priority depending on the compiler's users. And there are lots of existing solutions which probably won't be migrated to the standard.
Anyone using Unreal C++, Managed C++ (.NET 1.0) or C++/CLI (.NET 2.0 onwards).
Tiobe is outright nonsense.
Citing it (besides jokes) is usually a sign that you can't trust the source that does so in the first place. Really everybody should know (at least for the last few years) that the Tiobe index is just completely made up nonsense.
s/no one/I/And everybody who doesn't do so really deserves the pain that results later on.
Such suppression are than big warning signs in the code telling you that something exceptional is going on which needs extra attention when touched.
Also warnings may be wrong. Errors mustn't be and can't be as strict as warnings therefore.
But it shouldn't be possible to "just ignore them". If you do, this needs to be done deliberately and explicitly.
But I see, you're not interested in correcting the bugs you produce. You obviously prefer the "three-monkeys solution" to correctness problems.
It's a good general practice, as long as exceptions can be made.
Some compiler warnings are rooted in the compiler being unable to prove something that is actually true.
I want good practices to be the thing people actually do!
Nope. Not waiting for that. Does not mean I am using or ever will every feature. However if it exists and being used by others I have nothing against it.
But indeed, these things can't be removed or reworked without breaking backwards compatibility. (And if you seriously take on reworking them, you'll end up with a different language, which we already have several.)
... huh? i'm fairly confident dereferencing void is not valid C++ ; at the very least gcc/clang/msvc do not compile it: https://gcc.godbolt.org/z/hK6qb1z6o
I am just worried that some proponents of "move fast and break things" might be undervaluing what they are breaking, although C++ committees are are generally good about backward compatibility.
If the only side effect of breaking backwards compatibility is making the people that write C++ as if it was C89 irritated and upset, then that's probably a good thing, let's do it more.
C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will.
If you are using ancient C++, compiler security updates are the least of your security concerns.
If you have code that nobody understands and cannot be touched, you should see that as the real problem and an urgent call to action to fix it, not modernization.
That doesn't make it a dead codebase. New code still gets written - and it helps when it can be written using newer, better techniques while working nicely with old code. I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP.
Sounds like pure joy.
OTOH if we tried to rewrite the whole thing from scratch, we wouldn't ship a new feature for many years - only new bugs.
For example, if you port numeric libraries are you sure you maintain the same guarantees for numerical stability? If you are porting containers, do your new backing-array growth strategies achieve the same efficiency as using realloc? Do your new threading primitives have equivalent efficiency on all of the target architectures?
I would prefer to have warnings, or even errors, for 'known bad behaviour' that are enabled by default with new standards - think along the lines of `-fpermissive`. Forcing people to suppress these means that the onus is on them to accept the risks their choices bring.
However, just as with things like void*, the new standards are bringing in their own footguns. Ranges have pointer semantics, not value semantics, for example, which is totally non-obvious and actually means a lot of use cases for ranges just aren't possible. Newer isn't necessarily better, the people writing the original standards were brilliant as well and had their own insights which we now forget.
But your test suite would catch any issues, wouldn't it?
You have an exhaustive test suite for your important numeric libraries, right?
> If you are porting containers, do your new backing-array growth strategies achieve the same efficiency as using realloc? Do your new threading primitives have equivalent efficiency on all of the target architectures?
The benchmarks suite, which is part of your exhaustive test suite, and is guarding against performance regressions would catch any issues for sure!
You have a benchmarks suite to protect against performance degradation, right?
> You have a benchmarks suite to protect against performance degradation, right?
In theory, in a perfect world, yes.
In practice, people use open source libraries like Eigen because they are the best, not because of their extensive test coverage. Doing things which might break these libraries will fork the community.
Only because something spits out numbers really fast doesn't say anything about the quality of this something. Especially when considering that optimizing for speed comes most times with very hacky code! This, plus the fact that this code is usually written by laymen (scientist aren't software engineers!) makes such things very questionable.
After looking into scientific computing and the usual software "quality" there I lost quite some trust in anything that comes out of there. This was actually very disillusionary and extremely sad to find out. This could even destroy the broader trust in science in general (as everything today in this field depends on statistics calculated by computers). This would be an catastrophic outcome! But most people would currently even deny the existence of an issue…
Related (together with the parent): https://news.ycombinator.com/item?id=34224186
Also related as people (scientists!) got blinded by the promise of speed without considering correctness:
A house of cards… :-(
This is why subtle compiler rule changes are so potentially devastating.
It seems you know better than the C++ standard committee and Bjarne Stroustrup anyways.
And yes, you shouldn't use realloc... but what should you do if your buffer size is more than half of your physical memory?
I know this won't be applicable in many cases regarding C++ projects, but if you want to see state-of-the-art code gen features in action have a look at Scala 3:
https://docs.scala-lang.org/scala3/reference/metaprogramming...
With something like that in place you actually don't need any (runtime) reflection (which is also available on the JVM OOTB, just in case).
In contrast quotes and splices aren't reflection at all! The whole point about them is that they're "black box". You (usually) can't "extract information" form a quote in a safe way (so it's the exact contrary to reflection). That's still something academia is trying to solve (even there are some proposals out)¹.
Where can I learn more about the C++ proposals to compare?
---
¹ https://dl.acm.org/doi/10.1145/3136000.3136005
¹ https://dl.acm.org/doi/10.1145/3158101
And the recent work that underlines the solution included in Scala 3:
¹ https://se.informatik.uni-tuebingen.de/publications/stucki21...
I mean, that's just because many languages don't even have a compile-time so of course reflection can only be runtime. Every compiled language has at least some amount of extremely basic concept of compile-time reflection, e.g. sizeof in C for instance which yields a constant expression ; likewise, `if constexpr(std::is_same_v<T, some_other_type>) { ... }` which we can do since C++17 is very much in the domain of compile-time reflection.
Here's the most recent paper: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p12...
If you want this is a very good read: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p07...
Finally, there is an implementation of the reflection TS: https://clementpirelli.wordpress.com/2021/12/08/cpp-reflecti...
It's not always easy to find the relevant stuff in C++ land.
Thanks a lot!
I have to read this stuff first, but my gut feeling would still be that `constexpr` and such isn't reflection at all.
The `sizeof` example seems more in this direction (because some expression gets actually inspected).
e.g.
void f(auto x) {
// common code path
if constexpr(x is floating-point) {
// code path 1
}
else if constexpr(x is a string) {
// code path 2
}
// common code path
}Thanks for the pointer.
OTOH Kotlin, while popular, is still tiny compared to Java. Except for Android, which is a bit of a special case because mobile platforms generally have smaller codebases and shorter app lifecycle due to forced API breakage by the platform.
Strange conclusion.
For me it looks like C++ has chosen to become exactly this. The only reason it's still relevant is all the legacy code. Almost no new projects get started in C++. So it looks like they double down on that.
> Its continuing popularity in game development is just one of the areas that could see enormous growth and evolution.
I don't see this. Game dev is also moving.
The most popular engines may be written in C++, because there was no choice as this projects started. But the games made on those engines are mostly not written in C++.
Most code in games is "script like". And it's even often written in scripting languages. When not, it's something like C#, or some other more modern high level language.
I don't have a crystal ball but there are important differentiating factors: C++ is much more capable and it is relevant in more diverse domains whereas COBOL was very confined.
> Game dev is also moving
There are several new ECS projects implemented in C++ that have enthousiastic following.
My hunch is that it is still up to the C++ world to lose it entrenched position by not doing the right changes but maybe that won't be the case in a few years from now.
Would you mind to share?
I'm currently looking into game dev. Would be nice to have a better picture of the landscape.
its just a data point that C++ has constituencies that have not given up on it yet.
[0] https://github.com/topics/ecs?l=c%2B%2B&o=desc&s=forks
But the two bigger projects don't contribute to the argument actually.
This flecs (which looks very interesting on first sight!) is a C project with C++ API bindings on top as I see it. The other one is a Godot library (which I have to examine closer as I'm specifically looking into Godot).
The collection of GitHub project looks mostly like engines. So not really games as such. (Also I'm not sure how recently those projects where started. There was no real alternative to C++ for game engines for a long time. So all older projects are likely C++. This does not prove the point that anybody would grab C++ today).
maybe next year ..
People often talk about Bjarne Stroustoup as if he was a BDFL, while in reality he only has one vote from those 200 plus.
Welcome to standard body processes.
A case of "brilliant coder wants to make game but don't know art well, so they create new complicated programming tasks instead", but, the brilliant coder part is still pretty relevant.
To you. Meanwhile many of us who do need it are stuck with buggy half implemented code generation tools.
But there is (almost) no use for runtime reflection when you have proper compile time features.
Of course this is something one can only find out when using a language with those features.
But now I'm curious: What do you concretely need (runtime) reflection for? Maybe it's indeed one of the very rare cases where one would really need runtime reflection.
The idea that you’d rely more on tools is in a sense the Java approach. Java is somewhat more verbose than other languages, in practice, and you deal with the verbosity by making more use of code snippets / templates, autocompletion, etc. Basically, your IDE writes more of the code for you. I think this was, in general, a dead end in language research for various reasons, and improving code generation (via ChatGPT or some successor) does nothing to solve the actual problems with using generated code.
At the end of the day, somebody has to at least read the code and verify that it does what is requested.
Maybe at some point, someone will hook a more formal front-end to ChatGPT or something similar, so you can write the interfaces and specs, and the AI will generate the implementation. That may take a while, however.
I think language researchers would strongly disagree.
Something like that is likely the future of programming!
For example:
https://www.youtube.com/watch?v=X36ye-1x_HQ
From the video description:
> In Idris, types are a first class language construct, meaning that they can be manipulated and computed like any other language construct. It encourages a type-driven style of development, in which programmers give types first and use interactive editing tools to derive programs.