I think the most interesting thing about C++ in 2022 is that big C++ names at Google are saying in public that if you can use Rust instead of C++, you should.
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
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.
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.
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
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.
> 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...
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...