51–60 of 235 posts
Not to brag but I recently ported our legacy java code base written for Java 1.5 to Java 8. The only change we made was to swap the jdbc jar as we also upgraded our Oracle DB.
8 to 11 can be a bit trickier, though. Subsequent upgrades should be boring again, but 8->9 can get interesting.
Have you tried C++, Rust, Java or any other language? They all at some point in the development cycle become a maintenance nightmare. I will let you on a secret, we software developers create problems and then solve those problems. That is how software developer jobs are retained :)
Certain languages prioritize backwards compatibility and maintainability over new features / complicated programming stuff. The maintenance burden is dramatically different for different languages in my experience.
> Scala libraries need to be cross compiled with different Scala versions. This seems like a big turn off. Question to any Scala dev's out there. Does this get in the way? And does it make upgrading Scala versions difficult?
In practice though it is not a major issue. It is easy for library authors to cross-compile for different versions and SBT handles fetching to correct binary dependency for your project. And in general, binary incompatibility doesn't mean source incompatibility. So generally uprgrading your projects scala version is as simple as changing the scalaVersion in your build.sbt. The exceptions are:
1. If you have a dependency that hasn't been cross-compiled for the new Scala version yet. So if you are trying to upgrade as soon as a new Scala minor version comes out then you may have issues if you have a lot of dependencies.
2. If you are trying to publish a library compiled for multiple older Scala versions then you can run into source compatibility issues. For instance, if you are using a method/interface that is new as of Scala 2.13 you won't be able to cross-compile to Scala 2.12.
Not to brag but I recently ported our legacy java code base written for Java 1.5 to Java 8. The only change we made was to swap the jdbc jar as we also upgraded our Oracle DB.
Damn dude, nice work. We've going 8 -> 11 right now and it's a pain in the butt.
Have you tried C++, Rust, Java or any other language? They all at some point in the development cycle become a maintenance nightmare. I will let you on a secret, we software developers create problems and then solve those problems. That is how software developer jobs are retained :)
When I read the article I was shocked that 2.11/2.12/2.13 could be breaking changes that prevent existing libraries from working, and so badly that they take years to catch up.
This is so even at a low-level. Look at the beautiful code examples in a Scala book and you might be seduced, but make a small change and there is nothing beautiful about it.
Does rust have this issue? Anyone with experience?
I have more experience writing in Go, and I think the code for all would look similar-ish. Go is a bit of a grey language, but it gets the job done without a lot of refactoring and restructuring.
I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really mi…
>Python projects that are built with Python 3.6 are usable in Python 3.7 projects for example. This has not been my experience in the Machine Learning space.
for most simple HTTP webservers, python maintains somewhat OK-ish source/binary compatibility between python-versions. But my experience with scala was things breaking between scala-versions / waiting for some library to compile with next scala-version... I'm surprised why scala couldn't solve it better than python -- I mean, scala's a compiled language, so it should have more wriggle-room...
Scala developers aren’t willing to freeze that mapping, partly because they found out better ways to do such mappings, and partly because they keep changing the language, changing what was the best way to do that mapping.
I think it’s easier for interpreted languages to keep their internals compatible. They are willing to give up some speed for convenience, so even if they think “I wish we had done that differently”, the pressure to change it isn’t that high.
They also keep more metadata around. In some cases, that enables them to discover “this is using the old way to do Foo”, and fix that up to use the new way.