I don’t think it should have only one, but I think we should orient people.
Something like that.
While this suggestion might sound a bit extreme at first sight, I think it is actually sensible. Does anyone doing any serious development download Scala? I never did - I only update the version in my build file (SBT or Mill). What I think a person starting development should download is an IDE or SBT and then some example or template project.
On this note, the getting started page does not show you that you can get Metals to install a sample project for your from gitter
For example: Metals tab → New Scala project → scala/scala3.g8
(The list would probably benefit from being updated, it feels a bit cluttered at the moment)
This is in my experience is the simplest way to get a project started, you don’t even need to know what sbt is, you can do everything through Metals
(At least everything you need to when starting out)
And to add insult to injury, the with an IDE subsection just tells you to go get Intellij
(There is an explanation for VS Code, but it’s after “You can skip the rest of this page”)
Edit: It felt weird to complain about something I could help fix, so I’ll work on some PRs
Another question is , will a feature in Scala Next be removed in next Scala LTS？
We only use LTS Java and LTS Scala at work
No.
Well, something experimental can of course always be removed.
But for a normal feature, once it’s in it’s in.
In fact “large application” is a myth. For example HHVM depends on nightly Rust in order to use unstable features. HHVM is a large code base.
IMHO, the benifit of using LTS is to avoid migration for a while, but still receiving security updates. I think eventually the migration would be even more difficult.
I would instead recommend by default depending on the latest relase and increamental migration, for both larger and smaller projects.
Thanks! I came here to say exactly the same.
For most projects “LTS” usually just means “left to rot, for people who like big-bang migrations after not carrying for years”.
Additionally: When you start a project just right now even in a “conservative environment” you need to target anyway the next LTS—as your project won’t be ready just the next day usually.
So as a developer of something new you always need to build against the latest and greatest if you want to avoid big-bang migration in the middle of development (or worse, at the end of development, which will maybe even kill your project as time runs out but you need to migrate from the last LTS to the current just to ship v1.0, which is usually a big pain everywhere).
It has reasons why small, incremental improvements are regarded the optimal practice in software development. Something like “LTS” was just invented for the boneheads in management who don’t like to understand that proven fact.
Regarding Rust: Rust has “Editions”, which correlate a little bit with the concept of “LTS”. But it’s not really LTS. Older Editions are incorporated into every Rust release. It’s a kind of “language version switch” you can use in your build definition. It’s there to handle version incompatibilities on the language level (in contrast to binary compat which does not exist in Rust anyway for good reason).
Regarding the installation instructions on the website: Imho it never makes sense to download “a Scala distribution”. I’ve honestly never seen a valid use-case for that. You want Scala-CLI, an IDE plugin, and for more serious stuff the SBT launcher script. For newcomers in exactly this order. (Scala-CLI and SBT usually from package management so it stays always up to date; IDEs have their own package management for plugins built-in).
A newcomer should not need to decide about versions and flavors. Whatever the CLI tool / the IDE plugin uses as default is exactly the right thing to get started. And it’s of course the latest and greatest by default!
The website should have only one big “Get Scala” button, and it should lead to a page explaining how to install Scala-CLI, an IDE plugin, and the SBT launcher script. The first two options presented in some “quick start” manner, and the last as go-to solution to create and run binaries for most real world Scala source projects (use-case: “I’ve checked out this cool Scala project from GitHub, but how do I run it? It says I need SBT. What?”).
PS: The reason why things like Docker got so big was in fact exactly “LTS Enterprise Distributions”: Because such products didn’t get any updates in some cases for even over a decade. Just imagine you would need to build software against such ancient libs and runtimes… Of course this does not work in practice! So people started to deliver packaged apps together with the appropriate runtime in some form of image (btw: “Hello, SmallTalk”), which could than again contain the latest and greatest you need to use to develop modern software. If the proper system packages had been keep up to date in a reasonable manner Docker & Co. wouldn’t be needed in most cases. Also I will never understand why almost nobody sees the irony when people proudly tell you that they run their servers on LTS BS, with “great uptimes measured in years”, while running at the same time all their applications (and that’s where the actual juice is!) on some nightly Docker containers… Proud of their “modern CI/CD development practices” where things get pushed to production dozens of times per day (in the extreme not even upfront tested, because YOLO, “we test in production”).
Maybe it’s just me but I really don’t get the joke hidden here.
PPS: I don’t argue to get rid of LTS in Scala. Some people need that to set a check-mark on some compliance documents, or so. But the question of having a LTS branch is really irrelevant to the getting started experience.
The LTS version should be well documented on the website of course. But for the download option I really don’t see anything other than the big “Get Scala” button described above.
Go-lang got this right. A newcomer does not care about anything other than how to get “Hello World” printed on their screen as quickly and easy as possible. Needing to inform yourself about all the version options upfront is just an unnecessary barrier to entry. (Especially as changing the language version is just setting a CLI option or changing one line in the build file. Something a newcomer will learn quickly later on anyway).
I dunno - that’s a pretty idiosyncratic example. I’m at Slack (the other company that makes use of HHVM) and it’s an unusual, polyglot compiler system that bears little resemblance to the sort of typical business project that AFAIK is the core of the Scala user base…
The latest “stable” version of Scala has not felt particularly stable historically. On several occasions, parts of the language that were not marked as experimental have changed enough that code using these parts stopped compiling.
Match types come to mind as an example. While SIP-56 is undoubtedly a huge improvement, one could argue that match types should have been marked as experimental before that.
Who knows what other parts of the language are secretly experimental? Some of the discussions on this forum almost give me the impression that no part of Scala 3 is safe from being reworked in the future.
The landing webpage should show just one version not 3 versions. This is confusing even for me the long time scala user. I imageine for newcommers is really bad. So this confusion has to be fixed.
I think I want to user LTS as long as possible. And switching to next later when I feel that it is possible and it wont brake anything. All my libraries will depend on LTS so why use something newer.
For ordinary usage LTS is good enough I dont want to have any suprisez with large setups. When next LTS comes out I will switch to that. Its same with JAVA we use just LTS releases.
Scala language is already good enough what you are doing in next versions is not something newcommers to a language should care about. And also learning materials should point to LTS.
By the way scala team promised 100% source code compatibility with LTS, so switching from LTS to newer version should be a breeze. So I dont think it is “left to rot” but its left to mature. and it should not be a “big bang” migration, because We are not talking about 2.x to 3.x migration.
You have to revise why you make LTS in the first place? Now you are saying its left to rot. I smell paradox here.
If you dont want users to use LTS version then just dont link it and dont suggest it. The library creators should be avare of this fact that they should use LTS.
But again for smoother user experience it should target LTS because all the tooling will work with LTS, but it might not with latest. For example IntellJ Idea has this issue it wont work with latest features of Scala. I just hope that they put together Scala 3 LTS compatibility soon. I really dont want to use Metals, I would if it would be integrated into IntellJ. We use metals only for specific use cases like macro code editing.
I understand this promise as 100% source compatibility while the same minor version (3.3 in this case) is being used as LTS. I expect some source incompability (mostly in form of deprecations) between one and next LTS (like 3.3 and 3.6 or whichever will become next LTS). Even now upgrading 3.3 to 3.4 means dealing with some deprecations. It would not be realistic not to expect this from 3.3 to 3.6.
That said, I expect the migration effort to be much lower compared to Scala 2 → Scala 3 and I can imagine prefering doing it in one bigger go than in many smaller steps.
But ideally all serious tooling should have been updated before the public release of a new version. And if that’s not feasible for a specific tool it should warn you to delay updating until it’s caught up, which shouldn’t be very long.
Perhaps a good solution would be to have LTS not be a branch so much as a rolling version tag, perhaps with a less confusing name.
“Edge” would be the most current version that has been released.
“Stable” would be the most current version that has full support in a blessed subset of the tooling (at least Mill, Sbt, Metals, Scalafmt, Intellij, Scalafix, and VSCode), and gets bumped as quickly as the tooling catches up.
This way we can point newcomers and those with lower tolerance for tooling shenanigans at the most recent version that will provide them the experience they need, and still keep them as close to up to date as possible.
It would also provide a way to easily track the current state of tooling support.
That is true, we only use LTS at work. And I think Scala should publish a LTS update release along with a Next Scala, we should publishing the LTS release more regularly.
This was true until April 11, but it is not anymore.
What about creating a milestone of 3.3.4 now? I see no milestone. it’s nearly 8 weeks since 3.3.3 released:)
Could we just annotate the buttons on scala-lang to make it more clear? Something similar to this:
