Great Talk, I could not agree more. Been using Scala since 2012 exclusively and I'm playing with Rust for the past year. Scala + ZIO2.0 always will be much more enjoyable and fun. Using Rust is rather necessary for me due to high demand.
Me too. I know Scala 2 (not as much as Java). I don't care about FP very much as long as the code makes sense. So for me, Scala + libs like zio/cats don't give much more values than Java 21. That's why I switch to Rust.
If Rust can replace Scala for you, you haven't really needed Scala in the first place. And if using Rust doesn't "cramp your style", you probably have pretty simple usage patterns. Sure, Rust gives you low-overhead code, if you pay the cognitive-load price. All in all, Scala native will kick Rusts sorry ass soon, while Rust can't dig itself out of the hole it enthusiastically dug for itself. Slightly (mostly) better C++, that Rust is. Contender for Scala (or Haskell) -- it won't ever be.
Great talk! I have been doing Scala for 10+ years and love the basic language, but I agree that the continuous movement/"improvement" is a huge problem. Loved the Feeding the Mathematician section! :-)
John hits the nail on the head: "A good IDE is extremely important to attract that commercial software developer..." at 36:33. Over the years I've been using Scala, I could never get any development environment working properly 100% of the time. With C/C++, Rust, Haskell, I can fire up vi or emacs and be productive in no time at all. That's got to be one of the greatest weaknesses of the Scala ecosystem (and not the Scala language itself).
Pragmatist here: Correct me if I am wrong but as far as I can tell Scala has the following to learn from Rust: 1) It has to learn to work with out the JVM (or any kind of run-time system). Requiring the JVM implies bloat and poor performance. That excludes use of Scala from much of the work I do. 2) It has to learn to work without a garbage collector. A garbage collector introduces unpredictability in performance. It also excludes use of Scala from much of the work I do. 3) It has to learn to run in only kilobytes of code space on micro-controllers and the like. 4) It has to learn that maths is great and all, but maths is limited. Maths does not have a solution for the many body problem, for example. As for monoids, I had them surgically removed as a child.
I love scala. But I’ve been annoyed for a long time that no there is no clear and visible Value Prop. wanna do Spring? Choose Java/Kotlin. Wanna do Android? Kotlin. But what about Scala? Is it spark? Nah, not anymore. Great talk! And what a great loss for the scala community to see you go. But relatable
I love Scala, too. I maintain several Play Framework applications. And suddenly Lightbend has abandoned the Play Framework. For a long time it was also uncertain whether there would be a new version for Scala 3. That doesn't make it any easier.
“Killer feature” used to mean that it was ahead of the game compared to other alternatives That’s not the case here, so it’s not really a killer feature. Most devs that are pushing wasm hard, like in game jam for example … choose non-rust tools, because they are generally better at doing wasm work
What do you think about safe asynchronous processing as the direction for Scala? This pulled me into learning Scala. Now I value that I'm not limited to some specific domain like server-side programming which is the case for Go or PHP. Scala allows me create a UI, use an ML library through Java. Actually I need a glue language with safe concurrency. Can Scala move in this direction?
@@avalagum7957 I mean some years ago Bartosh Milevski said that FP solves the problems of asyncronous computing. As far as I remember it was about sharing mutable state in concurrent computations. There are lots of examples in literature on this subject.
The Scala community over the years built the mindset that Scala is for mathematicians who love purism of category theory. In reality, you can find literally several hundreds of while loops in the standard library, and so: you should not be expelled from the room if you prefer to employ a simple and efficient while loop instead of an over engineered trampoline. Unfortunately, the vast majority of FP libraries make simple things complicated and make complicated things impossible.
Scala is far more interesting as a language than 99% of the tasks out there you are supposed to do. You can spend days on end lovingly pondering about higher-kinded types and tagless final while all the bosses want is a f.... report. So naturally, people already bored by the intellectual void of most commercial programming, started to play around in Scala. Scala lets you do that. It encourages intellectual curiosity. Also naturally, businesses didn't like that. They need boring languages that suit there boring needs, to be solved with boring programming. That is the most significant Value Prop that Scala could never deliver. And likely never will.
John tweeted about this in the past. I believe he feels it’s too disruptive to gain adoption, because it requires almost everything about software development to be rethought
Brutal and honest talk. I will say that Caprese might actually bring us closer to Rust's way of lifetimes and memory safety which in turn would enable multi-targeting of platforms.
A great talk. I've just started re-learning Rust, going into my head much easier this time, many similarities with Scala (I have 14 years Scala) A friend of mine said that Scala was "Ruined by FP weirdos". I have to agree, too many academics
Interestingly, I tried Rust and I don't like it. I especially was annoyed with the little nuances that the borrow checker&ownership model demanded me to do. I learnt that I like GC. I have to add that I don't need super fast programs either. It is enough if the program that I write can be scaled horizontally. Also Rust enforces to treat structs in a mutable way. Although these things were not as bad as the async programming which is tragically complicated in Rust. It was horrible and make my life miserable. Mutexes, RwLocks, Arc, moving etc. makes the code tragically noisy and complex. Also you need a library to have async traits. Not to mentioned that async programming is a real red color in Rust therefore. I don't like red colors in my code. If you write sth in a single threaded way and then you have to mark every function call async (plus call await on them) to make it concurrently computed is a nightmare IMO. ZIO in Scala shows how good it is if we don't have but just minimal coloring for concurrent/parallel programming. So I like Scala, Ocaml/F#, Haskell and Elixir much more than Rust and I learnt this in a couple of months. So should we say I spent too short time to understand/switch to Rust "paradigm"? Maybe yes. However, when I spent even less time learning Haskell and Elixir, I fell in love with them easily. This doesn't mean that Rust doesn't have pros. I have seen a lot. It is just not as good as it is hyped and I feel that around Rust this is rather therefore just a hype, because we like to learn new things and borrow checker&borrowing entertain us for a while. However I think it is a hype especially because Rust can replace system programming languages like C and C++ admittedly. But what does that do with us Scala devs? Can Scala learn from Rust? For sure. But not async programming for sure. If you need pragmatic language that we can learn from, then it is rather Elixir where everything is immutable by default, where the pattern matching is on another level. It is super pragmatic. I know, it is a dynamically typed language yet still I like its language features much better than Rust's.
Always working Scala IDE and focus on industry is all what Scala eco-system needs. As for mentioned weaknesses: what is wrong with SBT? It works fine, no problem with it. Also, I do not know anyone who is calculating sum of elements in pure collection using Monoid type class like John did. He is exaggerates. He created one more FP eco-system like ZIO and then saying there is no consensus in libraries world )))))))))))))
We already have what industry needs: two IDEs, two build tools, libraries index, conferences, forum and central org like Scala Center. What else you need to be happy in industry?
@@alex50922 But the IDEs are not rock solid, SBT is a huge mess that's hard to develop an intuition of how to work with so people are copy-pasting stuff all the time (unless you have some simple build). Yes, there are libs but they are maintained by volunteers. all of this makes Scala seem amateurish. It's no wonder then, that companies prefer to develop mobile apps in Kotlin, do ETLs and ML in python with py-spark, do system-level programming with Rust and do web servers in Java/Kotlin.
I believe firmly that Scala will die out in the next couple of years. It's an academic language, not a commercial one. From a business perspective, It is not worth it.
Great Talk, I could not agree more. Been using Scala since 2012 exclusively and I'm playing with Rust for the past year. Scala + ZIO2.0 always will be much more enjoyable and fun. Using Rust is rather necessary for me due to high demand.
that's the thing
This actually inspired me to check out Rust, great talk John 😊
Rust? Ehhhhh.
Me too. I know Scala 2 (not as much as Java). I don't care about FP very much as long as the code makes sense. So for me, Scala + libs like zio/cats don't give much more values than Java 21. That's why I switch to Rust.
If Rust can replace Scala for you, you haven't really needed Scala in the first place.
And if using Rust doesn't "cramp your style", you probably have pretty simple usage patterns.
Sure, Rust gives you low-overhead code, if you pay the cognitive-load price.
All in all, Scala native will kick Rusts sorry ass soon, while Rust can't dig itself out of the hole it enthusiastically dug for itself.
Slightly (mostly) better C++, that Rust is. Contender for Scala (or Haskell) -- it won't ever be.
Great talk! I have been doing Scala for 10+ years and love the basic language, but I agree that the continuous movement/"improvement" is a huge problem.
Loved the Feeding the Mathematician section! :-)
John hits the nail on the head: "A good IDE is extremely important to attract that commercial software developer..." at 36:33. Over the years I've been using Scala, I could never get any development environment working properly 100% of the time. With C/C++, Rust, Haskell, I can fire up vi or emacs and be productive in no time at all. That's got to be one of the greatest weaknesses of the Scala ecosystem (and not the Scala language itself).
Pragmatist here: Correct me if I am wrong but as far as I can tell Scala has the following to learn from Rust:
1) It has to learn to work with out the JVM (or any kind of run-time system). Requiring the JVM implies bloat and poor performance. That excludes use of Scala from much of the work I do.
2) It has to learn to work without a garbage collector. A garbage collector introduces unpredictability in performance. It also excludes use of Scala from much of the work I do.
3) It has to learn to run in only kilobytes of code space on micro-controllers and the like.
4) It has to learn that maths is great and all, but maths is limited. Maths does not have a solution for the many body problem, for example.
As for monoids, I had them surgically removed as a child.
I love scala. But I’ve been annoyed for a long time that no there is no clear and visible Value Prop. wanna do Spring? Choose Java/Kotlin. Wanna do Android? Kotlin. But what about Scala? Is it spark? Nah, not anymore.
Great talk! And what a great loss for the scala community to see you go. But relatable
I love Scala, too. I maintain several Play Framework applications. And suddenly Lightbend has abandoned the Play Framework. For a long time it was also uncertain whether there would be a new version for Scala 3. That doesn't make it any easier.
Excellent! Mark Odersky should think about it.
Rust's killer feature is the great wasm support - all languages that don't have that will be left behind in a very very near future
“Killer feature” used to mean that it was ahead of the game compared to other alternatives
That’s not the case here, so it’s not really a killer feature.
Most devs that are pushing wasm hard, like in game jam for example … choose non-rust tools, because they are generally better at doing wasm work
Crisp and awesome analysis. Was a joy to listen! Keep it up! Love the bridge between tech but also entrepreneur and and business thinking
What do you think about safe asynchronous processing as the direction for Scala? This pulled me into learning Scala. Now I value that I'm not limited to some specific domain like server-side programming which is the case for Go or PHP. Scala allows me create a UI, use an ML library through Java. Actually I need a glue language with safe concurrency. Can Scala move in this direction?
yes for sure it can and it will
As for me Scala’s domain today indeed is a glue language with safe concurrency
Could you give an example of unsafe asynchronous processing? With languages like Java, Scala, I think it depends on how you write your code.
@@avalagum7957 I mean some years ago Bartosh Milevski said that FP solves the problems of asyncronous computing. As far as I remember it was about sharing mutable state in concurrent computations. There are lots of examples in literature on this subject.
The Scala community over the years built the mindset that Scala is for mathematicians who love purism of category theory. In reality, you can find literally several hundreds of while loops in the standard library, and so: you should not be expelled from the room if you prefer to employ a simple and efficient while loop instead of an over engineered trampoline. Unfortunately, the vast majority of FP libraries make simple things complicated and make complicated things impossible.
Scala value prop (for me at least): write reliable concurrent code on the JVM, easily.
Scala is far more interesting as a language than 99% of the tasks out there you are supposed to do.
You can spend days on end lovingly pondering about higher-kinded types and tagless final while all the bosses want is a f.... report.
So naturally, people already bored by the intellectual void of most commercial programming, started to play around in Scala. Scala lets you do that. It encourages intellectual curiosity.
Also naturally, businesses didn't like that. They need boring languages that suit there boring needs, to be solved with boring programming. That is the most significant Value Prop that Scala could never deliver. And likely never will.
I agree 100%
39:10 Isn't Scala.JS very much integrated in Scala?
Any pointers that explain his negativity towards Unison?
John tweeted about this in the past. I believe he feels it’s too disruptive to gain adoption, because it requires almost everything about software development to be rethought
i am learn a lot from scala to understand rust
Terrific talk!
Why?
Brutal and honest talk.
I will say that Caprese might actually bring us closer to Rust's way of lifetimes and memory safety which in turn would enable multi-targeting of platforms.
Thank you John! a great and inspiring talk
nice talk
A great talk. I've just started re-learning Rust, going into my head much easier this time, many similarities with Scala (I have 14 years Scala)
A friend of mine said that Scala was "Ruined by FP weirdos".
I have to agree, too many academics
not expressive enough to be Agda, not flexible and efficient enough to be C, not readable enough to be Python, and not linear enough to be Rust.
ruclips.net/video/hIssqESXgfI/видео.html 🤣
@@clementdato6328Python is readable? Lmao
> A friend of mine said that Scala was "Ruined by FP weirdos"
I think I agree with this.
Interestingly, I tried Rust and I don't like it. I especially was annoyed with the little nuances that the borrow checker&ownership model demanded me to do. I learnt that I like GC. I have to add that I don't need super fast programs either. It is enough if the program that I write can be scaled horizontally. Also Rust enforces to treat structs in a mutable way. Although these things were not as bad as the async programming which is tragically complicated in Rust. It was horrible and make my life miserable. Mutexes, RwLocks, Arc, moving etc. makes the code tragically noisy and complex. Also you need a library to have async traits. Not to mentioned that async programming is a real red color in Rust therefore. I don't like red colors in my code. If you write sth in a single threaded way and then you have to mark every function call async (plus call await on them) to make it concurrently computed is a nightmare IMO. ZIO in Scala shows how good it is if we don't have but just minimal coloring for concurrent/parallel programming.
So I like Scala, Ocaml/F#, Haskell and Elixir much more than Rust and I learnt this in a couple of months. So should we say I spent too short time to understand/switch to Rust "paradigm"? Maybe yes. However, when I spent even less time learning Haskell and Elixir, I fell in love with them easily.
This doesn't mean that Rust doesn't have pros. I have seen a lot. It is just not as good as it is hyped and I feel that around Rust this is rather therefore just a hype, because we like to learn new things and borrow checker&borrowing entertain us for a while. However I think it is a hype especially because Rust can replace system programming languages like C and C++ admittedly. But what does that do with us Scala devs? Can Scala learn from Rust? For sure. But not async programming for sure.
If you need pragmatic language that we can learn from, then it is rather Elixir where everything is immutable by default, where the pattern matching is on another level. It is super pragmatic. I know, it is a dynamically typed language yet still I like its language features much better than Rust's.
34:10 scala-cli is probably much better than cargo
Always working Scala IDE and focus on industry is all what Scala eco-system needs.
As for mentioned weaknesses: what is wrong with SBT? It works fine, no problem with it. Also, I do not know anyone who is calculating sum of elements in pure collection using Monoid type class like John did. He is exaggerates. He created one more FP eco-system like ZIO and then saying there is no consensus in libraries world )))))))))))))
It's an illustration of how Scala is moving toward more and more academic features rather than improving the things that the industry needs.
We already have what industry needs: two IDEs, two build tools, libraries index, conferences, forum and central org like Scala Center. What else you need to be happy in industry?
@@alex50922 But the IDEs are not rock solid, SBT is a huge mess that's hard to develop an intuition of how to work with so people are copy-pasting stuff all the time (unless you have some simple build). Yes, there are libs but they are maintained by volunteers. all of this makes Scala seem amateurish. It's no wonder then, that companies prefer to develop mobile apps in Kotlin, do ETLs and ML in python with py-spark, do system-level programming with Rust and do web servers in Java/Kotlin.
Great trolling, none of these are trully a problems of Rust, those are issues with Scala.
Rust ❤
I believe firmly that Scala will die out in the next couple of years. It's an academic language, not a commercial one. From a business perspective, It is not worth it.
I firmly believe that time will force you to choke on your willy-nilly assertion.
Long live opinions, i guess :-/