@alexandru While I understand your general frustration, I think that you’re oversimplifying the problem at hand. Decisions on this topic are not simple, they have both advantages and disadvantages. This discussion is contentious in a lot of other programming language communities. You’ve cited the most common programming languages that do have a notion of binary compatibility built-in into the language. But there are many others that don’t – and compromise similarly to how Scala does.
I disagree with this idea of “semantic versioning being a recipe for breakage”. Semantic versioning is necessary to have a “semi-formal” way of reasoning about software changes and its implications to their ecosystem. It’s a concept useful on its own – it lacks precision, but it’s better than nothing.
I believe that the whole Scala community should use a refinement of semantic versioning adapted to Scala – where source and binary compatibility are taken into account. But that’s another topic.
I agree this is a good idea in general. There are, however, certain scenarios in which this is not possible – the standard library is one of them. The standard library is part of the language. Using different namespaces would create a ridiculous overhead for those interfacing with libraries whose interfaces use previous versions of the collections library, for example.
As you probably know, the Scala standard library will be overhauled by the Scala Core + Scala Platform combo, allowing libraries to evolve much, much faster in the Scala Platform, where most of the utils will be maintained. So I see this move as a nice, future improvement.
There are indeed benefits. Scala doesn’t break bincompat just because the Scala team is keen on giving users new features. Oftentimes, bincompat is broken because the encoding of certain features changes, either for better performance or correctness. Evolving a language means polishing the rough edges, too. I would not be happy coping with decisions that were made several years ago and were afterwards deemed bad ideas and changed. Under your proposal, I would need to cope with them.
I don’t believe this is mission impossible. Take the 2.11.x-2.12.x migration. From my OSS point of view, it hasn’t been so painful – I agree this may not be the case for certain industrial software. There are indeed libraries that have slowed the process down, some of them for lack of economic incentive, some others because of technical problems (Spark).
Languages like Java (and JS) have a substantial advantage over Scala because they control the runtime – they can afford themselves to implement lambdas in a bincompat way in both the VM and the language. Clojure is an interesting exception and won’t comment on it since my understanding is limited. However, I venture to say that Clojure is much simpler than Scala (it needs less syntactic sugar and encodings, which makes it significantly easier to keep bincompat across major versions).
If you want to move this discussion forward and my arguments don’t convince you, I believe it’s better to discuss concrete, technical details on how you would evolve the language without breaking binary compatibity and what implications that would have for language designers, library authors and users.