- 62951413 parenthttps://inside.java/2024/05/23/dop-v1-1-introduction/
- If you have a use-case where you currently allocate ~1K threads mostly waiting on I/O switching to virtual threads is a one-liner ("Thread.ofVirtual()" instead of "Thread.ofPlatform()"). No more golang envy for sure.
Depending on how much memory is used by the Thread stack (presumably 1M-512K by default, allegedly 128K with Alpine base images) that's your 1G-500M heap space usage improvement right off the bat.
The migration from JDK17 to JDK21 was uneventful in production. The only issue is limited monitoring as a thread dump will not show most virtual threads and the micrometer metrics will not even collect the total number of active virtual threads. It's supposed to work better in JDK24.
The Spring Framework directly supports virtual threads with "spring.threads.virtual.enabled=true" but I haven't tried it to comment.
- In a galaxy far far away so called "J2EE application servers" used to be the reason JDK upgrades were not allowed. And that would probably be a real major update Java project.
When I joined my current team (in a big honkin' corporation with a history of layoffs and outsourcing) I inherited a dozen microservices, all on JDK8 and a couple written in Scala. So among the first things I did was an upgrade to JDK17 of every single repository. And it was mostly uneventful. More or less use a different Docker base image and bump up the Spring Boot version from 1.x to 3.4. Not running the latest LTS release is professional negligence in my book.
- You can ask them a single question to know the answer: do they have any cats/scalaz in their production code? Without their ilk Scala 10 years ago was the language Kotlin and Java are still trying to be.
But from what I have observed in the last few years Scala is either used in legacy projects or you're talking to a hard-core FP shop. The saddest fact that it's true even in Data Engineering with Spark :(
- Apache DataFusion Comet is a high-performance accelerator for Apache Spark, built on top of the powerful Apache DataFusion query engine: https://datafusion.apache.org/comet/user-guide/overview.html
- You're unfortunately right. Every Scala codebase I have seen recently is essentially legacy. New services are not built with it anymore. Other than blaming SBT and the Haskel fans I'm not aware of a technical justification. But the industry/community has shifted since 2015-2018.
The only rare exceptions I heard of were strict FP shops who share nothing with common JVM-based development. You could have a few years of full-time Scala experience with Akka and Spark and they won't even screen you.
In the year of our Lord 2024 the question is if you want to bet on Java21+ catching up with Kotlin or go with Kotlin from day one. The choice is less obvious nowadays. I'd go with a modern language, actual job market sides with Java still. At least on the backend in the Bay Area.
As a side note, I cannot imagine a competent JVM-based developer not familiar with either Kotlin or Scala by now. In a typical Java shop half of the team is dying to switch to one of them in my experience.
- There's one book that discusses a few related questions from a very mainstream perspective: Functional and Reactive Domain Modeling (https://www.manning.com/books/functional-and-reactive-domain...). The emphasis here is on practical while most similar resources tend to go too hard in the Haskell-on-the-JVM direction.
- I'm curious how one ends up with such ahistorical sequence. I'd expect it to be more aligned with the actual PL history. Mainstream PLs have had a fairly logical progression with each generation solving well understood problems from the previous one. And building on top of the previous generation's abstractions.
Turbo Pascal for education, C as professional lingua franca in mid-90s (manual memory management). C++ was all the rage in late 90s (OOP,STL) . Java got hot around 2003 (GC, canonical concurrency library and memory model). Scala grew in popularity around 2010-2012 (FP for the masses, much less verbosity, mainstream ADTs and pattern matching). Kotlin was cobbled together to have the Scala syntactic sugar without the Haskell-on-the-JVM complexity later.
And then they came up with golang which completely broke with any intellectual tradition and went back to before the Java heyday.
Rust feels like a Scala with pointers so the "C++ => Rust" transition looks analogous to the "Java => Scala" one.
- Ce n'est pas un Kafka: Kafka is a Protocol Apache Kafka is an aging open source project. It's time to accept that Kafka's protocol is what matters. (https://materializedview.io/p/ce-nest-pas-un-kafka)
- Anyone with a Java background will mention JCiP. But there's another book going deeper - "Art of Multiprocessor Programming" (https://www.amazon.com/Art-Multiprocessor-Programming-Mauric...).
- AWS Fargate is popular among large companies in my experience.
Some of them try to migrate from it to a unified k8s "platform" (i.e. frequently not pure k8s/EKS/helm but some kind of in-house layer built on top of it). It takes so long that your tenure with the company could end before you see it through.
- You kind of can peek into parquet files with a tiny command line utility: https://github.com/manojkarthick/pqrs
- There are two pinnacles in a traditional CS program - building a compiler and a DBMS. They are umbrella topics that prepare you for building pretty much any kind of software.
If you came to programming because you liked computers you'll find building an interpreter a fascinating topic in its own right. Building a compiler frontend is comprehensible and reading a modern/practical textbook (e.g. based on ANTLR or whatever is the latest parser generator in the wild) will illuminate so much for you.
You're highly unlikely to find a job with this skillset though. There are very few companies that do it, very small core teams, and there's competition with PhDs from top tier schools. The current leetcode fashion will ignore your niche knowledge right off the bat. So from this perspective the utility of knowing this stuff has always been a grey area regardless of the AI.
If you like money more than you like computers surely aim for an MLE position instead of SE/DE. But that's kind of a selective club too I imagine.
- Let's talk about you growing older. The closer you're to 50 the more difficult it gets to find a new job. You get laid off in a major downsizing round. Your COBRA healthcare plan is $2K+/month which incidentally is comparable to your 1-bedroom apartment rent. It could take you a few months to find the next job. Or longer, people discuss it on this very site every other week.
The FAANGs and the capital gains are real but for a minority of us. If you're single and under 30 the Bay Area is a top destination for sure. You won't be that person forever though.
- Core Java by Cay Horstmann (https://horstmann.com/corejava/) is a well-structured and concise review of major features. Historically, the most interesting chapters were scattered across both volumes. So completely skipping the "Fundamentals" volume was ill-advised while the "Advanced Features" volume had some boring and mostly unnecessary chapters.
- Last years I worked for a SJ-headquartered public company with spectacular compensation. While I was still there they stopped hiring in CA and the gossip was about TX. But on my team new roles were opened in Europe instead (surprisingly, not Eastern). The layoffs were concentrated in the Bay Area too. I heard that since then they started looking for even cheaper locations.
I have recently seen large American companies where managers/team leads are full-time employees while their teams are mostly contractors from LatAm. And even those managers are not on PST. They advertise "W2 contract-to-hire" roles here in the US though.