What's Next for Scala(lihaoyi.com)
lihaoyi.com
What's Next for Scala
http://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala.html
202 comments
Here's a great talk given by Martin Odersky, "A Tour of Scala 3" https://www.youtube.com/watch?v=_Rnrx2lo9cw
That talk is almost a year old now :) a lot of progress has been made towards launching Scala 3. The latest Dotty release was March 18 https://dotty.epfl.ch/blog/index.html
Scala 3 combined with Scala.js and GraalVM native compilation will be a killer stack :). You can write code that's as high level as python and typesafe as Haskell. Use the same code on the backend and in-browser with Scala.js. Compile your code to statically linked native executables with instant startup time, great for CLI tools.
In terms of developer experience, Scala 3's compiler is much faster than Scala 2 because the data structure representing incremental compilation is not rebuilt for each compiler phase. The faster compiler can be used with Microsoft's Language Server for a delightful IDE experience, especially in VS Code which is the current recommended editor for Scala 3.
That talk is almost a year old now :) a lot of progress has been made towards launching Scala 3. The latest Dotty release was March 18 https://dotty.epfl.ch/blog/index.html
Scala 3 combined with Scala.js and GraalVM native compilation will be a killer stack :). You can write code that's as high level as python and typesafe as Haskell. Use the same code on the backend and in-browser with Scala.js. Compile your code to statically linked native executables with instant startup time, great for CLI tools.
In terms of developer experience, Scala 3's compiler is much faster than Scala 2 because the data structure representing incremental compilation is not rebuilt for each compiler phase. The faster compiler can be used with Microsoft's Language Server for a delightful IDE experience, especially in VS Code which is the current recommended editor for Scala 3.
Interesting you refer to C++. Both languages, IMHO, became too big to be practical. You need to, as a team, choose a subset of C++ (or Scala) and a style for it to become manageable.
I dont think this looks good on a language, I prefer a language that comes with a small, concise set of features that are broadly understood and applied. But different folks different strokes.
I dont think this looks good on a language, I prefer a language that comes with a small, concise set of features that are broadly understood and applied. But different folks different strokes.
I would disagree here. Scala's language spec is smaller than javas, it's problems are akin to Lisps. Too many dsls, extensions and so on. It really opened the doors for FP concepts to go mainstream. Unfortunately, some people went way too far with it.
Brainfuck's spec fits in one page. As does Whitespace's spec.
These two languages are impossible to write code in because of their complexity.
It's completely mystifying to me that even today, Martin still uses the "spec size" argument in his keynotes to attempt to demonstrate that Scala is a simple language, and it demonstrates a complete ignorance of what language design actually is, or a troubling disingenuity meant to deceive.
These two languages are impossible to write code in because of their complexity.
It's completely mystifying to me that even today, Martin still uses the "spec size" argument in his keynotes to attempt to demonstrate that Scala is a simple language, and it demonstrates a complete ignorance of what language design actually is, or a troubling disingenuity meant to deceive.
The intention should matter. Brainfuck's is self descripted. I can come up with a few things that are genually confusing about scala, like implicits resolution rules and quirks of the type system, but I cannot claim they are intentional, and they are getting fixed. On the other hand, having things like functional collections futures years before Java made life easier for the whole lot of us
Creator of Scala believes, and advocates, Scala is simpler than Java?
Wow.
Wow.
Because it is simpler than Java, in particular when you limit it to the subset of features covered by Java only. Many Scala features that do exist in Java are more complicated in Java. And some do not exist at all, which means you have to emulate them by writing more boilerplate code.
So does creator of spring who sat on lightbends board for a while
To me, the question is who is allowed to make the choice?
Is it the language designer's place to say what can or cannot be done with it or the person/team who chooses what they do with it?
Personally, I would rather work with programming languages which allow me/the team to choose. YMMV.
Is it the language designer's place to say what can or cannot be done with it or the person/team who chooses what they do with it?
Personally, I would rather work with programming languages which allow me/the team to choose. YMMV.
A word of caution on Scala 3:
Scala 3 still in beta, lacks clear roadmap, allows choosing between two syntaxes (python-style vs braces).
Dotty Community Build lacking Lightbend frameworks (no Akka, no Play, no sbt)
With the recent layoffs at Lightbend of Scala 2.x core contributors, a full endorsement of Scala 3 would certainly help.
Scala 3 still in beta, lacks clear roadmap, allows choosing between two syntaxes (python-style vs braces).
Dotty Community Build lacking Lightbend frameworks (no Akka, no Play, no sbt)
With the recent layoffs at Lightbend of Scala 2.x core contributors, a full endorsement of Scala 3 would certainly help.
As an outside observer (and professional Akka user), comments like this really help put the changes in perspective. Thanks.
Scala made lots of Java patterns builtin language features, and it appears Scala 3 will do the same thing with all the patterns that emerged in Scala 2. As long as the tooling keeps up to par, Scala 3 will be one of the most pleasant to use languages out there.
Unfortunately, I slowly got frustrated reading the what's coming for Scala 3.
* True intersections and union types -- use them sometimes, not something you can't live without though.
* Trait parameters -- slightly easier life for OOP, ok I guess.
* Function types and implicit function types -- right, will make your code even harder to read (subjective).
* Generic tuples -- again, I can't remember we ever had problems with tuples in Scala.
* Opaque types -- another small OOP improvement.
* Type lambdas -- I've never seen them used.
* Erased parameters -- probably useful if it improves performance even at the cost of readability right?
* Enums -- finally something practical, good.
And that's all about major changes in Scala 3. Ah, yes, we get a new compiler. Are you excited?
These changes look like a quarterly release than a major version shift. Now, imagine a project manager who's estimating the migration downtime for Scala 2 for the sake of the above.
* True intersections and union types -- use them sometimes, not something you can't live without though.
* Trait parameters -- slightly easier life for OOP, ok I guess.
* Function types and implicit function types -- right, will make your code even harder to read (subjective).
* Generic tuples -- again, I can't remember we ever had problems with tuples in Scala.
* Opaque types -- another small OOP improvement.
* Type lambdas -- I've never seen them used.
* Erased parameters -- probably useful if it improves performance even at the cost of readability right?
* Enums -- finally something practical, good.
And that's all about major changes in Scala 3. Ah, yes, we get a new compiler. Are you excited?
These changes look like a quarterly release than a major version shift. Now, imagine a project manager who's estimating the migration downtime for Scala 2 for the sake of the above.
Trait params have little to do with OOP.
Opaque types are not a "small OOP improvement", they finally bring zero-cost newtypes to Scala, superseding value classes. Now you can finally ensure that object Ids, people's names, meters, feet, and degrees Celsius all have different types - without any extra boxing at runtime.
Your list is also missing typeclass derivation, which is going to be a fantastic quality of life improvement. Yes, even for people who don't care about what a typeclass is.
This is a point I want to stress the most, I think. Features like type lambdas, or libraries like Shapeless - they can possibly be extremely beneficial to you even if you don't use them directly in your code. Ask your nearby Haskell programmers about the virtues of `deriving (Eq, Ord)` and they'll talk your ear off. And that's before they even get to things like `deriving (FromJSON, ToJSON)`. Don't have a Haskell programmer nearby? It's ok, ask a Rust programmer about Serde instead. Typeclass derivation is just such a massive, massive feature to have in your language's repertoire.
Opaque types are not a "small OOP improvement", they finally bring zero-cost newtypes to Scala, superseding value classes. Now you can finally ensure that object Ids, people's names, meters, feet, and degrees Celsius all have different types - without any extra boxing at runtime.
Your list is also missing typeclass derivation, which is going to be a fantastic quality of life improvement. Yes, even for people who don't care about what a typeclass is.
This is a point I want to stress the most, I think. Features like type lambdas, or libraries like Shapeless - they can possibly be extremely beneficial to you even if you don't use them directly in your code. Ask your nearby Haskell programmers about the virtues of `deriving (Eq, Ord)` and they'll talk your ear off. And that's before they even get to things like `deriving (FromJSON, ToJSON)`. Don't have a Haskell programmer nearby? It's ok, ask a Rust programmer about Serde instead. Typeclass derivation is just such a massive, massive feature to have in your language's repertoire.
Well. You also get better binary compatibility and the possibility to do whole program analysis.
Edit: oh. And this is on top of a rewritten, faster, compiler, a unified base paradigm making it easier to learn the language, and better error messages for compile errors. I think dismissing this as as minor release is disingenuous to how much effort goes in such a large scale rewrite. Granted, most of it is under the hood but it will pay off dividend.
Edit: oh. And this is on top of a rewritten, faster, compiler, a unified base paradigm making it easier to learn the language, and better error messages for compile errors. I think dismissing this as as minor release is disingenuous to how much effort goes in such a large scale rewrite. Granted, most of it is under the hood but it will pay off dividend.
Scala 3 could improve on 2.x struggles with supporting JDK 9 and up:
Support features of JDK 11+ https://github.com/scala/scala-dev/issues/139
Support Java Module System https://github.com/scala/scala-dev/issues/529
In comparison language features seem to attract much more attention:
Removing existential types https://contributors.scala-lang.org/t/proposal-to-remove-exi...
Significant indentation syntax https://github.com/lampepfl/dotty/pull/7083
Support features of JDK 11+ https://github.com/scala/scala-dev/issues/139
Support Java Module System https://github.com/scala/scala-dev/issues/529
In comparison language features seem to attract much more attention:
Removing existential types https://contributors.scala-lang.org/t/proposal-to-remove-exi...
Significant indentation syntax https://github.com/lampepfl/dotty/pull/7083
That is a good example why betting on the platform languages is always a long term safer bet than betting the house on guest languages,
Eventually they won't keep up with the underlying platform.
Eventually they won't keep up with the underlying platform.
It's not like it isn't working. Scala runs fine on JDK13 (probably 14 too, but we currently run one Play project in prod on 13).
Java is a pretty safe bet, as it has an outstanding backward compatibility track record.
Java is a pretty safe bet, as it has an outstanding backward compatibility track record.
Yup. I jumped ship for Swift a while ago.
I always thought scala native to be a bit of distraction after graalvm went mainstream. Don't know why people do not like working with language that can combine better parts of Java Haskell Ruby and Erlang. Having said that, Scala is Scala, and people who are writing Haskell or Java code in Scala certainly not writing Scala
> people who are writing Haskell or Java code in Scala certainly not writing Scala
For me, one of the joys of Scala is that you can use different paradigms and mix them up as convenient. Haskell Scala is still Scala and so is Java Scala!
For me, one of the joys of Scala is that you can use different paradigms and mix them up as convenient. Haskell Scala is still Scala and so is Java Scala!
I do that too, but to a degree. For example, I avoid monad transformers, fully automatic derivations, pretty much anything that requires line long type signatures
> Martin Odersky is for me in the top three language designers of our time
I don't know about that.
To me, the criteria he uses to allow incorporation of features in both Scala 2 and Scala 3 is "Will this feature allow me and my students to apply papers for conferences and fund my PhD students?".
Language design seems to have very little to do with that. As long as you can derive multiple papers to multiple conferences from a proposed feature, it's in.
I don't know about that.
To me, the criteria he uses to allow incorporation of features in both Scala 2 and Scala 3 is "Will this feature allow me and my students to apply papers for conferences and fund my PhD students?".
Language design seems to have very little to do with that. As long as you can derive multiple papers to multiple conferences from a proposed feature, it's in.
That sounds like an accusation. Could you back it up by something, perhaps examples?
for the record, instantiating case classes in scala does not require "new"
Or any other class if you write an apply method in companion object
Scala is a beautiful and elegant language. I really thought that it would be one of my favourite languages when I first started working with it. However, after some time I got disenchanted.
First, Scala is hard. Projects written by one person quickly become a deep functional labyrinth and custom architectural patterns because Scala is so expressive and you can do all kind of twists.
Second, the entrance level remains high. Your more experienced colleagues will not allow to write anything that even remotely smells OOP. This delays the time when you can be productive.
Third, on paper Scala tries to serve both object oriented and functional worlds but in practice the the latter is the unconditional standard.
Although I like the positive tone of the article, I find it difficult to agree with Scala ever becoming mainstream.
Yeah, I was also excited about Scala. Went to a conference in 2010; eventually took the Odersky course and tried it for some personal projects.
I ended up abandoning it, and for me Bruce Eckels captured a big part of why, talking about it as a "landscape of cliffs". [1] Every time I thought I knew what was going on, I tripped over something and ended up in a chasm. With much study and effort I could dig myself out of that hole, but soon enough I'd be in another one, trying to understand some abstruse bit of type magic when I just wanted to render a web page or something.
It also reminds me of the famous Kernighan quote: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." [2] Scala might be optimal for some group of people, but definitely not for me, and I think not for a mainstream developer audience either.
[1] https://www.bruceeckel.com/2015/08/29/what-i-do/
[2] https://en.wikiquote.org/wiki/Brian_Kernighan
It also reminds me of the famous Kernighan quote: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." [2] Scala might be optimal for some group of people, but definitely not for me, and I think not for a mainstream developer audience either.
[1] https://www.bruceeckel.com/2015/08/29/what-i-do/
[2] https://en.wikiquote.org/wiki/Brian_Kernighan
I must say this comment reminded me of LISP and the many criticisms put against it. Perceived as overly flexible ("custom architectural patterns") with snobbish people ("colleagues will not allow to"). But at the same time many people will find LISP (or Scala) their "superpower" that allows them to perform really well.
no one flavor of scala will ever be a standard. you have to adopt coding styles and stick to them. once you get to the point where you have a pattern and you’re just coding-by-number scala isn’t the problem anymore
I was asked to join a team of scala developers. Most except one had started learning about 6 months earlier. I was asked to learn it while making small contributions to the project. I quickly found out that there were statements that could be interpreted in multiple ways, can't remember now what it was. Then I got stuck on something and even our seasoned very enthusiastic Scala developer could not solve it. I then and there decided not to pursue learning the language and quickly have myself transferred to another team. It's a difficult language, one should not spend thinking on the language but spend time thinking about the problem itself. Probably what I say is not doing justice to Scala as I was just a newbie but I did not have those problems with Clojure which is another not that mainstream language.
And that's the whole problem with Scala. When you work with it, you are having a battle with types and compiler more often than you should. Funny but it is not the first typed language I had to write code in. Never did I have to do so much unnecessary dancing around and asking senior colleagues for help. I guess not all of us are capable of grasping such expressiveness at the cost of such complexity. The majority just need simpler tools to be productive.
That's what led to ZIO.
Going full FP in Scala with Scalaz and "tagless final" (I still have no clear idea what's that) and whatever else that's hip, leads to madness. Sure you can write maximally polymorphic code. Great. But you end up doing the extractions/refactors that the type system and the compiler allows, not those that would help the code the most. Because those are too slow (too much boxing and GC churn), or the compiler has a bug (or the library) so you end up putting a TODO comment in the code with a link to a github issue.
Or it's a feature that's not supported by Scala, so you end up with a FP spaghetti. :(
Going full FP in Scala with Scalaz and "tagless final" (I still have no clear idea what's that) and whatever else that's hip, leads to madness. Sure you can write maximally polymorphic code. Great. But you end up doing the extractions/refactors that the type system and the compiler allows, not those that would help the code the most. Because those are too slow (too much boxing and GC churn), or the compiler has a bug (or the library) so you end up putting a TODO comment in the code with a link to a github issue.
Or it's a feature that's not supported by Scala, so you end up with a FP spaghetti. :(
IMO, it really depends on the team you join, as with most programming projects. Scala can be used in a classic mutable OOP manner, as if you were writing Java in 2005, or if you heavily buy into pure FB libraries it can be used basically like it's Haskell, but IMO neither of these approaches embrace the strengths of the language. It's meant to be a true mix of OOP and functional paradigms, not going extreme one way or the other. The object oriented aspects let you embrace great OOP software architecture patterns like Domain Driven Design, so that you can really model the business domain clearly and faithfully. Then the functional aspects allow you to implement a "functional core, imperative shell" style, that's really easy to reason about, and easy to make concurrent (safely), while also having excellent/safe/descriptive types like Future/Option/Try and ADTs.
It sounds like you've worked with a group of people who want to treat Scala like it's Haskell, but that's a minority community that IMO isn't really embracing the strengths of the language. I've worked on projects that go all-in on libs like Cats and Scalaz, and I agree that they're mostly unnecessary complexity that also obscure the modelling of the business domain. You're going to massively confuse newcomers with all the Applicative/Effect/Monad/Monoid/Functor/etc. talk, for next to no benefit. Actors are a bit of a different story - excellent for the 1% of times where you really need them (lots of mutable state and lots of concurrency), but 99% of the time you don't need them. Some devs are enamoured with the mathematical purity of pure functional programming, without properly considering how hard it is to understand for most other devs. If you let these types take over your company, that’s a cultural problem, not really a language problem.
Odersky describes why he created the language here: https://www.signifytechnology.com/blog/2018/01/why-scala
> ... programmers are increasingly facing new challenges for high-level domain modeling, rapid development, and, more recently, parallelism and concurrency. It seemed to me that a unification of the traditional object-oriented model with functional programming concepts was feasible and highly desirable to address those challenges.
I completely agree, and have yet to find a better language than Scala for the above demands, assuming you really embrace the OOP/functional mix. I've been writing lots of Scala at my day job for the past ~5 years, and it's my favourite language. I've worked on backends in Scala, Java, Go, Python, PHP and Node, and prefer Scala to all of them.
I also agree with Li Haoyi - it's becoming a really solid, stable, reliable language, with improvements focused on the build tools, compiler, and the odd language wart, without significant changes to syntax/style, which is great. It does take awhile to learn, and you do have to be careful about what style you program in, but I think if you just embrace the language's OOP/functional fix, and for "core style" mostly stick with the standard library (Future/Try/Option/etc.) vs. going crazy with Cats/Scalaz/Akka/etc. (unless you REALLY need Akka specifically), it's an outstanding language.
It sounds like you've worked with a group of people who want to treat Scala like it's Haskell, but that's a minority community that IMO isn't really embracing the strengths of the language. I've worked on projects that go all-in on libs like Cats and Scalaz, and I agree that they're mostly unnecessary complexity that also obscure the modelling of the business domain. You're going to massively confuse newcomers with all the Applicative/Effect/Monad/Monoid/Functor/etc. talk, for next to no benefit. Actors are a bit of a different story - excellent for the 1% of times where you really need them (lots of mutable state and lots of concurrency), but 99% of the time you don't need them. Some devs are enamoured with the mathematical purity of pure functional programming, without properly considering how hard it is to understand for most other devs. If you let these types take over your company, that’s a cultural problem, not really a language problem.
Odersky describes why he created the language here: https://www.signifytechnology.com/blog/2018/01/why-scala
> ... programmers are increasingly facing new challenges for high-level domain modeling, rapid development, and, more recently, parallelism and concurrency. It seemed to me that a unification of the traditional object-oriented model with functional programming concepts was feasible and highly desirable to address those challenges.
I completely agree, and have yet to find a better language than Scala for the above demands, assuming you really embrace the OOP/functional mix. I've been writing lots of Scala at my day job for the past ~5 years, and it's my favourite language. I've worked on backends in Scala, Java, Go, Python, PHP and Node, and prefer Scala to all of them.
I also agree with Li Haoyi - it's becoming a really solid, stable, reliable language, with improvements focused on the build tools, compiler, and the odd language wart, without significant changes to syntax/style, which is great. It does take awhile to learn, and you do have to be careful about what style you program in, but I think if you just embrace the language's OOP/functional fix, and for "core style" mostly stick with the standard library (Future/Try/Option/etc.) vs. going crazy with Cats/Scalaz/Akka/etc. (unless you REALLY need Akka specifically), it's an outstanding language.
What types of projects you have been working on?
Exactly my experience too.
It's hard not to fall in love with Scala in the first months you start using it but downright impossible to like the language after that.
Kotlin has won my heart. So far, anyway.
It's hard not to fall in love with Scala in the first months you start using it but downright impossible to like the language after that.
Kotlin has won my heart. So far, anyway.
Author here. The full title is “The Death of Hype: What’s Next for Scala”, and the full title is significant. This article is as much about the initial hype and its decline as it is about the future prospects of the language. It very much isn’t an official or even unofficial roadmap for the language, which is what the shortened title makes it sound like.
I posted it with the original title. I don't know why the HN moderators almost always change titles. Happened to me a couple of times.
[deleted]
I saw a lot of myself in your article. Came to scala in 2014 via spark, wrote a lot of OOP code and then slowly moved into the FP space. These days I find myself writing python a lot (for machine learning) but just miss the type safety net I get with scala
My take is that “death of hype” could be prefixed to a lot of article titles submitted to Hacker News. It’s not that it isn’t meaningful to you as the author or that it’s not a theme of the article or that Hacker News doesn’t encourage the submission of original titles. It’s that “death of hype” doesn’t make Hacker News better because it amps up the attack surface for low quality comments about the title, or Scala hype, or somebody’s least favorite hyped languages in general. Basically it opens the door to a lot of nonexpert comments of outrage without creating value for people who click the link because those people see “death of hype” with an <h> tag.
I very recently (about a year ago) joined a shop that is primarily into functional programming (FP) and I got my first exposure to Scala as well as F# through work projects. As a long time user of Java/OOP here are my thoughts on Scala and why it has so many things things going against it. Consider the following:
1) First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis purposes. Nothing wrong with that. But that also means language features are added not to solve a practical problem but mostly to show that "it can be done"/"prove a point". When you are awake at 3 AM early in the morning because a release made in the evening went awry and you are trying to grep though logs/code to see what caused the issue I can assure you that debates about "pure" versus "impure", Monads, Kleisli arrow will be further from your mind. So the problem that Scala seems to suffer from is that of "image".
2) Second, Scala is neither a fully functional (FP) nor object oriented (OOP). Support for mixed/multi-paradigm sounds nice on paper but let me ask this question: do you know of any hard core FP programmer who is excited about inheritance or abstract classes or other OOP features? Vice-versa the same thing can be said about many OOP programmers lukewarm response towards many functional features of Scala. I believe that support for mixed/multiple paradigms has hindered large scale adoption of Scala. The language seems to be caught at cross-roads not knowing which way to advance next.
3) Third is lack of niche. True, I absolutely love "Spark" and primarily use it to extract/manipulate data from HDFS/Hive storage but I am gradually gravitating towards "Python" libraries due to their ease of use. What about better Java? Kotlin check. What about sidecar systems used by DevOps? Go check. What about a better designed system language? Rust check. The days of pure general purpose programming languages are truly over and Scala will be in great peril if it fails to expand into newer niches. Without broadening its programmer base it will finally run out of people that can design newer language features in light of ever advancing progresses in processor, OS and memory architectures.
Just my two cents.
1) First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis purposes. Nothing wrong with that. But that also means language features are added not to solve a practical problem but mostly to show that "it can be done"/"prove a point". When you are awake at 3 AM early in the morning because a release made in the evening went awry and you are trying to grep though logs/code to see what caused the issue I can assure you that debates about "pure" versus "impure", Monads, Kleisli arrow will be further from your mind. So the problem that Scala seems to suffer from is that of "image".
2) Second, Scala is neither a fully functional (FP) nor object oriented (OOP). Support for mixed/multi-paradigm sounds nice on paper but let me ask this question: do you know of any hard core FP programmer who is excited about inheritance or abstract classes or other OOP features? Vice-versa the same thing can be said about many OOP programmers lukewarm response towards many functional features of Scala. I believe that support for mixed/multiple paradigms has hindered large scale adoption of Scala. The language seems to be caught at cross-roads not knowing which way to advance next.
3) Third is lack of niche. True, I absolutely love "Spark" and primarily use it to extract/manipulate data from HDFS/Hive storage but I am gradually gravitating towards "Python" libraries due to their ease of use. What about better Java? Kotlin check. What about sidecar systems used by DevOps? Go check. What about a better designed system language? Rust check. The days of pure general purpose programming languages are truly over and Scala will be in great peril if it fails to expand into newer niches. Without broadening its programmer base it will finally run out of people that can design newer language features in light of ever advancing progresses in processor, OS and memory architectures.
Just my two cents.
I work at a Java shop, we do ‘modern’ Java (11 or 14, some legacy 8), but I do a lot fp-style Scala dev at home.
Calling Scala an ivory tower with no interest in ‘practical’ programming is ridiculous. Scala and Java are remarkably similar in this respect (note Odersky was heavily involved with Java before Scala), albeit one is sponsored by a uni and the other a corporation. JEPs are just as likely to have actual PhD theses associated with them, and those that don’t often could have. Look at Project Valhalla or Loom or the GraalVM, these are novel programming language research projects with the end goal of bringing them to a widely used industry language in a backwards compatible and ergonomic way.
As for pure FP in production, just last week we had a brief bit of message loss in a system because some layer in an sdk swallowed a socket timeout exception and re-threw something totally unrelated and undocumented. This was hell to debug for other reasons related to imperative code, that simply wouldn’t have happened in a ZIO project.
That’s not to say you can’t make reliable software in Java, my team spends a lot of time doing just that. It just often feels like the whole ecosystem is fighting against you. Things are getting much better in Java land, but there are parts that can never catch up with Scala because of past design choices.
I agree with your other 2 points, multi-paradigm is both a blessing and a curse and probably becomes more of the latter in a large org.
Also, unrelated, but imo better Java is Java or maybe Java in 3 years, Kotlin didn’t go far enough.
Calling Scala an ivory tower with no interest in ‘practical’ programming is ridiculous. Scala and Java are remarkably similar in this respect (note Odersky was heavily involved with Java before Scala), albeit one is sponsored by a uni and the other a corporation. JEPs are just as likely to have actual PhD theses associated with them, and those that don’t often could have. Look at Project Valhalla or Loom or the GraalVM, these are novel programming language research projects with the end goal of bringing them to a widely used industry language in a backwards compatible and ergonomic way.
As for pure FP in production, just last week we had a brief bit of message loss in a system because some layer in an sdk swallowed a socket timeout exception and re-threw something totally unrelated and undocumented. This was hell to debug for other reasons related to imperative code, that simply wouldn’t have happened in a ZIO project.
That’s not to say you can’t make reliable software in Java, my team spends a lot of time doing just that. It just often feels like the whole ecosystem is fighting against you. Things are getting much better in Java land, but there are parts that can never catch up with Scala because of past design choices.
I agree with your other 2 points, multi-paradigm is both a blessing and a curse and probably becomes more of the latter in a large org.
Also, unrelated, but imo better Java is Java or maybe Java in 3 years, Kotlin didn’t go far enough.
Kotlin hit jackpot with Android, but given Google's reluctance to move Android Java beyond its Java 8 subset, JetBrains will eventually need to consider having two Java targets as part of their multiplatform Kotlin, or just focus being an Android language.
Well put. I had to use Scala for a little and I wasn't a fan.
It's maybe a fun language to play around with for a pet project, but for a reliable production system I would never pick it.
The language is too flexible with too many ways to do the same thing, increasing cognitive load and making things difficult to understand. Maybe you can limit that in your own projects, but what if you have to look at a library codebase that's structured completely differently. Trying to understand that can take a lot of time.
Also there is the problem with hiring. Maybe your current team can work well with Scala, but what if a key member leaves or a service gets transferred. Hiring for Scala turned out to be impossible, so you get all these people that need to learn Scala first. Normally that may be ok, but Scala has a pretty steep learning curve so it takes a lot longer to onboard people.
The language is too flexible with too many ways to do the same thing, increasing cognitive load and making things difficult to understand. Maybe you can limit that in your own projects, but what if you have to look at a library codebase that's structured completely differently. Trying to understand that can take a lot of time.
Also there is the problem with hiring. Maybe your current team can work well with Scala, but what if a key member leaves or a service gets transferred. Hiring for Scala turned out to be impossible, so you get all these people that need to learn Scala first. Normally that may be ok, but Scala has a pretty steep learning curve so it takes a lot longer to onboard people.
On hiring: Python Paradox comes to mind (http://www.paulgraham.com/pypar.html).
I've never met sub-par FPer or Scala programmer specifically.
Using PHP or Javascript might give you a bigger top of the hiring funnel, but it doesn't mean you'll have easier time finding well-qualified applicant.
[deleted]
I’m surprised you had such a bad experience with scala. Or do you think these are problems with how scala is perceived versus how it actually is to use?
Personally I liked it. I spent a while doing java web dev with the play framework, and also spent a while doing scala web dev with the play framework, which allowed me to compare directly. I have to say scala is a far nicer OOP language than java. The collection classes are better designed, the way futures and options work is so much more elegant than the java counterparts, and the overall syntax is much more efficient. IMHO if you just use scala as a nicer java, it absolutely trounces it. I couldn’t really say what OOP feature it lacks compared to java. I never tried kotlin, so I cannot tell how that compares.
I also spent a while doing FP style programming with scala in spark and akka. I cannot compare it against other FP languages because I never used them but I can say it was similarly very enjoyable and it was easy to write elegant and understandable code.
I would agree mixing both approaches in a single codebase is a path fraught with peril. If scala has a flaw then it is having too many features. Like C++ you need to be careful which features you use in which combination, or you can end up writing an intractable codebase.
Personally I liked it. I spent a while doing java web dev with the play framework, and also spent a while doing scala web dev with the play framework, which allowed me to compare directly. I have to say scala is a far nicer OOP language than java. The collection classes are better designed, the way futures and options work is so much more elegant than the java counterparts, and the overall syntax is much more efficient. IMHO if you just use scala as a nicer java, it absolutely trounces it. I couldn’t really say what OOP feature it lacks compared to java. I never tried kotlin, so I cannot tell how that compares.
I also spent a while doing FP style programming with scala in spark and akka. I cannot compare it against other FP languages because I never used them but I can say it was similarly very enjoyable and it was easy to write elegant and understandable code.
I would agree mixing both approaches in a single codebase is a path fraught with peril. If scala has a flaw then it is having too many features. Like C++ you need to be careful which features you use in which combination, or you can end up writing an intractable codebase.
I had the same experience as you on the beginning. I started with a project in play framework, I was really excited about an improved java, etc. Then some FP hardcore developers came and started to influence younger developers that OOP was not cool anymore, all our system should be composed of Actions and monads of all kinds, and all business logic should be just a big composition of map and flatMaps.
After a while the project became just a dick measuring context of who could do the best trick shots. Declaring a lot of implicit parameters, implicit conversions automatically applied, crazy type inference that makes compiling 10x slower, you name it. Just to make the code unreadable enough that other developers need days to understand a three lines of code change.
And after all of that the more they do it, the more they are seen as the best Scala developers on the team.
After a while the project became just a dick measuring context of who could do the best trick shots. Declaring a lot of implicit parameters, implicit conversions automatically applied, crazy type inference that makes compiling 10x slower, you name it. Just to make the code unreadable enough that other developers need days to understand a three lines of code change.
And after all of that the more they do it, the more they are seen as the best Scala developers on the team.
That seems more a symptom of an organizational dysfunction than an indictment of the language.
To wit, 15 years ago I was on a team where it was “How J2EE can you get?” Ughh. Along the way they(we) basically forgot to solve the business problems.
And that sion was the end of that.
To wit, 15 years ago I was on a team where it was “How J2EE can you get?” Ughh. Along the way they(we) basically forgot to solve the business problems.
And that sion was the end of that.
Based on your preferences you definitely should try Kotlin :)
Thanks to Scala we've built, scaled and sold a startup (~150kloc, Lift + Play, SBT). Thank you.
That said, "First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis purposes." I totally agree.
Error messages when using libraries are horrendous with dozens of lines of type errors (take a look at Elm how it's done right).
Compile times are horrendous. There are whole consulting companies [1] which do nothing than help companies with compile time of their Scala projects.
The article talks about 2x speedups over the years. Which sounds nice, but if you're 10x slower than others (Go, Rust, ...), then with a 2x speed up you're still 5x slower. Which is fine far small projects but kills you with large ones.
Would come back if the compiler is rewritten in Go (which will not happen because Scala is primarily a research project).
I now use TypeScript with Wallaby.js and Quokka developing test first. It's like night and day. I do miss Scala, because I really love the language, but I would not go to the pain of compiling and executing unit tests again in Scala.
[1] https://triplequote.com/ "Compile Scala Faster"
That said, "First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis purposes." I totally agree.
Error messages when using libraries are horrendous with dozens of lines of type errors (take a look at Elm how it's done right).
Compile times are horrendous. There are whole consulting companies [1] which do nothing than help companies with compile time of their Scala projects.
The article talks about 2x speedups over the years. Which sounds nice, but if you're 10x slower than others (Go, Rust, ...), then with a 2x speed up you're still 5x slower. Which is fine far small projects but kills you with large ones.
Would come back if the compiler is rewritten in Go (which will not happen because Scala is primarily a research project).
I now use TypeScript with Wallaby.js and Quokka developing test first. It's like night and day. I do miss Scala, because I really love the language, but I would not go to the pain of compiling and executing unit tests again in Scala.
[1] https://triplequote.com/ "Compile Scala Faster"
Did you have trouble hiring Scala devs? And if so, do you think the language benefits outweighed that. This is my main concern choosing to build new ventures with Scala.
1.) Yes
1a.) Scala was a bad choice, but it was chosen because I love the language.
2.) When founders ask me about what language to choose, I tell them: "Choose one where you easily find developers, then you can't go wrong".
2.) When founders ask me about what language to choose, I tell them: "Choose one where you easily find developers, then you can't go wrong".
Totally. I think the right way to pick a language for a startup is to find some smart, experienced devs to hire and let them pick (modulo reasonable business constraints). The popular languages all can do a wide range of things effectively. The more important factor for productivity is how well the team knows and likes the tools.
As an example, we know that PHP is a "fractal of bad design"[1], but I can't deny that Facebook as a business is doing just fine.
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
As an example, we know that PHP is a "fractal of bad design"[1], but I can't deny that Facebook as a business is doing just fine.
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Agreed. I switched from scala to python and oh man what a relief.
Scala is a heavy weight languange. By heavyweight I mean,
1. Even intellij struggles to figure out the meaning of implicits in the given context. And then there are macros.
2. Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid. There is always a nagging feeling that you don't 'get it' when you program in scala. Here is an example of scala conference in 2020:
https://scaladays.org/2020/berlin/schedule
Features talks like these.
> a. Composition with Functional Effects
> b. Scala 3 and Abstract Algebra
> c. Describable, typesafe computations for the less monadically inclined
> d. Understanding Scala's Type System
> e. Roll your own Effect System
3. Every code base is written in its own flavor of scala.
I was spending absurd amount of time "learning scala", now i look back at that and cringe.
Scala is a heavy weight languange. By heavyweight I mean,
1. Even intellij struggles to figure out the meaning of implicits in the given context. And then there are macros.
2. Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid. There is always a nagging feeling that you don't 'get it' when you program in scala. Here is an example of scala conference in 2020:
https://scaladays.org/2020/berlin/schedule
Features talks like these.
> a. Composition with Functional Effects
> b. Scala 3 and Abstract Algebra
> c. Describable, typesafe computations for the less monadically inclined
> d. Understanding Scala's Type System
> e. Roll your own Effect System
3. Every code base is written in its own flavor of scala.
I was spending absurd amount of time "learning scala", now i look back at that and cringe.
Scala 3 will alleviate some of the pain you felt, for example around implicits. Scala's IDE tooling is getting better with faster compilation and language servers.
Scala is a fusion of object-oriented and functional programming. There are at least three major styles of Scala programs: OOP, functional, and reactive (actors). Scala indeed places the burden on the development team of choosing which patterns are right for them.
The theoretical concepts that you disliked are "available" in other languages too, you just don't hear about them much because functional programmers prefer languages with strong type systems. That's not to excuse the learning curve they create! I still don't understand them too well. Some of the people who do understand them will unnecessarily push them onto their projects or teams. Scala doesn't force these on you, you can ignore them. For example I write a game engine in Scala that is mostly imperative-style and has limited use of the theoretical constructs you mention.
Python's lack of a strong type system is a serious deficiency for large projects. Same with JavaScript. The costs it creates are large and often undetectable because they are the zeitgeist and death by a thousand cuts.
Scala is a fusion of object-oriented and functional programming. There are at least three major styles of Scala programs: OOP, functional, and reactive (actors). Scala indeed places the burden on the development team of choosing which patterns are right for them.
The theoretical concepts that you disliked are "available" in other languages too, you just don't hear about them much because functional programmers prefer languages with strong type systems. That's not to excuse the learning curve they create! I still don't understand them too well. Some of the people who do understand them will unnecessarily push them onto their projects or teams. Scala doesn't force these on you, you can ignore them. For example I write a game engine in Scala that is mostly imperative-style and has limited use of the theoretical constructs you mention.
Python's lack of a strong type system is a serious deficiency for large projects. Same with JavaScript. The costs it creates are large and often undetectable because they are the zeitgeist and death by a thousand cuts.
Ahh yes, the old “the next version will solve everything!” and the “you must be doing it wrong.”
Or... have one way of doing everything (python, go, Rust, even Java) and simplify. That simplicity means 3rd party libraries will all largely have the same basic constructs for how things work, which makes it far easier to learn, which makes it easier to contribute.
Or... have one way of doing everything (python, go, Rust, even Java) and simplify. That simplicity means 3rd party libraries will all largely have the same basic constructs for how things work, which makes it far easier to learn, which makes it easier to contribute.
None of those languages have one way to do everything, I would even wager none have only one way to do anything.
Simplicity comes at a cost, compare Elm to Purescript/Haskell for example. Elm lacks type classes, so it’s simpler and more explicit, but that comes at the cost of verbosity and duplication. This was an explicit decision to make the language more friendly for beginners, and that’s a reasonable trade off to make, but it’s not universally better.
Simplicity comes at a cost, compare Elm to Purescript/Haskell for example. Elm lacks type classes, so it’s simpler and more explicit, but that comes at the cost of verbosity and duplication. This was an explicit decision to make the language more friendly for beginners, and that’s a reasonable trade off to make, but it’s not universally better.
> Scala doesn't force these on you
Yea but one cannot write everything from scratch. I had to work on project that use cats, scalz and stuff. I felt like i was splitting an atom when i was actually writing a crud app :) .
Obsession with those theoretical concepts with dubious and unproven benefits is deeply interwoven in community. Cost of learning cats vs benefit is just absurd.
I would only recommend scala to programming language nerds that want to sound smart.
Yea but one cannot write everything from scratch. I had to work on project that use cats, scalz and stuff. I felt like i was splitting an atom when i was actually writing a crud app :) .
Obsession with those theoretical concepts with dubious and unproven benefits is deeply interwoven in community. Cost of learning cats vs benefit is just absurd.
I would only recommend scala to programming language nerds that want to sound smart.
[deleted]
> I switched from scala to python and oh man what a relief.
I did a bit of Python, then did a bit of Scala, and now do both at work. Oh what a pain Python is! And what a joy Scala is!
> Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid.
Concepts are theoretical in their nature, aren't they? Perhaps these concepts are useful and you just haven't yet found out why?
Wrt feeling stupid, there are two possible reactions: "gee, I'm not so smart" and "whee a learning opportunity" - I'll prefer the latter anytime.
> There is always a nagging feeling that you don't 'get it' when you program in scala
Yes I have that too - so much more to learn!
I did a bit of Python, then did a bit of Scala, and now do both at work. Oh what a pain Python is! And what a joy Scala is!
> Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid.
Concepts are theoretical in their nature, aren't they? Perhaps these concepts are useful and you just haven't yet found out why?
Wrt feeling stupid, there are two possible reactions: "gee, I'm not so smart" and "whee a learning opportunity" - I'll prefer the latter anytime.
> There is always a nagging feeling that you don't 'get it' when you program in scala
Yes I have that too - so much more to learn!
> Perhaps these concepts are useful and you just haven't yet found out why?
Or maybe they are not that useful? If they were really that useful we would see those concepts everywhere.
Or maybe they are not that useful? If they were really that useful we would see those concepts everywhere.
You do see those concepts everywhere.
monads : stuff which kind of encapsulate other things, but you can still nicely manipulate both the thing and the stuff. Let's say, lists.
monoids : set of things where you kind of can add one to another. Let's say, numbers
isomorphisms : functions where there is exactly as many outputs possible than there are possible inputs. Let's say, adding 1 to a number. It's kind of useful knowing whether or not a function is an isomorphism (hello, hash collisions !).
Those concepts aren't specific to any programming language in fact, and are in fact everywhere. You just don't need to explicit them to use them, expliciting them is an option (even in Scala) which allows you to do meta manipulations on them (which Scala doesn't require, and doesn't even really suggest since none are part of the standard lib).
monads : stuff which kind of encapsulate other things, but you can still nicely manipulate both the thing and the stuff. Let's say, lists.
monoids : set of things where you kind of can add one to another. Let's say, numbers
isomorphisms : functions where there is exactly as many outputs possible than there are possible inputs. Let's say, adding 1 to a number. It's kind of useful knowing whether or not a function is an isomorphism (hello, hash collisions !).
Those concepts aren't specific to any programming language in fact, and are in fact everywhere. You just don't need to explicit them to use them, expliciting them is an option (even in Scala) which allows you to do meta manipulations on them (which Scala doesn't require, and doesn't even really suggest since none are part of the standard lib).
oh ok. Any thoughts on why scala conferences have this "Describable, typesafe computations for the less monadically inclined" but python conferences don't ?
Because doing something like that without a type system (which Python doesn't have) to guide your hand is practically impossible.
I would expect Clojure programmers (while still functional) don't use these abstractions either.
On the other hand, typed languages, like Haskell, Scala, OCaml, F#, do employ these abstract concepts. Their type system makes these worthwhile endeavour with great payoff.
I would expect Clojure programmers (while still functional) don't use these abstractions either.
On the other hand, typed languages, like Haskell, Scala, OCaml, F#, do employ these abstract concepts. Their type system makes these worthwhile endeavour with great payoff.
Oh I was asking if they( monoids, monads ect) are everywhere like GP claimed then how come monads isn't something that talked about in clojure or python conferences. But its always talked about in scala conferences.
Well, maybe scala conferences are hosted and attended by people who are interested in those concepts and find them attractive to talk about ? "conference people" just develop their own meta over time
Also, I just clicked on the most recent conference on clojure.org : https://clojured.de/schedule/ , and there is a talk mentioning monads while promising to not talk about monads :-D So it kind of reinforce my point that basic theoretical concepts are silently everywhere ^^ (and fully not necessary for almost everything).
But I don't think conferences are representative of the "on the ground production experience" that you have, or at least can have.
I personnaly wouldn't submit a paper to a conference with a talk "Here's how I made a whole backend stack using boring scala, and it just works" because as you say, I feel it's just full of theoretical speakers and that wouldn't interest anyone. Meanwhile, I also did code a whole backend in boring scala, and it in fact just works, and it feels good :-)
Also, I just clicked on the most recent conference on clojure.org : https://clojured.de/schedule/ , and there is a talk mentioning monads while promising to not talk about monads :-D So it kind of reinforce my point that basic theoretical concepts are silently everywhere ^^ (and fully not necessary for almost everything).
But I don't think conferences are representative of the "on the ground production experience" that you have, or at least can have.
I personnaly wouldn't submit a paper to a conference with a talk "Here's how I made a whole backend stack using boring scala, and it just works" because as you say, I feel it's just full of theoretical speakers and that wouldn't interest anyone. Meanwhile, I also did code a whole backend in boring scala, and it in fact just works, and it feels good :-)
Oh I was asking if they( monoids, monads ect) are everywhere like GP claimed then how come monads isn't something that talked about in clojure or python conferences.
I very much agree with your point on academics pursuing programming language theory for the sake of theory, and not for language design. I don't want to disparage FP research as a whole, but it seems to be the area of language design that cares the least about practicality and I don't really know why.
Being an undergrad doing my dissertation into programming language design, it seems that FP evolved from an area of research that was very much tied to the theory of computation and never really danced with the practical side of software engineering. Of course there are a few languages that have tried to marry the two (OCaml, Rust to an extent) it seems to very much a mathematicians game. Of course I love the math but it gets annoying to explain that no programmer should have to have a working understanding of category theory to use a language effectively.
Being an undergrad doing my dissertation into programming language design, it seems that FP evolved from an area of research that was very much tied to the theory of computation and never really danced with the practical side of software engineering. Of course there are a few languages that have tried to marry the two (OCaml, Rust to an extent) it seems to very much a mathematicians game. Of course I love the math but it gets annoying to explain that no programmer should have to have a working understanding of category theory to use a language effectively.
1) Without concrete examples this is just an unsubstantiated rant. As a trivial counterpoint, just have a look at the most advanced and opinionated FP libraries out there. Most of their contributors are not in academia.
2) Plenty of FP developers enjoy having access to the JVM and its huge ecosystem. I can trivially use and wrap most Java libraries, even the ones that overuse outdated OO patterns.
3) There are still enough companies and teams out there that don't just want a better Java. We'd see a decline in job openings if they were massively going back to Spring with Java or Kotlin, but that's not the case
2) Plenty of FP developers enjoy having access to the JVM and its huge ecosystem. I can trivially use and wrap most Java libraries, even the ones that overuse outdated OO patterns.
3) There are still enough companies and teams out there that don't just want a better Java. We'd see a decline in job openings if they were massively going back to Spring with Java or Kotlin, but that's not the case
Nowadays most Spark users use either PySpark or Spark SQL. Spark is designed in some sense to mimic Scala collection library. Rust is nice but its interop with other open source big data libs (Hadoop/Zookeeper/HBase) can be painful.
I’ve been using Scala as my main programming language for over 5 years. I’ve found my “plateau of enlightenment” by sticking to a subset of the features: case classes, for comprehensions, futures, immutability, pattern matching. By avoiding things like implicit, overly complex types, defining/overloading operators, and being dogmatic about FP/OOP I find the language stays out of your way and lets you write code that reads like what you’re trying to do.
I've done the same by being lazy, mainly treating it as a better Java and only learning new stuff when necessary or obviously beneficial. I want to write good programs, not fancy code.
My advice:
- Options, immutability, pattern matching, and list comprehensions are all awesome and better than the default Javaesque way
- Scala concurrency abstractions all better than Java, but concurrency is still hard. Proceed with caution
-- Except parallel collections. Use those liberally
- No Scalaz or any other FP-crusader stuff ever
- Macros and implicits should be rejected by default in code review. Amazing justifications required
- Enforce coding rules with linters. This applies for any language, but especially important for dynamic and non-straightjacket languages
My advice:
- Options, immutability, pattern matching, and list comprehensions are all awesome and better than the default Javaesque way
- Scala concurrency abstractions all better than Java, but concurrency is still hard. Proceed with caution
-- Except parallel collections. Use those liberally
- No Scalaz or any other FP-crusader stuff ever
- Macros and implicits should be rejected by default in code review. Amazing justifications required
- Enforce coding rules with linters. This applies for any language, but especially important for dynamic and non-straightjacket languages
OK, here's my question then. You're embracing Option type and yet presumably avoiding monads, applicatives, and functors (avoiding "FP-crusader stuff"), right?
So what happens when you are dealing with multiple option types, like you two optional ints you need to add together? Or you have an optional field in an optional object? This happens all the time in code that heavily uses Option types.
So do you match on every one, and nest match expressions inside match expressions inside match expressions? That can get very, very messy and even confusing.
So what happens when you are dealing with multiple option types, like you two optional ints you need to add together? Or you have an optional field in an optional object? This happens all the time in code that heavily uses Option types.
So do you match on every one, and nest match expressions inside match expressions inside match expressions? That can get very, very messy and even confusing.
For comprehensions should alleviate the examples you have given with regards to readability.
Although yes there are other more complex instances in which nested matches might come up. Generally I would think to handle them by creating a function that contains the next layer of matching instead of trying to come up with an uber function. Adds a bit more verbosity perhaps but I find it is fairly easy to follow and show intent.
Although yes there are other more complex instances in which nested matches might come up. Generally I would think to handle them by creating a function that contains the next layer of matching instead of trying to come up with an uber function. Adds a bit more verbosity perhaps but I find it is fairly easy to follow and show intent.
My question was poorly phrased, since if you're using Option types, you're obviously already using monads, applicatives, and functors.
What I should have asked was: if you're using monads such as Option, then how do you use them effectively without using integral tools such as flatMap?
And you've answered: you can use for comprehensions. I primarily have used Haskell and OCaml, so I sometimes forget about Scala's very nice for comprehensions, which I agree is a great solution. But note that for comprehensions are just syntactic sugar for `flatMap`.
I agree that if you do use Option types in Scala, for comprehensions are a very elegant way to interact with them.
But I'll end with a question. If you're already using option types with for comprehensions, why not also throw in other useful monads like bifunctor IO, which is a great way to deal with async code? I understand the dislike for the tendency in the FP Scala community to use custom sigils, but I do think most people who are using options and for comprehensions would also be comfortable and happy using other useful monads with for comprehensions.
What I should have asked was: if you're using monads such as Option, then how do you use them effectively without using integral tools such as flatMap?
And you've answered: you can use for comprehensions. I primarily have used Haskell and OCaml, so I sometimes forget about Scala's very nice for comprehensions, which I agree is a great solution. But note that for comprehensions are just syntactic sugar for `flatMap`.
I agree that if you do use Option types in Scala, for comprehensions are a very elegant way to interact with them.
But I'll end with a question. If you're already using option types with for comprehensions, why not also throw in other useful monads like bifunctor IO, which is a great way to deal with async code? I understand the dislike for the tendency in the FP Scala community to use custom sigils, but I do think most people who are using options and for comprehensions would also be comfortable and happy using other useful monads with for comprehensions.
> but I do think most people who are using options and for comprehensions would also be comfortable and happy using other useful monads with for comprehensions.
You seem to vastly underestimate the gap there is between using a for comprehension and understanding what a bifunctor is.
Nothing wrong with that: once you gain a certain advanced knowledge, it's often very hard to put yourself in the shoes of someone who hasn't gained that knowledge, and even harder to explain it to them in terms that they will understand.
Which is why we have so many unhelpful monad tutorials.
You seem to vastly underestimate the gap there is between using a for comprehension and understanding what a bifunctor is.
Nothing wrong with that: once you gain a certain advanced knowledge, it's often very hard to put yourself in the shoes of someone who hasn't gained that knowledge, and even harder to explain it to them in terms that they will understand.
Which is why we have so many unhelpful monad tutorials.
> concurrency is still hard. Proceed with caution
> No Scalaz or any other FP-crusader stuff ever
That stuff which some people might consider FP-crusader vanity is something which can make concurrency manageable, maybe even joy.
I encourage you to open your mind, at least for a bit, and have a look at ZIO or Monix.
> Enforce coding rules with linters
Absolutely! Scalafmt and Scalafix for the win!
> No Scalaz or any other FP-crusader stuff ever
That stuff which some people might consider FP-crusader vanity is something which can make concurrency manageable, maybe even joy.
I encourage you to open your mind, at least for a bit, and have a look at ZIO or Monix.
> Enforce coding rules with linters
Absolutely! Scalafmt and Scalafix for the win!
> By avoiding things like implicit ...
Implicit parameters are nothing more than a terminal argument list which the compiler attempts to provide from "the implicit scope." If you would rather it not, then simply provide them yourself at the point of invocation.
To wit:
HTH
0 - https://docs.oracle.com/javase/7/docs/technotes/tools/window...
Implicit parameters are nothing more than a terminal argument list which the compiler attempts to provide from "the implicit scope." If you would rather it not, then simply provide them yourself at the point of invocation.
To wit:
object HitchhikersGuide
{
implicit val answer : Int = 42;
implicit val question : String = "the universe";
def foo ()
(implicit a : Int, q : String)
: Unit =
System.out.println (s"${q} = ${a}");
// This
foo ();
// Is the same as this
foo () (42, "the universe");
}
HTH
0 - https://docs.oracle.com/javase/7/docs/technotes/tools/window...
This, and traits too!
As I've been learning Scala, traits is the feature that grabbed me and is what convinces me to keep learning. What a brilliant feature that cuts through all the OOP clutter that can come from various patterns to build up functionality. it is the killer feature, I think
As one of those new people boosting recent numbers, Scala is great! I use vscode with Metals and had no jvm experience before. sbt is annoying, Mill seems super promising, and graalvm native images basically mean that if I was going to do it in python, I might as well use scala now.
Scala 3 have a Python feeling over it with optional braces indentation (https://dotty.epfl.ch/docs/reference/other-new-features/inde...)
I wrote an example using this new (optional syntax) https://github.com/olofwalker/ting, if anyone wants to have a look.
I wrote an example using this new (optional syntax) https://github.com/olofwalker/ting, if anyone wants to have a look.
Maybe it’s just me, but “optional” is a word I hate seeing in language design, because I’m thinking of how many code reviewers I’ve met that have a hard time with “optional”.
It's been about 10 years since I did some work with Scala. I really like the syntax and the way your project uses it. Seems immediately legible and simple.
I just use maven for Scala compilation. I want to avoid Turing computable build tools (yes I know u can load plugins with maven but it is at least stiving for a declarative model)
What's your problem with SBT? I've been using IntelliJ + SBT since I started with Scala and it has been working well for me.
Personally I prefer more declarative dependency configuration. Also the IntelliJ integration is terrible. It thinks so many of the files have syntax errors and doesn’t have reliable autocomplete or goto definition. Also I don’t like how many files there are; though to be fair i don’t know how standard our setup is.
Weird. I've never had IntelliJ give me sbt-related syntax errors incorrectly.
I've taken several passes at Scala but the thing that always stops me is that I find it really hard to read unfamiliar code, including the core API implementations. The only Scala code I find easy to read is impure semi-object oriented code which is the non-idiomatic code that the Scala community tries not to write. I'm not sure if there's some point at which a penny drops and it all starts to become easy, but even if that is true, the time period it takes for that to happen is a real hurdle for newcomers.
To me, you have to be intrinsically motivated to become productive in Scala because of that early friction. Which is fine if you are, but if you're looking at a team of programmers and thinking "how do I get them all over that line" when about half of them have no intrinsic motivation to do that, it's a real disincentive to use the language.
To me, you have to be intrinsically motivated to become productive in Scala because of that early friction. Which is fine if you are, but if you're looking at a team of programmers and thinking "how do I get them all over that line" when about half of them have no intrinsic motivation to do that, it's a real disincentive to use the language.
Scala faces tough competition from Kotlin which has two huge platforms - Android and Spring/Pivotal. Arrow (https://arrow-kt.io), is enough to satisfy all but the most zealous FP purists whilst maintaining first-class inter-op with the host language. I foresee a lot of new projects adopting Kotlin where once they might have favoured Scala.
For context see
Lightbend secures 25MM funding round, proceeds to layoff Scala contributors https://news.ycombinator.com/item?id=22842166
Lightbend secures 25MM funding round, proceeds to layoff Scala contributors https://news.ycombinator.com/item?id=22842166
I don't follow Scala (never wrote a single line), so I didn't realize the company changed names from Typesafe to Lightbend. Here's a question: how on earth do they make any money? The Wikipedia article makes an offhand mention of something called Lightbend subscription; is that what keeps them afloat?
Also https://news.ycombinator.com/item?id=22836399 ("Six years at Lightbend")
I love Scala! It's the language that enlightened me and be more productive. Now, every time I code in other languages (e.g. Dart for Flutter, or JS for web stuff), I grumble when I can't find "standard" features such as "map", pattern matching, optional and named params, implicits.
Also, when I code in Scala, I frequently google and end up learning something new about the language. I know it sounds like distraction/wasting time, but there's a certain satisfaction when I found the "Scalaic" way of doing things, like, "There's gotta be a one-liner way of doing this."
Of course, my complain is still compile time (yes it's significantly faster, but I'm impatient).
Also, when I code in Scala, I frequently google and end up learning something new about the language. I know it sounds like distraction/wasting time, but there's a certain satisfaction when I found the "Scalaic" way of doing things, like, "There's gotta be a one-liner way of doing this."
Of course, my complain is still compile time (yes it's significantly faster, but I'm impatient).
You would be enlightened the same way or even more if you started with Haskell. That is, it is not Scala you are so excited about but the functional programming.
Btw, the actual thing to be inspired with in Scala is immutability and Option/Some/None instead of null. These are the things that make you code stable and reliable.
Btw, the actual thing to be inspired with in Scala is immutability and Option/Some/None instead of null. These are the things that make you code stable and reliable.
I wanted Scala to be my "better Java" for a long time, mainly because it seemed to have plentiful headroom as I seek to learn more. The community enthusiasm was also contagious.
But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to...
2) It is hard to pitch to an organization because of the learning curve if you assume any project maintainer must learn scala to expert level. I failed (in one attempt on a scala mailing list) to pitch to the scala community the idea of having language levels: a compiler switch or the like that would guarantee that a given project will be maintainable by java programmers with only N (1-2 I hope, for the first level) hours of scala training or study, maybe another level for adding certain features (or listing them in a config file), and full-on expert. So teams can be formed with realistic long-term maintainability in mind. Edit: This may be practical with add-ons I didn't try yet.
3) It was unclear what would be the best reasonable, maintainable way to use sqlite. (Edit: in a multiplatform way to include at least BSD, linux, windows, mac. Maybe call a native code library for each? Sounds like lots of work and maintenance to do it well.)
4) Startup times, future viability of scala native (edit: or equivalent), and whether it helps or adds enough more complexity given all the above, to just learn Rust and (hopefully) simplify life (in some ways).
5) And you have to learn java first (for those who didn't know it already), and know its libraries and idioms to some extent. Will that still likely be true?
Comments welcome. (I enjoyed the article.) Maybe I'm just the type that wants to hit the sweet spot between what C, Java, and Scala do (edit: and Scheme), in a way that is hopefully/eventually at a complexity level that is inviting to other devs, but with plenty of learning headroom for my future growth.
But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to...
2) It is hard to pitch to an organization because of the learning curve if you assume any project maintainer must learn scala to expert level. I failed (in one attempt on a scala mailing list) to pitch to the scala community the idea of having language levels: a compiler switch or the like that would guarantee that a given project will be maintainable by java programmers with only N (1-2 I hope, for the first level) hours of scala training or study, maybe another level for adding certain features (or listing them in a config file), and full-on expert. So teams can be formed with realistic long-term maintainability in mind. Edit: This may be practical with add-ons I didn't try yet.
3) It was unclear what would be the best reasonable, maintainable way to use sqlite. (Edit: in a multiplatform way to include at least BSD, linux, windows, mac. Maybe call a native code library for each? Sounds like lots of work and maintenance to do it well.)
4) Startup times, future viability of scala native (edit: or equivalent), and whether it helps or adds enough more complexity given all the above, to just learn Rust and (hopefully) simplify life (in some ways).
5) And you have to learn java first (for those who didn't know it already), and know its libraries and idioms to some extent. Will that still likely be true?
Comments welcome. (I enjoyed the article.) Maybe I'm just the type that wants to hit the sweet spot between what C, Java, and Scala do (edit: and Scheme), in a way that is hopefully/eventually at a complexity level that is inviting to other devs, but with plenty of learning headroom for my future growth.
Scala dev here. "Having to learn Java" is not true at all, unless you interact with Java dependencies in special ways, or if you maintain a Java API for your Scala code. There are Scala libraries for almost anything, and it's easy to use some Java libs here and there. Creating wrappers is also simple.
One of the coolest things about Scala it that it already contains lots of Java best practices. Case classes, singleton and companion objects, traits, powerful generics... almost every Scala feature is a builtin answer for a Java pattern. Hell, even implicits in all its various forms are elegant solutions to common Java problems. People getting creative with these features is an entirely different issue. It's possible, and desirable, to use Scala to craft simple, elegant, and understandable code. Fancy but unmaintainable code should not ever be accepted: it's the job of the developer to teach the reader what the code does, and while this is true in any language, is more important when coding Scala, because the multiparadigm approach means there are multiple ways to solve things.
What you have to learn, at least in a basic form, is how the JVM works.
One of the coolest things about Scala it that it already contains lots of Java best practices. Case classes, singleton and companion objects, traits, powerful generics... almost every Scala feature is a builtin answer for a Java pattern. Hell, even implicits in all its various forms are elegant solutions to common Java problems. People getting creative with these features is an entirely different issue. It's possible, and desirable, to use Scala to craft simple, elegant, and understandable code. Fancy but unmaintainable code should not ever be accepted: it's the job of the developer to teach the reader what the code does, and while this is true in any language, is more important when coding Scala, because the multiparadigm approach means there are multiple ways to solve things.
What you have to learn, at least in a basic form, is how the JVM works.
Thanks. I used Scala for some years and was always drawing on my java knowledge. Are there now good scala learning materials that don't assume java knowledge?
And the maintainability issue seems similar to perl vs. python in that way: it can be done, but I've found it takes much more work and long-term attention & presence, to enforce things with code reviews than with a project-level config that everyone knows why it is there. Just once when you are not looking and now you have a new (large or small) social and technical headache.
(Edit: in other words, while code reviews are essential I think for many reasons, any time there is a way to enforce something good, before the review, it seems like a win.)
And the maintainability issue seems similar to perl vs. python in that way: it can be done, but I've found it takes much more work and long-term attention & presence, to enforce things with code reviews than with a project-level config that everyone knows why it is there. Just once when you are not looking and now you have a new (large or small) social and technical headache.
(Edit: in other words, while code reviews are essential I think for many reasons, any time there is a way to enforce something good, before the review, it seems like a win.)
As for learning resources, I always loved the Oreilly "Programming Scala" book: http://shop.oreilly.com/product/0636920033073.do
It's one of the few books that is structured in the same way a Scala developer thinks. Lots of Scala books follow the same order: keywords, usual syntax, features also in Java, features exclusive to Scala. I think this is damaging for any person looking to learn Scala, because it does nothing to lay out the way the features interact together. for instance, the Oreilly book shows pattern matching and implicits before class hierarchies, and that maps well with how Scala devs work, because the former features are encountered daily, while the latter tends to be uncommon.
As for maintainability: you're right. Stricter languages are more maintainable. There's also the issue of powerful languages attracting certain kinds of people. Over the years, I've settled on a simple policy: reject everything that is not documented. This goes for both internal code, and external dependencies.
It's one of the few books that is structured in the same way a Scala developer thinks. Lots of Scala books follow the same order: keywords, usual syntax, features also in Java, features exclusive to Scala. I think this is damaging for any person looking to learn Scala, because it does nothing to lay out the way the features interact together. for instance, the Oreilly book shows pattern matching and implicits before class hierarchies, and that maps well with how Scala devs work, because the former features are encountered daily, while the latter tends to be uncommon.
As for maintainability: you're right. Stricter languages are more maintainable. There's also the issue of powerful languages attracting certain kinds of people. Over the years, I've settled on a simple policy: reject everything that is not documented. This goes for both internal code, and external dependencies.
Another follow-up about my point #2 above: if scala had done this early on (in an armchair hindsight kind of way), I don't know what need there could have been for Kotlin, and we could be learning one language for both purposes (better java and lots of headroom to learn/grow), instead of requiring 2-3 languages or more. Edit: I would appreciate better thoughts to improve my view on that.
I don’t understand your comment about SQLite. Doesn’t the driver manage creating a standard SQLite file? This shouldn’t really be Scala related.
Example connecting: https://github.com/tkawachi/sqlite-scalikejdbc-test/blob/mas...
Example connecting: https://github.com/tkawachi/sqlite-scalikejdbc-test/blob/mas...
Right, it's more of a JVM issue which affects scala. I did a search a while (couple years?) ago and maybe just didn't find the right materials, but they all (in my now-vague memory) seemed awkward and/or were not portable across platforms. Does this approach let you do every kind of sqlite operation, as completely as if from the interactive native client or as if calling it from C? Who maintains it and is it kept in sync with the C version? (Maybe I'll go look that up, but if you already know...) Thanks much for the info.
Edit: ps (maybe a note to myself as much as anything in case I go look up this stuff): And does sqlite run in the same process as the app? Can the app process control the db location?
Edit: ps (maybe a note to myself as much as anything in case I go look up this stuff): And does sqlite run in the same process as the app? Can the app process control the db location?
I don't really know the answer to those questions. But I know SQLite is heavily used in almost every ecosystem so I would be really surprised if there were real blockers.
I know Android uses it a lot, so I opened up an Android project at my company and it looks like the android SDK comes with a bunch of SQLite abstractions, and it's not clear what the underlying driver is. But the SQLite official website ships an Android AAR so maybe that is it? (https://www.sqlite.org/2020/sqlite-android-3310100.aar)
This seems to be the main general-purpose JVM lib: https://github.com/xerial/sqlite-jdbc and it seems to be keeping in lockstep with the official SQLite versions (within a couple months).
Edit: Also can you elaborate on the "in a multiplatform way"? Maybe I'm having a brain-fart or memory-hole but shouldn't you not have to worry about that at all?
Edit2: Looks like there is a nice blurb in the docs on that github page:
I know Android uses it a lot, so I opened up an Android project at my company and it looks like the android SDK comes with a bunch of SQLite abstractions, and it's not clear what the underlying driver is. But the SQLite official website ships an Android AAR so maybe that is it? (https://www.sqlite.org/2020/sqlite-android-3310100.aar)
This seems to be the main general-purpose JVM lib: https://github.com/xerial/sqlite-jdbc and it seems to be keeping in lockstep with the official SQLite versions (within a couple months).
Edit: Also can you elaborate on the "in a multiplatform way"? Maybe I'm having a brain-fart or memory-hole but shouldn't you not have to worry about that at all?
Edit2: Looks like there is a nice blurb in the docs on that github page:
Since sqlite-jdbc-3.6.19, the natively compiled SQLite engines will be used for the following operating systems:
Windows (Windows, x86 architecture, x86_64)
Mac OS X x86_64 (Support for SnowLeopard (i386) has been deprecated)
Linux x86, x86_64, arm (v5, v6, v7 and for android), ppc64
In the other OSs not listed above, the pure-java SQLite is used. (Applies to versions before 3.7.15)
If you want to use the native library for your OS, [build the source from scratch.I think I had found that one, but didn't actually try it. By multiplatform way, I meant avoiding native libraries (sounds like more maintenance and debugging over time) and still being able to run on OpenBSD (or any BSD), linux, windows, and mac, at least.
Edit: yes, I think it does not currently run on OpenBSD, etc. One could contribute that library, but in that case, I'm more inclined to learn Rust and not deal with the JVM at all. Then I also get convenient access to things like pledge() and unveil(), and other OS-specific system calls, when I want. :) I will be grateful, however, for further correction & enlightenment... :)
(Edit2: I have been reading "the book" in Rust, but probably should write a test to confirm that it will make calls to sqlite and pledge() as directly as I think, using the tools I found.)
Edit: yes, I think it does not currently run on OpenBSD, etc. One could contribute that library, but in that case, I'm more inclined to learn Rust and not deal with the JVM at all. Then I also get convenient access to things like pledge() and unveil(), and other OS-specific system calls, when I want. :) I will be grateful, however, for further correction & enlightenment... :)
(Edit2: I have been reading "the book" in Rust, but probably should write a test to confirm that it will make calls to sqlite and pledge() as directly as I think, using the tools I found.)
[deleted]
Scala has the reputation of being fun to create stuff with, but horrendous when understanding other people’s creations. Is this still true?
It's less true now because some of the patterns associated with code that's difficult to understand have been deprecated or flagged by the community to avoid.
For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern.
Another example is that it's now (more or less) recognized within the community that it's not preferable to dogmatically adhere to a particular style of programming, such as pure functional or reactive/actors. It's better to use the right tool for the right problem.
Whole classes of confusing code are now prevented or mitigated by language changes in Scala 3. For example, Scala 2's implicits are famously hard to learn and follow within a codebase. One reason for this is that in Scala 2 the keyword "implicit" was overloaded into a few common patterns, including the aforementioned implicit conversions, typeclass instances, and dependency injection. Scala 3 introduces new constructs and keywords to split out these patterns into separate language features, making them easier to learn and more understandable within a codebase.
For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern.
Another example is that it's now (more or less) recognized within the community that it's not preferable to dogmatically adhere to a particular style of programming, such as pure functional or reactive/actors. It's better to use the right tool for the right problem.
Whole classes of confusing code are now prevented or mitigated by language changes in Scala 3. For example, Scala 2's implicits are famously hard to learn and follow within a codebase. One reason for this is that in Scala 2 the keyword "implicit" was overloaded into a few common patterns, including the aforementioned implicit conversions, typeclass instances, and dependency injection. Scala 3 introduces new constructs and keywords to split out these patterns into separate language features, making them easier to learn and more understandable within a codebase.
> For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern.
Oh God I'm having flashbacks to using Lift in... 2012? There were about four levels of implicit conversions between my model and the final JSON, trying to understand that was hard.
That said, David Pollak the founder of Liftweb was amazingly helpful on on their mailing list.
Oh God I'm having flashbacks to using Lift in... 2012? There were about four levels of implicit conversions between my model and the final JSON, trying to understand that was hard.
That said, David Pollak the founder of Liftweb was amazingly helpful on on their mailing list.
> For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern.
I don't have experience with Scala 3 or Scala 2.13, but I don't believe this is true. Implicit conversions cannot be applied more than once.
I don't have experience with Scala 3 or Scala 2.13, but I don't believe this is true. Implicit conversions cannot be applied more than once.
Haha, I thought it was only me who thought this way :) I did enjoy learning Scala. It expanded my horizon. And, I enjoyed coding in it.
The code written by experts were at a whole another level. Couldn't make much sense of them. Maybe I could understand one line at a time, but the design patterns appeared hard to understand after my ~12 months Scala experience and over a decade of programming.
That said, the expert code looked amazingly beautiful :)
The code written by experts were at a whole another level. Couldn't make much sense of them. Maybe I could understand one line at a time, but the design patterns appeared hard to understand after my ~12 months Scala experience and over a decade of programming.
That said, the expert code looked amazingly beautiful :)
Since the syntax didn't (and cannot) become any less flexible, it's unfortunately still true and always will be. As annoying as it is to struggle with the rigid syntax of Java while writing it (which also results in overly verbose code), reading it is far easier than Scala (or even Kotlin in some cases), because Java code always looks like Java code.
And since we spend way more time looking at and interpreting other people's code than writing our own, personally I think Java is better for large projects. I wish it wasn't the case but it is.
And since we spend way more time looking at and interpreting other people's code than writing our own, personally I think Java is better for large projects. I wish it wasn't the case but it is.
You can't even imagine how. Reading a code base written by 1 person in the span of 5 years is a quest. Now, imagine the person goes on a vacation.
What's with the quote's casual Clojure dissing? Clojure seems more popular and growing more than Scala, from where I sit. Kotlin is not eating into Clojure's user base like Scala, which makes sense.
Since the post mentions Scala Native, all these guest language projects that eschew the platform that made them famous and try to pursue the dream of being their own platform, while building an ecosystem, GC and optimising compiler from scratch (even if they build on LLVM or compile via C/C++), would be much better taking advantage of AOT and JIT caches from several JVM implementations instead of pretending they don't exist.
In my mind, GraalVM native compilation has superseded scala-native.
GraalVM native compilation works really well. Many projects will compile to native out of the box. Many more with a bit of reflection config that's autogenerated. The native executables are slim, statically linked so they "just work", and startup instantly as one would expect.
Scala is now a great choice for CLI tools.
GraalVM native compilation works really well. Many projects will compile to native out of the box. Many more with a bit of reflection config that's autogenerated. The native executables are slim, statically linked so they "just work", and startup instantly as one would expect.
Scala is now a great choice for CLI tools.
Native image works well without dependencies. I tried to get Weld and other JEE deps running in a smaller project and it was foot gun after footgun.
I'm hoping in the future the native-image friction can be lowered, but as of now it's not trivial like other languages.
I'm hoping in the future the native-image friction can be lowered, but as of now it's not trivial like other languages.
> statically linked so they "just work"
If I remember correctly you have to redistribute some .dll (VC something) file alongside your .exe on Windows since fresh Windows installations don't have the .dll. Did that change?
If I remember correctly you have to redistribute some .dll (VC something) file alongside your .exe on Windows since fresh Windows installations don't have the .dll. Did that change?
I haven't tried GraalVM native-image on Windows :(
> The native executables are slim
What's the size of hello_world.exe?
What's the size of hello_world.exe?
Dunno about Scala, but Clojure - another JVM language, has a GraalVM native executable for Hello WOrld about 8MB.
Not that slim.
Not that slim.
How does that compare to similar languages? (Go, Nim, D, etc).
For reference:
$ \cat hellogo.go
package main
import "fmt"
func main() {
fmt.Println("hello")
}
$ go build hellogo.go
$ \cat hellonim.nim
echo "hello"
$ nim c hellonim.nim
...
$ ll
total 2.2M
-rwxr-xr-x 1 kbd staff 2.1M Apr 11 20:55 hellogo*
-rw-r--r-- 1 kbd staff 66 Apr 11 20:42 hellogo.go
-rwxr-xr-x 1 kbd staff 87K Apr 11 20:55 hellonim*
-rw-r--r-- 1 kbd staff 13 Apr 11 20:29 hellonim.nim
Not too bad if it's truly statically linked though ...
Are they statically linked by default now?
Last I looked (a couple of months ago) the executable produced linked dynamically but there was a flag to link statically.
Last I looked (a couple of months ago) the executable produced linked dynamically but there was a flag to link statically.
Looking at the commit log, Scala Native looks pretty dead https://github.com/scala-native/scala-native/commits/master
Previous maintainer left EPFL so nothing was happening there. But Scala Center took over the project so they will start maintaining it. AFAIR snnouncement was on Gitter by the same guy who maintains Scala.js. I guess it will take some time for them to catch up with the rest.
I'm particularly interested in how this plays out with dotty. My understanding was that lightbend was at some going to take over that compiler from EPFL, but taking over a compiler (the second, besides the current/old one) at the same time they are laying people off?
Announcement on Dotty as the future Scala 3 came from Scala Center (EPFL) not Typesafe/Lightbend.
AFAIK Typesafe/Lightbend has made no commitment to Scala 3.
Too bad the roadmap for Scala 2.14 has been scrapped.
AFAIK Typesafe/Lightbend has made no commitment to Scala 3.
Too bad the roadmap for Scala 2.14 has been scrapped.
I've worked with Dotty a bit and read about it a lot.
I am very excited about Scala 3 :)
Scala 3 isn't a python2/python3 situation. It will take years for large codebases to be upgraded to Scala 3. However, the tools to migrate code from Scala 2 to Scala 3 will be reliable and highly automated, due to Scala's strong type system. Most popular Scala libraries and frameworks will be available on Scala 3 right from the get-go. I expect that most Scala programmers and companies will want to write Scala 3 code asap.
Within the Scala community, the only truly divisive aspect of Scala 3 afaik is the introduction of optional python-style and Haskell-style syntax with significant whitespace. I was stridently against significant whitespace and now prefer it after having tried coding Scala 3 for awhile.
I am very excited about Scala 3 :)
Scala 3 isn't a python2/python3 situation. It will take years for large codebases to be upgraded to Scala 3. However, the tools to migrate code from Scala 2 to Scala 3 will be reliable and highly automated, due to Scala's strong type system. Most popular Scala libraries and frameworks will be available on Scala 3 right from the get-go. I expect that most Scala programmers and companies will want to write Scala 3 code asap.
Within the Scala community, the only truly divisive aspect of Scala 3 afaik is the introduction of optional python-style and Haskell-style syntax with significant whitespace. I was stridently against significant whitespace and now prefer it after having tried coding Scala 3 for awhile.
Thanks for this info, very useful and exciting.
I stopped using scala around 5 years back, want to get back to it. Would you recommend jumping straight to dotty? I’ve been doing a mostly python and a bit of Haskell in the meantime.
I stopped using scala around 5 years back, want to get back to it. Would you recommend jumping straight to dotty? I’ve been doing a mostly python and a bit of Haskell in the meantime.
I'd jump straight to dotty! You may as well learn the latest 'n greatest.
> It will take years for large codebases to be upgraded to Scala 3
Which for production level code bases means never. I can't even imagine what we are going to do with our 7 year old Scala code base.
Which for production level code bases means never. I can't even imagine what we are going to do with our 7 year old Scala code base.
It's the Java 1.4/Java 6/Java 8 problem all over again. Big companies refuse to keep up with the base languages, and important parts of the ecosystem (e.g. Spark) fall behind the language.
2.14 was supposed to be a stepping stone between 2 and 3, released only so that migration could be easier. They skipped it because apparently source code differences between valid 2.13 and 3.0 aren't that great. From what I saw it is mostly about migrating macros, the rest most likely would still work.
Farewells piling up:
Six years at Lightbend, by Eugene Yokota (Scala sbt, scalaxb, scopt) https://news.ycombinator.com/item?id=22836399
Six years at Lightbend, by Eugene Yokota (Scala sbt, scalaxb, scopt) https://news.ycombinator.com/item?id=22836399
I think a major reason Scala flourished was a big reason it has struggled as well: it opened the doors for many people to new and fundamentally different programming paradigms such as actor systems and functional programming. Many people got excited and implemented these new paradigms in production systems without regard to the immaturity of their own grasp of the concepts (think of how many years of imperative/OO programming you had under your belt before feeling confident of setting the style for a project), the learning curve they were non-consensually committing their coworkers to, and the hiring, productivity, and morale burden they were saddling their employers with. From the management point of view, allowing Scala in the door meant running the risk of waking up one day with a bunch of Scalaz in the codebase, one grinning functional programmer happy as a pig in shit, and the rest of the team shouting and cursing.
Likewise, on top of the real problems created by ill-conceived adoption, the irrational backlash against new paradigms is real as well. I'm old enough to remember the fuss over OO programming. Many experienced, successful coders were scared that they were about to become personally obsolete. Some OO proponents insinuated — and panicked veteran coders believed — that a large number of procedural programmers would have to retire or switch careers because they were too old or not intellectually nimble enough to adapt to object-oriented programming. Major companies such as Sun responded to these fears with a marketing blitz to prove their their OO technology was simple and easy to learn and would herald a new age of programmer productivity. Programmer culture was more driven by magazines and books in those days and therefore much more easily influenced by industry marketing. The "simplicity" of Java was an invention of Sun marketing, a successful self-fulfilling prophecy as Java became so familiar that similarity to it became millions of programmers' benchmark of simplicity.
There has been no total war marketing blitz for functional or actor-based programming from a company with the same stature that Sun had in the 1990s. The emotional reaction, the resentment at feeling a step behind the future, the anxiety about whether you will ever be as comfortable and confident in the new paradigm, operate virtually in a vacuum, or worse, in the echo chamber of the internet. Whatever latent fear of functional programming a person feels, the prospect of using Scala will bring it to the fore. The only countervailing force is the (usually lone) individual pushing adoption, and they are unlikely to be up to the challenge. There is a tension between programmers who are more oriented towards business problems, or who just want to get their job done and go home, and the programmers who get excited about different and potentially better ways to express programs. They both think of themselves as humble and results-oriented and have a hard time accepting each other as being equally humble and results-oriented in their own way. They both experience the other as snobbish, condescending, and threatening to their self-image as good engineers.
Sadly, the root of the problem is that Scala is expressive and powerful enough to be a natural vehicle for these new paradigms. An engineering organization should not fear expressive power, because they should have a culture that is incompatible with a single engineer (or a small cabal) committing their peers to a learning curve without consultation, debate over the cost and payoff, and buy-in from the team. Unfortunately, there seems to be an assumption that beyond choosing a language, you have no ability to consciously choose a style. I.e., Scala-as-a-better-Java (the least imaginative approach, but not a bad one) is an impossibility. This is grounded in the assumption that any aspect of a language that can be abused, will be abused, and that engineers cannot make collective decisions about how they will work together, which are odd assumptions to make about the behavior of highly paid professionals. As someone who wrote C++ professionally for many years, I can testify that it is possible for engineers to conform to coding standards that restrict them to a strict subset of the expressive power of a language. However, it sometimes requires management authority to bring people in line -- and perhaps this is a deal-breaker in an industry where teams of engineers are supposed to be entirely self-managing.
Likewise, on top of the real problems created by ill-conceived adoption, the irrational backlash against new paradigms is real as well. I'm old enough to remember the fuss over OO programming. Many experienced, successful coders were scared that they were about to become personally obsolete. Some OO proponents insinuated — and panicked veteran coders believed — that a large number of procedural programmers would have to retire or switch careers because they were too old or not intellectually nimble enough to adapt to object-oriented programming. Major companies such as Sun responded to these fears with a marketing blitz to prove their their OO technology was simple and easy to learn and would herald a new age of programmer productivity. Programmer culture was more driven by magazines and books in those days and therefore much more easily influenced by industry marketing. The "simplicity" of Java was an invention of Sun marketing, a successful self-fulfilling prophecy as Java became so familiar that similarity to it became millions of programmers' benchmark of simplicity.
There has been no total war marketing blitz for functional or actor-based programming from a company with the same stature that Sun had in the 1990s. The emotional reaction, the resentment at feeling a step behind the future, the anxiety about whether you will ever be as comfortable and confident in the new paradigm, operate virtually in a vacuum, or worse, in the echo chamber of the internet. Whatever latent fear of functional programming a person feels, the prospect of using Scala will bring it to the fore. The only countervailing force is the (usually lone) individual pushing adoption, and they are unlikely to be up to the challenge. There is a tension between programmers who are more oriented towards business problems, or who just want to get their job done and go home, and the programmers who get excited about different and potentially better ways to express programs. They both think of themselves as humble and results-oriented and have a hard time accepting each other as being equally humble and results-oriented in their own way. They both experience the other as snobbish, condescending, and threatening to their self-image as good engineers.
Sadly, the root of the problem is that Scala is expressive and powerful enough to be a natural vehicle for these new paradigms. An engineering organization should not fear expressive power, because they should have a culture that is incompatible with a single engineer (or a small cabal) committing their peers to a learning curve without consultation, debate over the cost and payoff, and buy-in from the team. Unfortunately, there seems to be an assumption that beyond choosing a language, you have no ability to consciously choose a style. I.e., Scala-as-a-better-Java (the least imaginative approach, but not a bad one) is an impossibility. This is grounded in the assumption that any aspect of a language that can be abused, will be abused, and that engineers cannot make collective decisions about how they will work together, which are odd assumptions to make about the behavior of highly paid professionals. As someone who wrote C++ professionally for many years, I can testify that it is possible for engineers to conform to coding standards that restrict them to a strict subset of the expressive power of a language. However, it sometimes requires management authority to bring people in line -- and perhaps this is a deal-breaker in an industry where teams of engineers are supposed to be entirely self-managing.
Scala is an awesome language and studying it helped me improve as a programmer more than I can describe.
That being said, even though Haoyi said he doesn’t think Java has “caught up”, the fact is it has closed the gap significantly on the language side, and will always remain ahead in other ways (performance as one example). OpenJDK 14 is an outstanding general purpose development platform, and the days are long gone of anyone actually _needing_ an alternate JVM based language, whereas 10 years ago (or maybe even 5) there was a desperate need.
That being said, even though Haoyi said he doesn’t think Java has “caught up”, the fact is it has closed the gap significantly on the language side, and will always remain ahead in other ways (performance as one example). OpenJDK 14 is an outstanding general purpose development platform, and the days are long gone of anyone actually _needing_ an alternate JVM based language, whereas 10 years ago (or maybe even 5) there was a desperate need.
If you think of it in terms of the words "need" and "alternative" then you will find a reason not to use Scala. Personally, I have found it painful to watch Java tack on Scala features years late and in awkward and clumsy ways. Encountering ideas first in Scala and then in Java is too often like learning math from a modern textbook and then looking at the same math in a textbook from a hundred years ago. You appreciate how decades of small improvements have made the subject less intellectually taxing despite the fundamental content not changing at all. For Java to end up on the wrong side of this comparison even when it implements features years later, to me marks it as a language in terminal decline, no matter if its popularity has begun to reflect it yet.
>Currently Scala is overwhelmingly used for backend services and/or Spark data pipelines,
This is also being taken over by Python. Databricks Koalas is a pandas interface on top of Spark - https://koalas.readthedocs.io/en/latest/
PySpark was already there (and very much in production). But Koalas (in beta) completely changes the go-to production aspects of spark.
This is also being taken over by Python. Databricks Koalas is a pandas interface on top of Spark - https://koalas.readthedocs.io/en/latest/
PySpark was already there (and very much in production). But Koalas (in beta) completely changes the go-to production aspects of spark.
I'm sad not because Scala is dying but because it will embolden the many loud voices who like to proclaim it as dying, while others will believe them. Meanwhile, it will continue to progress. I became a better java programmer, a better php programmer, and a better javascript programmer by studying Scala. I became better at distributed systems concepts by studying Akka. I'm sure I will become better at a lot of other things by studying Akka Typed and Dotty. It's a language that clarifies your thinking in a way that brings better practices to other spheres. It's absolutely worth learning.
I've also had the experience of using it on undisciplined teams and that sucked. One overly "clever" programmer can turn off a sufficient number of other programmers and give it a bad rep. I don't think a language being expressive is sufficient cause to blame the language for that, though.
I've also had the experience of using it on undisciplined teams and that sucked. One overly "clever" programmer can turn off a sufficient number of other programmers and give it a bad rep. I don't think a language being expressive is sufficient cause to blame the language for that, though.
>it seemed to peak around 2016
https://trends.google.com/trends/explore?cat=5&date=all&geo=...
Early 2017, perhaps! Are Go and Rust seen as competitors to Scala?
https://trends.google.com/trends/explore?cat=5&date=all&geo=...
Early 2017, perhaps! Are Go and Rust seen as competitors to Scala?
Remember that Google Trends just measures search traffic. Also, handy tip, select "Programming Language" instead of "Term", the graph changes slightly with that: https://trends.google.com/trends/explore?cat=5&date=all&geo=...
Another tip, by default Google Trends just show data from the US, which is not very interesting, select Wordwide to get a better picture: https://trends.google.com/trends/explore?cat=5&date=all&q=%2...
Competitors are hard to say as there would different categories. Some workplaces would only choose a JVM language, then Scala's competitors are Java itself, Clojure and alike.
Go and Rust have mainly been described as "system" languages but they take vastly different approaches from each other.
If you be a bit more specific on what you're compared them on, it'll be easier to know if they are competitors or not.
Another tip, by default Google Trends just show data from the US, which is not very interesting, select Wordwide to get a better picture: https://trends.google.com/trends/explore?cat=5&date=all&q=%2...
Competitors are hard to say as there would different categories. Some workplaces would only choose a JVM language, then Scala's competitors are Java itself, Clojure and alike.
Go and Rust have mainly been described as "system" languages but they take vastly different approaches from each other.
If you be a bit more specific on what you're compared them on, it'll be easier to know if they are competitors or not.
I was interested in Scala and used various tools/hacks to build Android apps with it. Very neat language but the pain for building on Android was too much for me - I stopped using Scala around 2016/2017 as Kotlin became viable (and is now extremely well supported) on Android.
Depends who Scala was a competitor to.
If you viewed Scala as a competitor to Java, then Go is a competitor to Scala and not Rust; because Go is a competitor to Java in my opinion.
If you viewed Scala as a competitor to Java, then Go is a competitor to Scala and not Rust; because Go is a competitor to Java in my opinion.
Go is a competitor to Java 1.0, it still needs to grow a bit more if it wants to compete with Java 14 and its 25 years of tooling and libraries.
If Go 2.0 ever happens, it will be a competitor to Java 5.
If Go 2.0 ever happens, it will be a competitor to Java 5.
So, it depends on what you’re talking about; language or organizational need.
Go is an imperfect match for Java The language, largely because of the whole Generics thing. But if you’re talking about how teams use Java and Go, they’re a good match now.
Go was designed for large companies like Google to have a huge number of engineers and produce consistent, quality code, all while constantly on boarding people and moving them around. From an organizational perspective there are a ton of Java shops that use Java for similar reasons, plus the ability to cheaply and quickly acquire contractors who know Java.
Go is an imperfect match for Java The language, largely because of the whole Generics thing. But if you’re talking about how teams use Java and Go, they’re a good match now.
Go was designed for large companies like Google to have a huge number of engineers and produce consistent, quality code, all while constantly on boarding people and moving them around. From an organizational perspective there are a ton of Java shops that use Java for similar reasons, plus the ability to cheaply and quickly acquire contractors who know Java.
Both, people comparing Go to Java apparently lack a complete understanding of the Java universe.
If you are talking about doing REST APIs, talking to Postgres in Java 1.0 servlets style code, yeah Go is a replacement for Java.
Except that is like 1% of everything that is currently being done in Java.
If you are talking about doing REST APIs, talking to Postgres in Java 1.0 servlets style code, yeah Go is a replacement for Java.
Except that is like 1% of everything that is currently being done in Java.
Go is a competitor to Java in that most of the things people do with one, they could do with the other.
As a Java guy, i would agree that Go is not actually competitive with Java. But then, a Go guy would probably say the opposite.
As a Java guy, i would agree that Go is not actually competitive with Java. But then, a Go guy would probably say the opposite.
Really? Where are the Go versions of Spring, JEE, Android, Solr, Liferay, Kafka, Gemalto, microEJ, PTC, Aicas, Ricoh, Kyocera, Java Card, VisualVM, JFR, JMX and plenty of other stuff I haven't bothered to type?
You really should not have started with spring and jee
Not understanding why they exist is the first error trying to sell to enterprise.
Seeing how .Net is being sold to enterprises without such libraries I would say that they exist because business happily buys into any promise that something increases productivity even if that is just salesmen's lies. But it requires good salesmen not good engineers.
Actually it does have many of those libraries, they just come with a different name, or in commercial only form, without the FOSS variants from Java.
Avoiding the necessity for libraries like many of these would be a key success criteria for a new language were I judging.
Then don't expect to actually take over Java on the domains it owns.
Why Java devs automatically assume that every new language is made to overthrow Java/C#? They might still to provide better development in a particular domain. Go or Python or JacaScript are good at rivaling Java at mainstream language, and so what?
Because that is what the "every new language" crowd keeps selling, without understanding how they got there.
I know people who would be sold on NO JEE, NO Spring, NO Hibernate. I am one of them. :)
I have to say if they add generics without type erasure to go then Java is likely in trouble.
A language feature alone doesn't replace an ecosystem with 25 years of production experience across platforms that aren't even supported by Go.
After getting generics, Go still needs to offer JFR/JMX/VisualVM like monitoring and dynamic code loading capabilities (Go plugins are very limited), JEE/Spring like Web tooling, Liferay/AEM/Magnolia like CMSs, an OS of its own and real time GC, card chips, M2M hardware gateways, printer enterprise configuration appps, and plenty of other use cases that many on HN seem unaware of its existence in enterprise scenarios.
After getting generics, Go still needs to offer JFR/JMX/VisualVM like monitoring and dynamic code loading capabilities (Go plugins are very limited), JEE/Spring like Web tooling, Liferay/AEM/Magnolia like CMSs, an OS of its own and real time GC, card chips, M2M hardware gateways, printer enterprise configuration appps, and plenty of other use cases that many on HN seem unaware of its existence in enterprise scenarios.
Good. Here I was thinking Java 17 to be released in 2021 will be competitor to Go 1.0 when it finally have value types.
Yeah, meanwhile Gonuts will still be discussing what is the best way to add generics, while it's users on Hacker News keep telling us that it isn't political and there is a working prototype at Google.
So where is the EA for generics like the value types EA I can download today from OpenJDK repository?
So where is the EA for generics like the value types EA I can download today from OpenJDK repository?
To be fair, apparently this appears to be the current internal prototype, https://go-review.googlesource.com/c/go/+/187317
It still appears quite far from being done in 2021, though.
It still appears quite far from being done in 2021, though.
> It's not Clojure-dead
What does this mean? I thought Clojure has a dedicated, if small, user base.
What does this mean? I thought Clojure has a dedicated, if small, user base.
I guess in the authors mind, dead here means it's stable, solves its problems well and doesn't try to attract developers with shiny new features but instead focuses on enhancing the core experience which gets better.
As a Clojure/Script developer, I could understand that Clojure looks dead from the outside if you're a JS developer, you're used to new language features being shoehorned into the language every year.
But for someone inside the Clojure ecosystem who used to be a JS developer, it's a breath of fresh air when I can take a 4 year old library and include it, everything works and no bugs are to be found. If there is a bug, I can patch it from the outside, if I really have to.
Clojure in general lends itself very well to be extended from the outside (like what clojure.spec is currently doing [and many others]) so the core language doesn't really have to change anymore, we're just building libraries on top of the language which extends the language.
As a Clojure/Script developer, I could understand that Clojure looks dead from the outside if you're a JS developer, you're used to new language features being shoehorned into the language every year.
But for someone inside the Clojure ecosystem who used to be a JS developer, it's a breath of fresh air when I can take a 4 year old library and include it, everything works and no bugs are to be found. If there is a bug, I can patch it from the outside, if I really have to.
Clojure in general lends itself very well to be extended from the outside (like what clojure.spec is currently doing [and many others]) so the core language doesn't really have to change anymore, we're just building libraries on top of the language which extends the language.
The dig at JS developers is completely uncalled-for.
I'm a JS developer and I admire the way Clojure has seemed to skip both the hype and disillusionment phases and jump straight to the productivity plateau.
I'm a JS developer and I admire the way Clojure has seemed to skip both the hype and disillusionment phases and jump straight to the productivity plateau.
I'm also a JS developer myself, so I guess the dig includes myself too (99% of my time is spent with ClojureScript). JavaScript was just a example out of many. Same with Java or basically most languages, where you can't change the core language from the outside without forking it. I don't think anyone will deny that some languages add features just to satisfy a smaller part of it's users, because there is no other way for those people to get their features.
Because of it's dynamic nature, there is no plateau in Clojure (lisps in general), the responsibility just shifted to outside the core language that Rich Hickey et al maintains.
Because of it's dynamic nature, there is no plateau in Clojure (lisps in general), the responsibility just shifted to outside the core language that Rich Hickey et al maintains.
> The dig at JS developers is completely uncalled-for.
Oh, no, as a developer who dealt with web front-ends for a long time, I can attest - it is totally justified.
Modern Javascript, in just a matter of a few years from being a small, simple language with a few quirks has blown into this colossal monstrosity. ECMAScript specification today is almost as big as Java's. There are tons of things that were added ( and still being added ) without careful thinking and upfront design. And that not to mention things that break all the time in the ecosystem of any JS framework. Have you ever tried updating dependencies in a nodejs project that is just a few months old? It rarely is simple and straightforward. Things break left and right. It feels there's no stability at all, compared to Clojure(script) projects. You can pretty much pick any Clojure project (that is a few years old) and update its dependencies, and most of the time, you can expect things not to break.
People got excited about React hooks, and Clojurescript people were like: "folks, we've had a better way of dealing with stateful components for a few years now."
JS devs got excited about destructuring (which looks like a weak attempt to borrow it from Clojure), without even slightest hint of how much more straightforward and cooler destructuring actually looks and works in Clojure.
They say they love JSX, which, compared to Clojure's Hiccup, is just a total and absolute crap.
JS devs are eager to use nulish coalescing and optional chaining and write unreadable crap like: `input ?? obj?.key ? 'yes' : 'no'``. And they dare to say that Lisps are not readable? ¯\_(ツ)_/¯
Honestly, after years of dealing with it, my take on it is this: Javascript is a morally outdated programming language. And Typescript is somewhat not the best attempt to fix its issues.
Oh, no, as a developer who dealt with web front-ends for a long time, I can attest - it is totally justified.
Modern Javascript, in just a matter of a few years from being a small, simple language with a few quirks has blown into this colossal monstrosity. ECMAScript specification today is almost as big as Java's. There are tons of things that were added ( and still being added ) without careful thinking and upfront design. And that not to mention things that break all the time in the ecosystem of any JS framework. Have you ever tried updating dependencies in a nodejs project that is just a few months old? It rarely is simple and straightforward. Things break left and right. It feels there's no stability at all, compared to Clojure(script) projects. You can pretty much pick any Clojure project (that is a few years old) and update its dependencies, and most of the time, you can expect things not to break.
People got excited about React hooks, and Clojurescript people were like: "folks, we've had a better way of dealing with stateful components for a few years now."
JS devs got excited about destructuring (which looks like a weak attempt to borrow it from Clojure), without even slightest hint of how much more straightforward and cooler destructuring actually looks and works in Clojure.
They say they love JSX, which, compared to Clojure's Hiccup, is just a total and absolute crap.
JS devs are eager to use nulish coalescing and optional chaining and write unreadable crap like: `input ?? obj?.key ? 'yes' : 'no'``. And they dare to say that Lisps are not readable? ¯\_(ツ)_/¯
Honestly, after years of dealing with it, my take on it is this: Javascript is a morally outdated programming language. And Typescript is somewhat not the best attempt to fix its issues.
TypeScript adds that extra Java smell back into the mix ;)
Clojure did have quite a bit of hype 5-10 years ago and a bit of slowdown in 2017-2018 where this meme of "Clojure is dead" probably started.
Agree. But slowdown in internet hype doesn’t mean slowdown in industry adoption though.
Indeed and probably there is no perfect measure for this. One way to look at it is Maven download data (https://i.imgur.com/66yEO9C.png) where it continues to increase. Another is to look at Google Trends data (https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...) where it seems like it's decreasing in searches.
It's currently used by 2.9% of devs, vs. 2.5% for scala.
(Search for JVM language report)
Yet another way of measuring (also without providing any type of source, searching "JVM Language Report" brings up a dozen of different results, whereas the first one lists Clojure as being 3% and Scala as 2.36%, can you just link the source instead of asking people to do your sourcing for you?) that is also not perfect.
In the end, we will never know the "real" numbers, and developers like me who use Clojure and find themselves most productive in it, could not care less either.
In the end, we will never know the "real" numbers, and developers like me who use Clojure and find themselves most productive in it, could not care less either.
With the biggest brazilian fintech buying cognitech and moving away from the consulting business, any chances to create the synergy that would merge scala and clojure efforts in this front ? Gave scala the same support or attract the functional crowd ?
That statement indicates that the author is not part of the Clojure community. My company uses Clojure and I know of many fintechs that also use Clojure as their primary language and are actively hiring. It is not a large community by any means, but it is very much alive.
Right? I thought it's one of the most popular Lisps.
It's a particularly ugly and distasteful aspect of software / programmer culture to declare anything that isn't either ubiquitous or in the middle of it's hype cycle to be "dead" - even when used by millions of people and providing huge value etc.
It doesn't serve anybody's interests: for all of us, nearly everything we are passionate about in software will be declared "dead" even one day, with this logic. I usually interpret someone saying "X is dead" as saying more about the person expressing it than the language or software they are talking about.
It doesn't serve anybody's interests: for all of us, nearly everything we are passionate about in software will be declared "dead" even one day, with this logic. I usually interpret someone saying "X is dead" as saying more about the person expressing it than the language or software they are talking about.
Once I saw that I could tell it was news from an alternate timeline and ducked out.
Scala and the Play Framework became my tool belt for whatever web application I need.
It has all the batteries included, it’s stable and rock-solid.
It never felt so good to use a “boring” stack.
[deleted]
Hands down, Scala is my favorite language. The world-class type system combined with its very practical nature make it a natural fit for really any server backend. And now with GraalVM, Scala hopefully will make inroads into desktop and command-line apps (start-up time has always been an issue, until now). Scala 3 looks pretty amazing and the future is bright!
> It's not Clojure-dead
It never ceases to amaze me. Almost every single time, whenever there's a post or a comment on HN that mentions Clojure or Clojurescript, there's always someone from outside of the Clojure community attacking the language, saying things that are simply untrue. Like people are afraid of it becoming too successful. It's not some zero-sum game - the success of one language ecosystem doesn't mean that your other, the more favorite tool would be immediately forgotten.
Somehow I don't see Clojure people attacking other languages; they instead learn and borrow from them.
- Python people would be like: "you can't do machine learning stuff...", and what Clojure people say? Instead of fighting Python, they're like: "We can¹, and also We have nothing against Python, we'll figure out a way to talk to it from Clojure.²"
- Golang people would be: "CSP be is cool," Clojure people: "Awesome, we'll borrow it just the way how you did it. Also, we like Golang, we're going to write a Clojure interpreter and linter in it.³"
- R people: "Clojure is data-driven? Pfff... you know nothing about statistics ...." Clojure people: - "Oh yeah R is cool, btw. we've just figured out a way to interop from Clojure⁴."
- Elixir people: "BEAM is way better than your JVM crap...", Clojure people: "Not really, but okay, we see your point, we'll build Clojure on BEAM⁵"
- JS/TS people say things like "Modern Javascript is so nice, who needs Clojure now?" They get excited about stuff like React Hooks, and Clojure people: "Hmmm... actually we had a better way of dealing with stateful UI components for a few years now. We've been trying to tell you, but you never listened..."
They've been saying, "Clojure is dead" for years now. But despite all the odds, Clojure is very much alive and thriving. It's the most popular language within languages with a strong FP emphasis. Just look around - it has more books, more jobs, more podcasts, more conferences, and meetups than of Haskell, OCaml, Purescript, Elm, Elixir, F#.
I suggest people from other PL communities learn from Clojure people. It is a small but diverse and very friendly community of pragmatists - while others keep shoveling the same shit from one corner to another, trying to re-invent things over and over again, Clojurists keep borrowing good ideas and filtering out bad ones. And calmly and quietly keep building cool stuff and getting paid for it⁶.
¹ https://dragan.rocks
² https://github.com/clj-python/libpython-clj
³ https://github.com/candid82/joker
⁴ https://github.com/scicloj/clojisr
⁵ https://github.com/clojerl/clojerl
⁶ https://bit.ly/3a3wxNH
It never ceases to amaze me. Almost every single time, whenever there's a post or a comment on HN that mentions Clojure or Clojurescript, there's always someone from outside of the Clojure community attacking the language, saying things that are simply untrue. Like people are afraid of it becoming too successful. It's not some zero-sum game - the success of one language ecosystem doesn't mean that your other, the more favorite tool would be immediately forgotten.
Somehow I don't see Clojure people attacking other languages; they instead learn and borrow from them.
- Python people would be like: "you can't do machine learning stuff...", and what Clojure people say? Instead of fighting Python, they're like: "We can¹, and also We have nothing against Python, we'll figure out a way to talk to it from Clojure.²"
- Golang people would be: "CSP be is cool," Clojure people: "Awesome, we'll borrow it just the way how you did it. Also, we like Golang, we're going to write a Clojure interpreter and linter in it.³"
- R people: "Clojure is data-driven? Pfff... you know nothing about statistics ...." Clojure people: - "Oh yeah R is cool, btw. we've just figured out a way to interop from Clojure⁴."
- Elixir people: "BEAM is way better than your JVM crap...", Clojure people: "Not really, but okay, we see your point, we'll build Clojure on BEAM⁵"
- JS/TS people say things like "Modern Javascript is so nice, who needs Clojure now?" They get excited about stuff like React Hooks, and Clojure people: "Hmmm... actually we had a better way of dealing with stateful UI components for a few years now. We've been trying to tell you, but you never listened..."
They've been saying, "Clojure is dead" for years now. But despite all the odds, Clojure is very much alive and thriving. It's the most popular language within languages with a strong FP emphasis. Just look around - it has more books, more jobs, more podcasts, more conferences, and meetups than of Haskell, OCaml, Purescript, Elm, Elixir, F#.
I suggest people from other PL communities learn from Clojure people. It is a small but diverse and very friendly community of pragmatists - while others keep shoveling the same shit from one corner to another, trying to re-invent things over and over again, Clojurists keep borrowing good ideas and filtering out bad ones. And calmly and quietly keep building cool stuff and getting paid for it⁶.
¹ https://dragan.rocks
² https://github.com/clj-python/libpython-clj
³ https://github.com/candid82/joker
⁴ https://github.com/scicloj/clojisr
⁵ https://github.com/clojerl/clojerl
⁶ https://bit.ly/3a3wxNH
Hmm, I don't like the concept of talking about a programming community as e.g. "python people" in combination with stating something on their behalf.
You are absolutely right to correct me, I re-read my comment, and it does look hypocritical, which wasn't my intent. Paradoxically, in the spotlight of what you've said, it looks a bit like "bees against the honey" movement. After all, I myself one of those "Python people." My lame excuse is that English is not my first, second, or even third language. Choosing proper words and nicely phrasing things in it ain't my forte, but I'm trying my best.
One of the most off-putting experiences when starting with Scala is the lack of a dedicated Scala repository such as Clojars for Clojure. Floundering around in Maven Central trying to get an idea of what's available for Scala is an exercise in futility and enough to make you want to give-up before you've even started.
[deleted]
Great. I stand corrected. How long has that been up? Last time I started with Scala it didn't exist.
More than 3 years. I've been using it for that long but it was pretty functional and full even 3 years ago.
Probably about 3 years
It is fun to see python being the beacon of friendly library design :)
Kotlin
Next Step for Scala: Shutdown.
Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Their decision to embrace whitespace sensitivity, while simplifying the syntax for predominant use-cases (again, union types!) betokens flexibility, and a desire to swing for the rafters.
The only thing that saddens me somewhat is that Scala Native does feel like a bit of a second class citizen. The `stackalloc` feels a little sad (coming from C++ -- it should be inverted!). I wonder if it's possible for Typesafe to leverage Scala Native in a manner akin to Python with Numba/Cython. With whitespace indentation - native code inlined and FFI'd automatically - right there with the rest of the nice JVM stuff.
I can't resist citing my email from Feb '07 asking (politely) why we needed a 'new' keyword. Dotty apparently removes the need for that keyword. Should have listened earlier, team Scala ;)
http://www.scala-archive.org/quot-new-quot-keyword-td1989540...