The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Th…
What's Next for Scala
71–80 of 203 posts
Re: What's Next for Scala
#72I 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 pu…
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 clas…
Re: What's Next for Scala
#73The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Th…
Re: What's Next for Scala
#74Earlier quoted context omitted.
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.
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?
Re: What's Next for Scala
#75Scala has the reputation of being fun to create stuff with, but horrendous when understanding other people’s creations. Is this still true?
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 :)
Re: What's Next for Scala
#76Re: What's Next for Scala
#77That 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.
Re: What's Next for Scala
#78Earlier quoted context omitted.
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, singleto…
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 i…
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.
Re: What's Next for Scala
#79Author 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.
Re: What's Next for Scala
#80Earlier quoted context omitted.
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 g…
> 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.