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 -
Replying to @djspiewak @jvican and
Fury deliberately takes an approach to try to mitigate this problem, though: No build definition gets silently upgraded to a different version of the source from what it was published with. Of course, that creates a new problem of more conflicts to resolve...
1 reply 0 retweets 2 likes
...which it attempts to minimize using multi-tiered layers for publishing coherent collections of projects with dependencies resolved. It shares the problem of conflict-resolution across the whole community, and hopefully reduces duplication of effort.
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.