> 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.
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 would consider whether people like writing it to be a virtue, so I would argue that the widespread love for Rust is, in fact, an example of a language thriving on virtue.
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 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).
Sure, lots of things would be nice to have in Rust that aren't done yet. Some of them you can see in nightly, because their rough shape exists but isn't stabilised. Rust is taking things rather steady because of a strong preference for soundness.
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).
> 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.
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:
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.
> Also the post is about the old version of Scala.
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.
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.
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).
> Rust is taking things rather steady because of a strong preference for soundness.
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". :-)
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.
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).
> Hard to say without knowing what is meant by "dangerous". :-)
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!
Dang, I should've been collecting paychecks this whole time!
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.
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…