back in my day we only had one language. it was called ASSEMBLY. wanted to make the computer do something? you had to ask it yourself. and that worked JUST FINE
Back in my dsy we only had non programmable computers. Wanted to make the computer do something? You had to specifically build in the function. And that worked JUST FINE
My favourite is "all the boilerplate" then they come up with go's error checking where you repeat the same three lines after every function call so that 60% of your code is the same lines orlf error checking over and over
When you handle all your errs the same way, I'd say you're doing something wrong. You can build some pretty strong err trace wrapping errs.
I also think it's more readable than the average try catch block.
How are they ignorant? It’s a known fact that java is slow, at least slower than some others. Sure, it’s still fast enough for 95% of use cases, but most code will run faster if written in, say, C. Will have 10x the amount of code and twice as many bugs though.
You're not wrong, it's still a staple today, but it lost a lot of its shine a while ago. They are mimicking "new" features introduced in other languages, but make a point to preserve retrocompatibility.
I can't imagine how convoluted the JVM has become in the last 10 years.
That one dude still using Delphi is getting screwed.
Also, these salary numbers seem... real low. I get that it's the median so maybe a huge number of overseas engineers are pulling the results down but in my neck of the woods 105K is less than what we pay juniors.
One project I worked on had 10 different languages. That was rough. But even your basic full stack web application is usually 5 languages: SQL, a backend language, HTML, CSS and JS. Usually some wheel reinventing frameworks thrown in for good measure. 5 languages is light these days.
I work in Java, Golang, Python, with Helm, CircleCI, bash scripts, Makefiles, Terraform, and Terragrunt for testing and deployment. There are other teams handling the C++ and SQL (plus whatever dark magic QA uses).
This is literally how this all started for us lol. Senior wanted to try to migrate everything to Kotlin in our project. Migration never finished. Now one of our major repos is just half Kotlin half Java. Devs on our team learn Kotlin by unexpectedly encountering it when they need to touch that code.
Maybe it's because I know both languages but is that really a big issue for people? The interop is great, and kotlin is very readable, so the cost of context switching between the two is miniscule.
Some people have an extreme aversion to learning new things though. I feel that holding yourself to the standards and limits of your lowest performers isn't a great thing.
Sounds like you're making progress, your devs are slowly learning a better language that will let them work faster and will soon be able to help port the rest of the codebase and then you can really accelerate when no one needs to touch or know Java.
Doesn't Kotlin has interoperability with Java? I didn't used it much yet but I'm about to in a few months. Is it that difficult to just refactor things to Kotlin when you need to change something in the project? I'm asking because I just can't work with verbose languages and would prefer Kotlin to Java everyday.
The python code we inherited had some performance issues. One of the guys was like "we should rewrite this in Java".
Luckily the boss was not an insane person and shut that down. The issue was an entirely stupid "...and then we do one query per project" behavior that worked fine when the company was small but unsurprisingly started to suck as users created more projects.
Instead of a months long complete rewrite, we had a two hour "let's add profiling... Oh wow that's a lot of queries" session.
I would say that over a decade of my career was coming in as a freelancer to fix codebases where a couple of people tought they knew better than the previous ones and proceeded to add yet another very different block to a codebase already spaghetiffied by a couple such people.
Sometimes it was coding style, sometimes it was software design, sometimes it was even a different language.
I reckon thinking that just deploying one's EliteZ skills on top of an existing code base without actually refactoring the whole thing will make it better is a phase we all go through when we're still puppy-coders.
The majority of puppy-coders I've encountered (including myself) actually want to refactor rather than just add onto. They are fundamentally correct in this, but they don't grasp that 1) few companies want to acknowledge that the code base which is their greatest tangible "asset" is actually complete shit, and 2) that due to their inexperience, their refactored replacement is probably going to end up as bad as or worse than the original.