3 ms·
(6) Design the new version to be compatible with the old version at the module level, allowing the different versions to interface with each other, where indivi
by infogulch 8y ago
(6) Design the new version to be compatible with the old version at the module level, allowing the different versions to interface with each other, where individual modules can be upgraded in isolation without breaking changes to their consumers, e.g. Rust 2018.
- oldmanhorton 8y agoC# and Javascript (mostly thinking of strict mode) fall in this category too
- frutiger 8y agoC/C++ also. It amuses me that GP used Rust as the example for this family. In fact C has an ABI and doesn’t suffer the problem that sibling commenter mentioned.
- coldtea 8y agoC doesn't do much evolution either, must less add generics or introduce new error handling semantics... And C++ just piles up features, supporting everything forever...
- frutiger 8y agoThat’s not really true. C++ makes changes after careful analysis. e.g. the repurposing of the auto keyword (which has been present since the days of K&R C!) I’m not a language lawyer, but one would be able to rattle of a long such list.
- pjmlp 8y agoIt only works if everyone is obliged to build all their dependencies from source code, hence why Swift is having such hard time coming up with an ABI that could survive language evolution.
- testvox 8y agoThis works on dotnet. The dotnet runtime is versioned separately from the language so you can use a library written and compiled with C# 5 in a project that is written in C# 7 so long as they both target a compatible runtime. You can go even further and use a C# 7 library in a F# or VB project.
- pjmlp 8y agoThat is because there isn't C#, F#, VB.NET, C++/CLI or any language that you decide to put on top, just MSIL. With straight native code, the story is a bit different.
- networkimprov 8y agoDifferent Go modules can use different versions of the language, per this proposal.