I always have great respect for Scala because itself and the community tried to adopt and push the novel idea in the industry. Take a look at the changes, they're no joke to design and implement. At the same time, they're also trying to make the language consistent and simple. (Yes, I mean simple, not easy or single-paradigmed)
They are taking the hard way, and not only there are not enough people to appreciate the effort, but also attract some hatred from time to time. I hope Scala 3 would bring us and itself a bright future, and inspire more languages to move forward.
(For example, there are a lot of type features added to TypeScript in most releases because it needs to do the typing on existing dynamically typed languages, it may also be a hint that dependent type actually makes sense in mainstream languages).
In the earlier versions of TypeScript, I often stuck with something natural in JavaScript but cannot express the same thing with type annotations - It's like opening a pandora box, once some advanced type operators have been introduced, whenever I played with them I would quickly found more type operators to be desired.
And so it did. Things were getting better over years, there were a lot more type operators, mapped types, the infer keyword, etc. I feel it points to a direction: There is still a lot of existing JavaScript functions' type depend on the input which cannot be well-typed. For example, there are functions similar printf in most languages, or return type T when 0 is passed otherwise return type U. To satisfy those cases, we'll basically reinvent a whole new programming language in the type system - if the new language happens to be JavaScript itself it would be similar to other dependent type systems.
This issue thread on the TS repo may be of interest:
In the end, I think they did an awesome job. Many, many sacred cows of old Scala were confronted. I think the result is a much more approachable language, where simple things are easier.
"Scala 3 takes a slightly different approach [from Scala 2] and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent"
So rather than something like implicits, that can be used N different ways, only 2 of which are practical, Scala 3 adds those 2 features explicitly.
One of my first impressions of Scala, which I have barely seen, and do not know, is that there is a lot of syntax. Has anything been done to help with that? I don't think syntax matters much, but it's one of the only impressions I have of the language and wanted to ask about it.
See slide 13: https://www.slideshare.net/Odersky/preparing-for-scala-3#13
With scala 3, syntax has been simplified even more, e.g.:
No more braces necessary. Top level declarations. Extension Methods.
I guess my perception is warped :-)
I'm especially excited about union/intersection types. I think we could all witness how well they work out in typescript and I believe that every language with the concept of subtyping should have this feature. It is one of the things that make working in a statically typed language feel much more dynamic/lightweight without giving up on safety guarantees.
Scala 3 is my on shared 1st place favorite language
Union/intersection types — indeed, I use all the time, in Typescript.
And Opaque Types looks lovely too. All across my code base, I have type aliases like "UserId" or "PageId" or "PostNr" or "DraftNr" etc, and it'll be nice that this can now be type safe for real, not just type aliases. (Just waiting for opaque types to arrive to Typescript too.)
> After 8 years of work, 28,000 commits, 7,400 pull requests, 4,100 closed issues – Scala 3 is finally out. Since the first commit on December 6th 2012...
I mean it is lot of work for sure. But is it such a fast pace?
However, the language resembled Scala, was created by the same person, had some cool capabilities that a lot of Scala users longed for, and it was a chance to "start over" with some of the more questionable design decisions that had been made previously, so there was a lot of questions and pressure to make it Scala 3.
So it was decided to no longer treat Dotty as a second language, but rather to find a path to migrate the existing Scala ecosystem to this new language. This transitioned the project from a relatively slow-paced research language into a full fledged and funded project with an urge for engineering not just tool and ecosystem compatibility, but also bytecode compatibility with Scala.
So for most of those 8 years, there was no objective but to create a better language than Scala. Then very rapidly (maybe the last two years), it went from "this is a completely new language" to "these language ideas will be incorporated into Scala 3", to "this will actually become Scala 3 and we're working on a transition path".
And from the perspective of someone who was aware of Dotty and a regular user of Scala, that felt like an extremely fast transition. Especially for a language that took years to make much smaller changes in the past (2.10->2.11->2.12 felt like an eternity).
Scala does not use semver. The last major release was 2.13.0, not 2.0.0. That's a bit confusing I guess.
What that means is, they haven't just added some features, they redesigned/rewrote to language from ground up to simplify it and make formally sound. I actually don't know any other language that does that (though I'm sure there are others, maybe Haskell is one of them).
In addition, a lot of features are very impactful and unprecedented, such as match types. To me, for a mainstream language (even though a smaller one), it certainly feels fast pasted.
* Powerful functional features
* Powerful OO features
* Imperative features
* Powerful type system
* Great stdlib
* Great syntax
* Very fast write/test cycle with worksheets, way better than a REPL
* Great IDE features such as autocomplete
Scala may not be the best on any one axis, but the combination is unparalleled.
What would be advantage of using VS Code over IntelliJ for Scala?
Follow-up: How do you transition to productionizing your code after iterating in them?
I tend to not view it as a replacement for an ordinary code file, but as a replacement for a REPL session. It has several advantages:
* Keeping track of your previous commands in a file is much more convenient than keeping track of it in your input history of the REPL.
* You can keep re-editing previous lines easily, and you can see the output of all lines.
* There is no hidden state (unlike a REPL). Everything is run from scratch every time.
* It's easier to define helper functions than in a REPL.
* It's easier to turn a worksheet into a unit test than it is to turn a REPL session into a unit test.
That said, it's also possible to start writing a module in a worksheet, and then turn it into an ordinary code file later.
Worksheets aren't perfect yet; I can think of many improvements, but they're already very useful to me. I think the end game will be to merge the concept of worksheet, unit test, debugger, printf debugging, and ordinary code file into one system, like Sean McDirmid's usable live programming research work (which in my opinion remains one of the most underrated research projects).
Feels ironic, since Scala has a very advanced type system that would prevent such bugs, but the page contains the most classic issue of not handling non-ascii characters properly :)
Kotlin is great and if you want a cleaner Java experience, by all means use it but Scala is real champion in pushing many, many things into the mainstream.
I guess it only has decent marketshare because of google's android support(they are throwing stuff on the wall to move away from Oracle IP i guess) and Jetbrains being very popular among java devs.
What did the trick are the other programming languages that can stand on their own as platforms.
I like to refer to it as Haskell with an extra chromosome: slow, hard to comprehend, and incredibly strong.
I'm lucky enough to write it in my day job and I feel like I'm living life on easy mode because of it. It'd take a lot of money to lure me back to garbage like Python/JS at this point.
that's a weird and offensive thing to say
That's why some call it Haskellator. :)
This also means that many codebases have different styles though, whereas in Haskell you have one style (FP).
I think they've pulled off an unlikely and amazing feat with this release.
What will tangibly be broken with 3.0, and is there any migration tooling?
— Nevermind, https://scalacenter.github.io/scala-3-migration-guide/ seems to cover this quite respectably.
Luckily Scala has one of the strongest statical type-systems, which will make migrating much smoother (not completely painless though)
Scala 2.x already had path-dependent types, which combined with implicits and type inference were technically sufficient to implement versions of of the dependent function types we have now in 3.x. In my opinion, how you did this previously could get really clunky (See e.g. hlist mapping in https://github.com/milessabin/shapeless/blob/8933ddb7af63b8b...). Lots of things that frankly felt like casting magic spells, and there were sometimes fragile and weird bugs especially with how implicits were resolved, see e.g. https://github.com/scala/scala/pull/6139.
The native type-level meta-programming coming in 3.x along with a lot of streamlining of the underlying type system and implicit resolution rules (e.g. https://github.com/lampepfl/dotty/pull/5925) could help a lot. This is just one example of a more advanced feature, but there are lots of things like this that changed in Dotty (maybe the most interesting is the DOT calculus that makes a better backbone for the type system). I don't know what tooling for Scala 3.x looks like, but even Intellij's frankly amazing Scala plugin broke down sometimes for 2.x.
After using TypeScript, I just personally enjoyed the experience better. Technically Typescript's type system is equally as powerful as Scala's, but the primitives for expressing more complicated types just seem much easier compared to the path-dependent stuff you would need to do in Scala. I was amazed to find stuff like this https://github.com/aws-amplify/amplify-js/blob/dedd5641dfcfc... in mainstream wide usage. I'm not even sure how you could write these type of transformations as well in any version of Scala. I suppose maybe records work, or in this specific case there are functional patterns that are preferred.
Caveat, I haven't followed Dotty for a couple years now, so I could be missing a lot. Regardless, I have really enjoyed the tooling around Typescript as well as the design. The real-world usage of more complicated dependent types (and there are good uses IMO) have been more fluent and easier to understand, and less dependent on tricky behavior like for implicits. VS Code's tools are really magical, and I hope with some of the amazing underlying work done in Dotty the Scala developer experience could look more like that.
In general, Scala focusses a bit more on theoretical foundation and sound features (which makes progress slower), whereas TS focusses more on practicality. That's pretty exciting because it also means that TS leads to more "experimentation" and if something works out well (and can be proven to scale into the future and interops well with other features) then it can be added to Scala in a more general/abstract way - which also makes it easier for other languages (like Java) to pick it up.
val scala: "Scala" = "Scala"
const typescript: "Typescript" = "Typescript"
"Scala" | "Typescript"
In the example above, the created type "Scala" is distinct from a type Scala, correct?
I did some quick poking around for Scala literal types, but I found stuff like https://github.com/jeremyrsmith/literal-types , which don't look like the example above.
Syntax is all there so maybe it'll get better in 3.1+
1. How much better is the performance? (In terms of compilation speed, and runtime)
2. Compatibility with Graal Native?
Someone did some tests on Scalaz codebase and Scala 3 is around 2.5x faster. While Scalaz (and Cats) isn't exactly like your typical Scala production code base, I think we should see noticeable improvement across all kinds of Scala code.
https://dotty.epfl.ch/docs/reference/other-new-features/inde...
RIP Code samples.
Many of the other features are nice adjustments.
* Community switching from SBT to Mill
* Community agreeing on automated code formatting and everyone using the same scalafmt settings. After using automated code formatting tools like black for Python and gofmt, programmers really don't want to talk about whitespace formatting on every PR. Scala has a lot of syntax, so this is more important than you might imagine. They need to change from this detailed style guide (https://docs.scala-lang.org/style/) to "use these scalafmt settings and don't talk about code formatting anymore"
* Make it clear what libraries are recommended for certain tasks. If you search for "scala json libraries" you'll arrive at these 16 options: https://stackoverflow.com/a/14442630. Devs don't want to do an extensive research project to figure out what JSON lib to use.
* Shift from Scalatest to utest / munit for the reasons outlined here: https://github.com/com-lihaoyi/utest#why-utest
* Fill in "obvious library gaps" with good solutions. Scala needs a graph library that's usable like networkx for example. Li's libs are so popular cause he exposes beautiful Python-like interfaces (with crazy, performant Scala implementations under the hood).
* Embracing devs that want to use Scala as a "better Python" rather than giving them the message "if you use Scala, you need to do it the Scala-way". Scala is a multi-paradigm language and using the language in different ways should be encouraged.
* Getting the community to use the Principle of Least power is perhaps the hardest: https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL.... I find the doc to be cut-and-dry, but have found it less useful than I originally thought for resolving technical disputes.
The hard work has been done to build Mill, utest/munit, scalafmt, metals, etc. Scala just needs to make some opinionated choices so the ecosystem is appealing to ppl that aren't as into programming.
It'll be interesting to see if Spark is able to upgrade to Scala 3 or if they get stuck on Scala 2.13.
This hurts so much. The nerd in me wants to gush over the improvements in Scala 3, but that pleasure has been ruined by observing in my own coworkers that the people who are the most excited about Scala are terribly self-indulgent in their work. I know when my coworker says he's excited about @inline that our first Scala 3 service (which I'm guessing he will roll out next month) will have more than one use of @inline, for no other reason than his desire to learn it. I am a huge fan of Scala, but I am developing a knee-jerk Grinchiness about any kind of excitement about it.
I hate the way my feelings have changed, but still, I think we have to wrestle with the fact that in many if not most software organizations, the Scala advocates are people who enjoy having fun with technology and leveling up their skills and who cultivate an intentionally and stubbornly unexamined assumption that continually adding new programming powers to their skillset is the best way to serve the needs of the business and the needs of their coworkers.
If I could wish for one impossible thing for Scala, it would be widespread top-down forced adoption, so that lots of people who aren't particularly enthusiastic about Scala are forced to use it. I think people who are less enthusiastic about Scala write better code in Scala. I think they could improve Scala (and Scala could improve their programming as well.) What I'm seeing now in practice is Scala being avoided by those people who have the skepticism and discipline to use it well, and embraced by people whose engineering decisions are determined by their feelings of curiosity and boredom.
I think no community has this problem solved, and I also think it is unsolvable unfortunately. The need to experiment seems to be human nature, and we are still really terrible at designing for code reuse, so small, subtle feature differences often require a totally different interface / library.
I don't disagree with the desire to solve this problem, I just think it's completely unrealistic and not rooted in reality. It reminds me of when people say "we should make this simpler."
Yes, that's a great goal, and one that is easy to say but not easy to achieve.
I'd appreciate if anyone has any advices of one vs the other.
The big ones are mostly there, but there are lots of smaller ones that are not and there will be teething problems, even after a long alpha-beta-rc train. Scala 2.13 is still great.
I think scala 3 is ready to go for production use, but it did come out yesterday. So waiting a tick would be prudent.
It can also target JavaScript if you need to deploy something on browsers.
I wouldn't call Scala3 quite "start-a-project-with-it" ready because the ecosystem will need a couple of months at least to update, but Scala 2.13 should suit your needs more than fine.
Scala 2 is a very flexible language and a lot of outsider complaints seem grounded in this flexibility.
Scala 3 is more opinionated in some ways:
"Opinionated: Contextual Abstractions
One underlying core concept of Scala was (and still is to some degree) to provide users with a small set of powerful features that can be combined to great (and sometimes even unforeseen) expressivity. For example, the feature of implicits has been used to model contextual abstraction, to express type-level computation, model type-classes, perform implicit coercions, encode extension methods, and many more. Learning from these use cases, Scala 3 takes a slightly different approach and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent
"
I think it is a very practical and grounded focus change.
[1]: https://dotty.epfl.ch/docs/reference/contextual/motivation.h...
[2]: https://dotty.epfl.ch/docs/reference/dropped-features/macros...
The biggest change touching your comment is replacing one feature (implicits) with a couple more tailored features (extension methods, conversions and context parameters). In practice they were very powerful and versatile, but also complicated, finicky and bug-prone. Feels a bit like pointers in that regard.
Fortunately, Scala is one of the best (statically typed) languages in that regard that I ever used.
- If you're at least a little familiar with Java, Scala for the Impatient is pretty good, though a little dated (I think the last edition covers Scala 2.12).
- Daniel Westheide's blog: https://danielwestheide.com/books/the-neophytes-guide-to-sca...
- https://www.scala-exercises.org (at least the part on the standard library).
- https://www.handsonscala.com
Note: Scala 3 introduces quite a bit of new syntax that is specifically designed to make intimidating features less so. But at the beginner/intermediate level it won't matter too much, for instance if you learn how to implement typeclasses the old way, you'll easily understand the new syntax. Also the Scala Center has committed to providing a lot of training material along with the Scala 3 release.
I would start by playing about with the syntax and writing standard OOP code, as its probably what you're most familiar with.
When you want to dive into the power of FP then I recommend http://eed3si9n.com/herding-cats/. Its basically a companion to the Haskell book 'Learn you a haskell' (http://learnyouahaskell.com/) that takes the theory coming up in that book and translates it to Scala. I found it the most direct explanation of the different types and theories (Monads, Functors, Applicative, etc).
If you start with Haskell, you are forced to do pure functional programming. That is much more intimidating and less productive, but also better if you want to force yourself to learn it.
There's also an ongoing video series called "Let's talk about Scala 3" by the Scala Center and 47 Degrees [2], which are more in-depth on certain topics, but still quite beginner-friendly. Especially the video on setting up a development environment, and the video on Scala 3's data structures might be good introductions.
[1]: https://docs.scala-lang.org/scala3/book/introduction.html [2]: https://www.youtube.com/watch?v=j-H6LSv2z_8&list=PLTx-VKTe8y...
JavaScript Developers https://docs.scala-lang.org/scala3/book/scala-for-javascript...
Python Developers https://docs.scala-lang.org/scala3/book/scala-for-python-dev...
Java Developers https://docs.scala-lang.org/scala3/book/scala-for-java-devs....
for a quick introduction
https://docs.julialang.org/en/v1/manual/functions/#man-anony...
A function is of type ‘Function’. There is no way to define it with the type of its argument or the type of what it returns.
N-dimensional arrays in Scala 3. Think NumPy ndarray, but with compile-time type-checking/inference over shapes, ndarray/axis labels & numeric data types.
Can we take a step back now, and reflect on what was the original problem implicits were designed to solve and how it is solved now in Scala 3? I've heard the original problem was that they wanted a chain of functional transformations to return the same type of collection (unlike, say, Clojure or Java 9 which return a Stream).
It then turned out that they could be used to simulate extension methods, which is probably the main use case for implicit classes in Scala2.
And implicit parameters were probably just the result of trying to make type classes modular.
The CanBuildFrom approach came later than implicit parameters (https://stackoverflow.com/questions/1722726/is-the-scala-2-8...).
The desire to return the same type of collection lead to overall slow performance; it turned out it's a design dead-end that Scala is still suffering from.
It should simply have been abolished and replaced, instead of applying some minimal fixes in 2.13 that preserved the wrong design choices.
However, with the existing alternatives nowdays, Scala doesn't hold the same position. I have not coded in Scala for ~2 years and I'm not sure I'll ever need to.
Anyway, all the best for Scala's awesome team and its ecosystem.
On the one hand, Scala is such a seductive language - there is literally nobody it doesn't cater to. Whether you're into FP, OO, data science, enterprise business logic, strict conservative style explicit semantics vs going wild with implicits and DSLs etc, and now whether you like significant whitespace or not ...
But on the other hand its the same story as always - all this crazy optionality of features mean its got such a huge surface area for people to understand. Its a language where I get what I feel is functionally competent and then dive into a codebase in github and I can barely even recognise the syntax, let alone feel confident to make a change.
[0] https://dotty.epfl.ch/docs/reference/other-new-features/inde...
Maybe I'll write a blog-post about it, but as I practice leet-codes in scala, I miss relatively basic things like c-style for loop (so I can use a for loop on linked lists rather than a while), or things like a list that can have more than Int.MaxValue numbers.
def extractKey(e: Entry): e.Key = e.key
and:
def extractKey(e: Entry): Entry.Key = e.key // the way I'd normally think of it
So, with:
def process(p: Path, key: p.Key): Something = ???
this will not compile:
val p1: Path = ???
val p2: Path = ???
process(p1, p2.key) <- compile-time-error
I've been using a lot of Swift lately, and they have a generic type roadmap that talks about "existential types" and being able to "open" an existential. This looks very similar.
It was my main language for 5 years, and there was always a variety of Scala jobs in Berlin: companies of different industries, sizes. Recently, I mainly used Python at work. I love Scala and wonder if it makes sense to invest in keeping up my Scala 3 skills.
https://trends.google.com/trends/explore?cat=31&date=today%2...
Kotlin and Groovy both look pretty stable - both having core uses in their domains that I am guessing support continued traction as "the best tool for what they do". Scala I think peaked when it had the overlap b/w business use and data science.
I feel like Kotlin / Scala / Java are all after the same essential core market - a solid, type safe language to shoulder the huge broad need of enterprises to keep business software pumping away reliably. So they are essentially all part of the ebb and flow of the one giant "JVM" ecosystem.
Groovy sits a little outside of that since it specifically targets a different type of problem (providing an optimally integrated JVM scripting language for DSLs and rapid application development).
There are also lots of agencies using Scala, some machine learning and security stuff. Munich is a good place, Berlin, Zurich and Lausanne, if you want to stay in Europe.
I love the language and I'm very happy to get paid to do stuff in it. I don't think I ever learned that much using just one language, Scala is definitively a class of its own.
how far it supports inlining of types and data structures to achieve or get near to zero cost abstraction after normal warm up of the code on JVM ?
But it's there for meta-programming purposes, not micro-optimizations. I don't think trying to outsmart the JVM at inlining is worth it.
http://dotty.epfl.ch/docs/reference/metaprogramming/inline.h...
This effectively makes it possible to have a limited form of partial evaluation.
Ah key commits that you just know you have to bump the version up after receiving.
Or is it more impressive that they have walls of text without saying what scale is?
Also why would they wear an old product like Scala like a skin suit ?
