3 ms·
That is different than the fragile bytecode problem scala appears to have though. Go's issue is that the API's are changing fast so source code has to be modifi
by zaphar 15y ago
That is different than the fragile bytecode problem scala appears to have though. Go's issue is that the API's are changing fast so source code has to be modified frequently.
Scala's issue seems to be that even when the API's haven't changed and there is no need for a sourcecode change a compiler change could break you.
Frankly go's problem seems more manageable.
- luriel 15y agoThat Go does static linking also helps. And in Go-land source code is pretty much the only way things are distributed because it is so fast to build. For example in Go on AppEngine you upload the source for your app, and it is built on Google's servers. In a way Go's source is its 'bytecode' :)
- nknight 15y agoActually, it sounds like Scala's would be more manageable, if it were handled properly. In fact, you can find a kind of precedent for Scala's problem in C++, which was wildly successful in spite of itself and its many implementation problems that included routine ABI breakage. I can live with having to rebuild my stack for a compiler upgrade, if the ecosystem is setup such that rebuilding the stack is a natural and easy thing to do. The problem seems to be that Scala's ecosystem doesn't work like that. Go, on the other hand, is, in its current stage of development, requiring frequent source-level changes. I consider that much hairier, as it risks altering the actual meaning of the program even without possible compiler bugs (which Go, like every other language, can still have, I don't know why you seem to think Scala's situation there is special). Given their apparent state, I would accept neither Scala nor Go as production ready in a general sense. That said, Go gets points for not pretending to be such.