Random nugget of insight from @sjrdoeraene found while perusing unrelated threads: Source compatibility is broken in Scala when you *add a public method to a type*. Even ignoring diamonds, this alone is murder on source dependency schemes in this language.
-
-
This Tweet is unavailable.
-
Replying to @ashton @sjrdoeraene
For some aspects of Scala, that is 100% true. The ecosystem is structured though such that most users never see those problems. The burdens are generally borne by library and tool maintainers.
1 reply 0 retweets 1 like -
This Tweet is unavailable.
-
Replying to @ashton @sjrdoeraene
That's a completely fair conclusion, tbh. :-)
1 reply 0 retweets 2 likes -
I want to believe I maintain or have maintained some popular tools and Scala libraries... I've never been bitten by this problem. These quirks sound terrible in theory. In reality, they almost never happen and they don't even matter because most people don't promise src compat
3 replies 0 retweets 4 likes -
Ah but if the entire ecosystem were to move to something like Fury or similar, then suddenly source compatibility becomes more important than binary compatibility.
3 replies 0 retweets 2 likes -
And this is precisely why I am the greatest detractor of Fury. But in some way I wish Fury all the technical success it can get, so that people can actually try it and see for themselves that an ecosystem based on source compat is not viable for Scala.
5 replies 0 retweets 6 likes
Though I still think you're envisioning that being an ecosystem where the sources can change behind your back and you end up with some unexpected maintenance. I'm not naïvely assuming that that would be practical.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.