Personally, I think just a small tweak like this will improve the readability quite a lot.
I admire this aspiration, but currently my experience is more code is likely to break as I advance between Scala versions; and even between patch releases. I’m sure that for beginners the likelihood of running into the kind of bugs I’m running into is unlikely, but still almost every time I upgrade I get more surprises, not less.
We should download the latest version of the presentation compiler for that purpose , but I’ve seen multiple issues with that, which I can’t reproduce. I am currently unsure how is this even possible, but I will look into that today.
Hello,
Sorry you keep saying that you follow the Rust model, but I don’t get it, and it seems important for Scala futur, so I would like to get it.
AFAIK, Rust:
The Scala model for 3.x felt much more like the current Java model to me:
That understanding is derived from the nomenclature used, and the ecosystem custom where Scala lives. I mean, I try to follow quite in details what is done where in Scala-land, and I didn’t understood that LTS were NOT the standard entry point, but more like “you shouldn’t use that appart if [very restricted use cases]” before that thread, and I was happy @jducoeur / @davesmith00000 brought the subject here.
And so… Now I start to understand that mental is incorrect, or at least not the one Scala pursues nowadays. But I’m not sure either I understand the Rust comparison. Does it means that now, scala will have channels with time based release every few weeks ? And LTS are more alike rust “langage edition” ?
Does it means that now, scala will have channels with time based release every few weeks ?
Scala 3 has tried to follow ~6 weeks release cycle from the very beginning, however sometimes due to found regressions and problems with resolving them these could have been delayed. Now, after setting up LTS, improving the process and having project manager keeping us on schedule, we want to come back frequent, timely releases. See the latest roadmap
I think it might be more accurate as, “That’s a well understood issue within the Scala community”, and download links on the landing page seem like they would be targeting people outside our community who may not understand our tooling situation.
It also might be worth reevaluating what “better” means in the context of these new people. If we want them to have the best experience, pointing them at at LTS might provide that for them, even if it doesn’t have all of the latest and greatest - especially if we collectively come to a consensus that tutorials should be one of those times when targeting the LTS makes sense.
I think the website should only have
Scala 3.3.3 LTS (all versions)
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.