On reflection, I think if the Scala creators had been a bit less obsessed with symbology and had either a) used keywords rather than symbols more often or b) consistently only ever used a symbol for the same one purpose; the outcome would have been significantly better.
There are just too many symbols to cover them all in a short book or cheat sheet, and symbols are very SEO-unfriendly. And even if you do find the relevant medium article, it's not necessarily clear that you're looking at the same use case for that particular symbol.
There's been a lot of sensible work in the core codebase since then to move towards more coherent idioms, unfortunately the 'we can make Scala into Haskell' crowd have since taken up the mantle and everyone has become obsessed with the idea that no boilerplate starter project is complete without cats or similar which perpetuates barely-legible and unnecessary confusion in situations that should be simple.
This might not be something to pin on the language designers, if you're using certain third-party libraries. Indeed it is possible to name a method pretty much whatever you want, with some constraints[0]. Wanna call it "!^"? Go ahead! But, this is afoul of the naming convention in many cases[1]--acknowledging that the convention may have previously been a bit more lax in this regard.
OTOH the distinction between "::" and ":::", and the implications of stuff like "<:" often do require a refresher if they're not part of one's day-to-day.
[0] https://stackoverflow.com/questions/7656937/valid-identifier... [1] https://docs.scala-lang.org/style/naming-conventions.html
If the language designers allow methods named "!^", then someone will actually name a method "!^".
https://docs.scala-lang.org/cheatsheets/
Double arrow seems to have multiple uses - for anonymous functions (like in js) and for pass-by-reference arguments (I guess scala is pass-by-value by default).
(Surprised at how Erlang-y it feels, especially WRT pattern matching)
The best (but still not exhaustive) doc is : https://stackoverflow.com/questions/7888944/what-do-all-of-s...
Kotlin is basically the language Java should be after 20 years of lessons learned, e.g. language-supported Optionals. The JVM is a battle tested platform. Once Project Loom comes out, you'll get the "best of both worlds" - the easier (i.e. "no functions 'colors'") programming model of multiple threads like in Java, but the scalability and performance of things like async in NodeJS.
It's not clear whether Loom will be a big hit. Personally, I think the Actor model is the best application level concurrency "primitive", and Loom is just about fibers & continuations, both of which are parts of Actors but aren't really Actors themselves.
I just recently started to explore Quarkus, GraalVM to optimize Java microservices for cloud architecture. It's good to know that Java moves into that direction.
https://mail.openjdk.java.net/pipermail/discuss/2020-April/0...
I'm kind of curious about this. What kind of lifetimes are you looking at for JVMs? Are you trying to use Java in lambdas on demand to user requests? What kind of warmup time are you seeing right now?
Fast startup time is just a good bonus.
That's for my use-case. Lambdas, obviously, demand fast start-up.
Would anyone be able to recommend a good resource for quickly learning modern Java for experienced programmers that already know, let's say, one of {Python,Javascript} AND one of {Go,Rust,C,C++}, but have zero JVM experience?
(Ideally the resource would also teach some relevant things about the JVM itself rather than the Java language specifically.)
One way to get into it is to build something real, first on bare bones (e.g. 'javac Main.java; java Main'), then bare bones Maven, then finally pick a great starting project which itself curates some of the best techniques and libraries currently available for the platform. I am partial to Dropwizard. Do not skip the first two steps though, because if you dive immediately into Dropwizard you'll be disoriented.
I would also suggest avoiding IDEs at the beginning. They hinder more than help at the beginning. One fun thing to do is download the JDK and the docs and source (usually a separate download, alas) and then disconnect your laptop from the internet. See how far you can get with it! Sadly, File IO in Java has always been verbose, but it is probably useful for you to suffer through it.
What will keep you in the office to all hours is the ecosystem. Now the ecosystem is probably best in class so don't mistake this as a slight, but it's huge and complex.
Learning Gradle (or Maven), understanding how to make building java apps fast (because the default is slow package assembly times), learning some of the large frameworks (if you go down that route) can keep you occupied for years.
If you're fresh to java, i'd probably encourage you to try avoiding the incumbents like Spring and see how you go? Without Spring, Java is actually pretty efficient. A hello-world rest service with spring results in around 6,000 classes being loaded.
That said - spring, used idiomatically, is a productivity boosting powerhouse.
(Not a fan of Gradle)
More recent changes are relatively smaller and probably don't need a full book to cover.
Would recommend it after Effective Java (3rd edition).
skim over Java 5 syntax. It should be very easy to understand for anyone with programming experience.
Explore Java 8, 11, 17 features, but try to map all the syntax to Java 5, because those features usually are just a syntax sugar and I think that it's easier to understand those features this way.
Do not dive into standard library too much. It's vast and you can spend a lot of time studying it, but that's not necessary to start.
It should take few days of learning and experimenting.
After that you have to choose a framework, because Java applications are very framework-heavy ones. And that's where most of complexity comes from. People usually use Spring these days, so that's probably would be the most reasonable choice. There's no easy path, you'll struggle a lot and that's unavoidable. Modern Java Frameworks are full of hard to grasp concepts, tricky magic code and 20-year old roots buried in the depths of stacktraces.
Stackoverflow a lot, and you'll eventually naturally learn most things you need to know.
At some point I'd recommend to prepare for Oracle Java Certification (Oracle Certified Professional). It's a very good exam with lots of core Java topics and with some gained experience you'll structurize everything in your brain and you'll learn few things that avoided your attention before. I don't suggest to actually pass the exam, as that would cost some money and effort, so it's up for you to decide, but preparing to exam is very worthwhile time investment.
Honestly that does not sound like a culture/ecosystem it is pleasurable to work within. Why wouldn't people choose something more modern and lightweight than Spring?
This is actually also a weakness because there is no good competition in terms of alternative Kotlin IDEs. Eclipse and VS Code have Kotlin plugins but they are nowhere near as good as their Java support. Nice in a pinch if you really can't be bothered to install Intellij.
Java undeniably has great alternative IDEs. I think it's still unrivaled in the wide variety of very decent IDEs and by pretty much every other language. And that has been the case for a long time. Eclipse and Netbeans are still around and both still do a fine job. If you use emacs or vi, there are decent plugins for those as well. VS Code of course has pretty decent support. Kotlin support for all of those is not at the same level.
But one positive thing that has come out of Kotlin (and Scala) keeping the pressure on Oracle is that they have rapidly rolled out a lot of new Java and JVM features in the last few years. JDK 17 is a nice piece of technology with lots of under the hood changes that benefit all JVM languages. So is Graal. I think the efforts to make Java more usable are also going to be nice for people with Java code bases.
Like the author though, Kotlin is my main language at this point.
I don't see why I should force my company into vendor lock-in (IntelliJ/Kotlin) on what is otherwise an open platform (Java/OpenJDK).
https://blog.jetbrains.com/dotnet/2016/01/13/project-rider-a...
I'm 90% certain I would only really start working on a project if we could use Kotlin just because the ergonomics are vastly superior. If that requires the trial-by-error mentioned ITA to figure out the best practices of various approaches available I think I'd take that trade off.
As others have mentioned, with Kotlin you're pretty much limited to Jetbrains' IDE, you have a new runtime dependency, not just a compiler, which is rapidly changing and requires updates on the code base frequenly (one of my projects used Kotlin for testing with KotlinTest - which recently changed names to KTest I think - and it was horrible to have to re-write most of my hundreds of tests to be able to upgrade when they went from JUnit 4 to 5 and in the process re-wrote all of it, basically), the compiler is slower and it starts to feel very much once you have thousands of lines of code... not to mention that there's a fairly big overhead of not only having to have javac installed, but also the Kotlin compiler and standard library... also, you probably want to use Gradle with the Kotlin DSL which in my view is really, really slow and unpleasant to work with - though they've finally been improving this recently - in the last couple of years.
So, yeah, I like to write Kotlin code better than Java, but due to all of these factors and the fact that Java is now fairly close to Kotlin in functionality, if I had to start a big project today, I would pick Java for sure.
I‘m planning on revisiting Scala at some point
- Greatly improved error messages [1]
- Revamped implicit syntax that makes it more straightforward to declare type classes and extension methods. [2]
- Simplified support for macros [3]
[1] - https://www.scala-lang.org/blog/2020/05/05/scala-3-import-su...
[2] - https://dotty.epfl.ch/docs/reference/contextual/type-classes...
[3] - https://docs.scala-lang.org/scala3/guides/macros/index.html
EDIT: I find it quite depressing that so many want to attack people for being confused around Java licensing. I submit that it is confusing on its face, but moreover insiders seems to understand how confusing it is, too:
https://softwareengineering.stackexchange.com/questions/1194...
https://medium.com/@javachampions/java-is-still-free-2-0-0-6...
The only people I EVER encounter with any confusion around Java licensing are students, entry-level devs, and people from other ecosystems who parrot things they hear on Internet forums.
OpenJDK is free and open source. It imposes no license restrictions on your server-side applications, and these days imposes virtually no limitations on retribution of the JDK itself with traditionally-shipped applications.
Oracle's own binary build of the OpenJDK source code is a commercially licensed thing, because it comes with some extra proprietary tools that people might care about when profiling applications in a large enterprise. But there are other OpenJDK builds with no cost or licensing restrictions whatsoever, from Azul, IBM, Amazon, and others. Outside of the largest and most conservative Oracle shops, virtually everyone uses one of these free JDK builds.
So much nonsense FUD is made from "lack of commercial support" for the non-Oracle JDK builds. Not "having someone to sue" if something goes wrong, etc. For one thing, who are you supposed to sue when you have a problem with Python or Node? If you want someone to be financially liable to you, then you have to financially pay someone to take on that liability. In practice though, have you ever even heard of a lawsuit over a JDK bug? This is nonsense.
I personally don't think these are stupid or trivial questions. Nor do I think the answers are obvious. Nor are they nonsense FUD. I am certainly NOT an Oracle partisan - I saw first hand what they did with Sun.
Without Corretto, I think Oracle really has poisoned the well.
https://www.oracle.com/za/java/technologies/javase/jdk-faqs....
lack of enterprise support.
And also what javajosh said. Here's a(n arguably biased) corroboration: https://www.mondaq.com/unitedstates/corporate-and-company-la...
Just sign the license and agree to all the terms and conditions. Nothing will go wrong.
But for the rest of the world, you can also get certified JDKs from Azul, Amazon, Red Hat and a few others. All fine choices. Pretty much the entire financial industry, including some of the most conservative companies on the planet, depends on Java and I doubt most of them are paying Oracle for that. Why would they?
I wonder if MSFT will ever make C# run on JVM.
Java has way more web framworks from what I've seen (could be a good or bad thing), and more alternative languages that you can pick from.
I just do some Clojure programming, and I'm not deep into JVM things - but why does Android not even make a mention? Isn't it the most widely used JVM platform..?
2 -
> This does come with some restrictions and caveats; for example, it's not as straightforward to use Reflection in your Java code.
Is GraalVM going to push Reflections out of Java/JVM?
I guess my angle is I'd like to use the JVM to make (desktop) apps. Last I did, using cljfx/JavaFX reflections were a huge sore point. Ever dependency would drag in the whole kitchen sink - and reflections are an ugly wart that prevent unused classes/namespaces from being pruned.
I know technically there is Proguard.. but it's clunky and ugly I've never gotten it to work with Clojure. Graal native looked like a sort of light at the end of the tunnel.
3-
Whats the story with WASM and the JVM? Both designs seem eerily similar - but I don't know if the gap between the two is too large to bridge
I very much doubt reflection is going anywhere. For one, GraalVM native images support reflection, you just have to state ahead of time what you plan to reflect over.
WASM+JVM works. You can run WASM on top of the JVM. There's a Truffle interpreter for it, which means WASM code gets JITCd by the JVM itself and you can interop in and out. Check out GraalWASM.
- I can keep around the bloat
- I can try to find an 3rd tier library with less eyeballs that's smaller and does less (If I later want to do more image manipulation I might find myself in a bind)
- I can try to manually go in and trim out the stuff I think I'm not using (not that I really understand the BoofCV internals..)
So the ecosystem is actively discourages me from using large mature libraries :( (I ended up using option 3 with trial and error)
Graal maybe sidesteps the issue. Yeah it has reflections, but as you say you need to be explicit about them. So the rest can be trimmed.
I guess my original loaded question was implying that maybe this will make library developers more keen on dropping reflections internally (it's honestly almost never a good design choice anyway)
That all being said.. I think 90% of people are writing some server-side web stuff and none of this matters to them :)
> GraalWASM
I'm kinda curious about the other way around. Running JVM byte code on WASM. Not in any serious way.. but it'd be cool you could run an uberjar in the browser. A quick search brings up a few ongoing projects :)
Exactly the opposite of what comes to mind when I think of these.
val numVowels = countVowels(getDTO()?.string ?: "") val numVowels = getDTO()?.string?.let(::countVowels) ?: 0> Building large teams (think hundreds or thousands of developers) requires talent, and talent is easier to find if more people know the language (although, if you want the absolute best people, you might be better off choosing a more niche language).
It's very easy to hire good Java devs and crosstrain them to Kotlin.
> Java also arguably has the best tooling in the business. I'd argue that IntelliJ IDEA (and family) is the best IDE out there, more so if you are coding Java. Even if you prefer VS Code, Java is well supported.
Jetbrains of course make Kotlin also, and theoretically their Kotlin IDE support will be better than Java's once they complete the mainlining of the Kotlin plugin into the IDE code base. (Right now the Kotlin plugin has recurrent stability issues.)