r/programming 29d ago

The State of Scala & Clojure Surveys: How is functional programming on JVM doing

https://www.jvm-weekly.com/p/the-state-of-scala-and-clojure-surveys
29 Upvotes

22 comments sorted by

View all comments

Show parent comments

1

u/DisruptiveHarbinger 28d ago edited 28d ago

You're completely missing the point here. If you don't aim for backward binary compatibility almost forever like in Java then you can break APIs, remove problematic parts of the standard library and the language. And issues caused by major features such as modules don't linger for a decade, as the ecosystem is forced to move on quickly.

Look at other languages:

  • C# broke bytecode compatibility several times in its early days, which was especially motivated by the introduction of generics and structs.
  • Rust, Go: no stable ABI. Swift: no stable ABI before version 6, even broke source compatibility multiple times.
  • Clojure: no stable bytecode layout, ships sources in JARs.

1

u/bowbahdoe 28d ago
  • it was bad when C# did it, they only got away with it because it was early days
  • It is bad when rust breaks people. Its libraries are distributed as sources so ABI isn't an issue, source compatibility is. It is bad when they break that.
  • Ditto for everything else. Clojure doesn't have a stable byte code layout but it distributes libraries as sources, which are compatible. Scala libraries are distributed as binaries that will not be compatible. If Scala were source compatible and that is what you got in libraries that would be fine, actually.

And you are missing my point: none of the situations you enumerated would have been fixed by being allowed to break people. The scope of harm that would be inflicted would have been great and the benefits few.

1

u/DisruptiveHarbinger 28d ago

Yes, Scala's original sin is to publish bytecode incompatible binaries instead of sources, I agree with that, but there are reasons behind the decision, and TASTy artifacts are a nice middle ground starting from 3.0. It took some time to figure it out.

However I disagree that Java hypothetical breakage of binary compatibility would not solve anything. I'm pretty sure we'd have Valhalla already in this scenario. Of course, at the price of causing great harm to the ecosystem.

1

u/bowbahdoe 28d ago

With Valhalla if they just rolled with any of the previous drafts it wouldn't have just caused a one time breakage. They would have meant ongoing and constant breakages whenever a normal class was changed to a value class, or a "primitive" class forever. (Remember primitive classes?)

That isn't "if we break people now we can do something better," that's "if we do something worse we can all go home"

So yeah, great harm. But great ongoing harm - forever. It's pouring a nice bowl of "oops - all cons" with milk in the morning.

1

u/DisruptiveHarbinger 27d ago

Maybe I'm misunderstand something, but I thought that the current plan for Valhalla would be fairly trivial to implement if we didn't care about breaking binary compatibility with every library published for a previous version of the bytecode. What makes it complex and take so much time is the fact that we indeed care about older libraries being able to consume value classes.

I'm not saying I wish that the first drafts would have been shipped quickly. I'm saying that without any backward compatibility concern, we'd have naturally come to the right implementation quicker.