Scala homepage should make LTS clearer?

[jducoeur]

Bringing this over from a conversation on Mastodon:

The Scala homepage offers you links, right at the top, to download 3.4.0, 3.3.3, or 2.13.13. Nowhere there does it point out that, for most people, what you want is 3.3.3.

Even when you click into them, the only difference is that the 3.3.3 page says “LTS” (in one place, with no explanation) and 3.4.0 doesn’t. Folks, that’s jargon – moreover, it’s inside-baseball jargon that only some software communities use and junior engineers tend not to know. It sort of tacitly assumes that the reader is familiar with Java idiom, which is an assumption we shouldn’t be making. We need to explain it, not assume the viewer knows it.

The reality is that, if you want to dive into Scala for the first time, or start a serious project, 3.3 is probably what you currently want – 3.4 is more for the folks who like having fun out at the edge of language development. We should make that much clearer on the front homepage.

(Yes, I’m pondering what this ought to look like, but I’m also aware that I’m by no means a UX specialist, and my CSS is weak – there are undoubtedly people, hopefully some involved with the Scala Center, with a better sense of this stuff. My guess is that 3.3.3 should be first, and larger, with the other two below it, and hover text or small subtitles with one-liners of why you would want each.)

[soronpo]

Scala-cli defaults to 3.4

[spamegg1]

I was going to suggest the same thing. @jducoeur

[jducoeur]

@soronpo

Scala-cli defaults to 3.4

Interesting point. That’s a separate conversation, but I’d probably say the same thing applies: if we’re serious about having an LTS, that should probably generally be the default that we are presenting – the current latest-and-greatest should probably be more opt-in.

[davesmith00000]

I also feel the LTS version should be more prominent, or at least that the bleeding edge version should be well sign posted.

This also leaks into The Great Tooling Debate, unfortunately. (Sorry…)

Personally, I like living on the bleeding edge and I’m totally ok with the tooling being a bit rough n’ ready out on the fringes of civilisation. I’m not a huge fan of the idea of tying the language’s development to the speed of the tooling development, because:

1. …I think Scala needs to keep up with the changing programming language landscape.
2. …I like where its going, I really do!
3. …and that the people shouting for “stable and well supported tool chains” will end up stifling the language’s development into irrelevance.

We just don’t have a big enough user base (or, frankly, a big enough language development team) to be able to afford to evolve in the slow and stable manner that Java does.

On the other hand, the tooling story must improve, or we’ll lose existing users and no new comers will replace them when their first experience of Scala is “well, my IDE didn’t really work …but then I tried Kotlin and it was fine so I just stayed there. I guess they’re kinda the same anyway, right?”

There is a way forward though, to @jducoeur’s point:

Sign post the non-LTS versions clearly, saying “Here be dragons, not for the faint hearted, or for people who like working IDEs.” Thus, non-LTS versions can run as fast and as far as our fearless leaders and language designers dare, and the largely silent tooling-tolerant segment of our community, who like trying new features and don’t mind dodgy editors, will carry on as normal.

The LTS versions, on the other hand, are loudly promoted as “the one to use”. They are the default, and tooling efforts go into making them excellent experiences as a priority over supporting the shiny new non-LTS features.

Just my ten cents. I realise tooling has been debated ad-nauseam and I haven’t honestly followed it that closely. Perhaps some of this is already being done.

[odersky]

We follow the Rust model where the last version has the most bug fixes and is generally better than previous versions. This will be very apparent in another 6 months or so. So if you have a regular application or just want to try Scala, it’s recommended that you use the latest version. There are two scenarios where you want to use LTS:

• You publish a library that others rely on.
• You have a large application that does not change much and want to avoid risk.

[davesmith00000]

Thank you for the context, good to know. That being the case, the current version positioning / promotion does make sense, as does Scala-CLI defaulting to 3.4.x.

I don’t want to turn this into a tooling discussion. As previously stated, I don’t actually feel as passionately about this as others. The only skin I have in this game is that - selfishly! - I end up working at companies that won’t move to Scala 3 because of the tooling, so I’m stuck using Scala 2 professionally, and I much prefer Scala 3!

That said, it seems to me that following this approach would make it quite difficult for the tooling folks to keep up without holding back language releases until the tooling is ready, no?

But you mentioned that this is how Rust works, so I have to wonder how the Rust folks are managing all this. Does anyone know? Is it just easier for them for some technical reason? Do they just have more engineering capacity? I guess what I’m really asking is: Are we competing on a sufficiently level playing field that copying Rust’s approach makes sense for Scala?

[spamegg1]

@davesmith00000

But you mentioned that this is how Rust works, so I have to wonder how the Rust folks are managing all this. Does anyone know?

They have a lot more resources compared to Scala.

[OndrejSpanel]

@odersky

We follow the Rust model where the last version has the most bug fixes and is generally better than previous versions.

This seems quite different position than the one expressed in Scala 3 porting experiences - #2 by tgodzik - Question - Scala Users :

This is what we try to do in in Scala LTS (3.3.x). I wouldn’t recommend moving to 3.4.x or even further in the future just yet if there is no particular need for it. We port all the nice improvements and bugfixes to the 3.3.x branch, so that people can stay on it and not be left behind. We also improve the overall tooling with LTS especially in mind

[tgodzik]

I think this is a bit more complex than what I wrote, so probably someone from the compiler team or Martin explain it better.

Overall, from what I see recently, both versions are stable and tested with exception that LTS will be better if someone depends on your code.

[odersky]

@OndrejSpanel

This is what we try to do in in Scala LTS (3.3.x). I wouldn’t recommend moving to 3.4.x or even further in the future just yet if there is no particular need for it. We port all the nice improvements and bugfixes to the 3.3.x branch, so that people can stay on it and not be left behind. We also improve the overall tooling with LTS especially in mind

I think this might have been an aspiration, but it did not fully work out that way. The problem is that most improvements to (say) type inference, or match types, or sometimes even better error messages have the potential to break something that relied on the old behavior, even if that occurs only in extremely special circumstances. So in the interest of stability some of these fixes are not backported to LTS. The overriding concern for LTS is to play it safe. The overriding concern for Next is to improve the language and tooling. The two are sometimes in conflict.

[jducoeur]

@odersky

The overriding concern for LTS is to play it safe. The overriding concern for Next is to improve the language and tooling. The two are sometimes in conflict.

Right, but that’s getting back to my point – most people want LTS versions. Scala learners generally want something stable, proven, and if possible well-documented, not necessarily the newest-and-fanciest. Enterprise projects (who I suspect comprise most of our actual day-to-day users) generally prefer LTS versions of things, upgrading less often and sticking to the “safe” path.

I’m not saying that Next is bad – I’m saying that LTS is a thing for a reason, and it’s probably the correct answer for most folks other than us Scala geeks. We’re a little weird right now in not having that version front-and-center. IMO, we should fix that. And we absolutely must make the distinction clearer on the homepage.

[odersky]

I believe you might have a misconception what next is. It is the best version we can make, not a playfield of experiments. Everything we do in improvements goes into next.

I’m not saying that Next is bad – I’m saying that LTS is a thing for a reason, and it’s probably the correct answer for most folks other than us Scala geeks.

Not necessarily. As I said our release process is modeled after Rust, and there most people are always on the latest version. I would recommend learners and courses should pick Next, since it is the version with the fewest bugs.

[hepin1989]

Seems like we can build applications with Next but libraries with LTS.

[bishabosha]

Everyone, you have to understand that 3.4 is stable, it’s not a nightly, it’s the stable version. LTS exists as a target for library authors, or otherwise those wanting guaranteed source compatibility for years

[davesmith00000]

Hi! I think there may be some confusion.

Speaking for myself, I am super confident that the compiler itself will work really well, and will be stable on release day. I expect I’m not alone in this view. I have never heard of nor witnessed a bad release, or at least, one that the team hasn’t immediately communicated about and resolved. You all do excellent work here in my humble opinion.

Where people lack confidence, based on experience, is that the editor tooling will support the non-LTS versions on release day.

All we’re saying is that: It is in fact perfectly ok if the tooling isn’t quite ready for the latest version… but maybe that needs to be communicated more clearly somehow to avoid people having a bad experience with this language we all care about so much.

Hope that helps.

[WojciechMazur]

Where people lack confidence, based on experience, is that the editor tooling will support the non-LTS versions on release day.

That’s a well understood issue. That’s why before release of any new version of compiler, either stable or release-candidate we follow a procedure that ensures the the core tooling projects (Metals, scala-cli, debug-adapter etc.) are ready, see 3.4.1-RC2 Release procedure · Issue #19932 · scala/scala3 · GitHub

I personally believe we might even try to extend the procedure, by involving more community projects, eg. by setting up a CI flow where new release of compiler triggers CI/release of compiler plugins, eg. wartremover, better-tostring, etc. This technique is used for ScalaNative snapshots and ScalaNativeCLI used by scala-cli scala-native/.github/workflows/publish.yml at efabf74de738310edde0447e5ff5cc21f52bbd4a · scala-native/scala-native · GitHub

[davesmith00000]

It occurred to me after posting that talk of LTS / non-LTS may be misleading. It’s really just which version is best supported by the tooling, and on this occasion, the perception is that the LTS version will be, i.e. 3.3.3.

[davesmith00000]

That’s really great, thanks for sharing!

Given all this started due to a Metals message saying 3.4.0 was unsupported, does that mean that Metals testing is against the nightly version or the officially released version, do you know?

[JD557]

On the topic of the homepage, here’s the comparison with the CTA on other language home pages

Number of versions: All sites (other than Scala) seem to only have a single prominent version

Teminology: No standard… Node.js mentions the version + “LTS”, Rust just mentions the version and Go doesn’t even mention that.

Recommended versions:

• Node strongly recommends the LTS
• AFAICT, Rust doesn’t even seem to give instructions on how to download anything other than stable
• Go just recommends the latest version

Scala:

Node.js:

Rust:

Go: