Live data from Hacker News

Revisiting Java in 2021 – Part II

avanwyk.com

121–130 of 146 posts

Re: Revisiting Java in 2021 – Part II

#121
post #35

Earlier quoted context omitted.

I don't have an answer to your question, but I would suggest the following: 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. I…

> 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…

> Honestly that does not sound like a culture/ecosystem it is pleasurable to work within.

I agree. Of course I’ve heard people criticizing and making fun of java over the years, but I didn’t realize the (very helpful and thoughtful) answers to my question would be so depressing.

Re: Revisiting Java in 2021 – Part II

#122

I think when Project Loom comes out that Kotlin on top of the JVM will be a tough combo to beat. 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 th…

I think for Kotlin that ship has sailed with the introduction of suspend functions.

I remember reading that you can plug any continuation model into the suspense mechanism?

Re: Revisiting Java in 2021 – Part II

#123
post #8
post #4

I'm not a huge fan of Java, but a lot of the improvements being worked on here are promising. 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.

Have the ergonomics of Scala improved with version 3? I‘m planning on revisiting Scala at some point

optional braces if you are into that sort of thing. https://docs.scala-lang.org/scala3/reference/other-new-featu...

Re: Revisiting Java in 2021 – Part II

#125

The comments about Scala resonated. I've been working in a a large Scala codebase for the past few months. I've become a partial fan of the language, however: there have been multiple conversations like : (in screen share with colleague) "See that double right arrow there? What's that mean? (after attempts to find answer in books, SO, etc, and trying to guess based on the three/four other uses the language makes of d…

If you can't use an IDE to jump to the definition (or list all possible definitions) of a function, then aren't you missing one of the main benefits of a statically-typed language? If you can't use the static types for static analysis, what's the point?

Jump to definition is not some special benefit of static typing. Every Common Lisp IDE that I know of offers it, for example.

Re: Revisiting Java in 2021 – Part II

#126
post #114

Earlier quoted context omitted.

Sure but the issue is that when a single symbol has multiple meanings that presents an obstacle to learning the language and understanding a code base.

How do you feel about = (assignment and equality check)? Or > which can be used for markup or less than or part of a function arrow? Or {} which can be used as a block or as an object? Or : which can be used for...so many things! Even the humble . can be used to dereference or as a decimal point. My point is that if "a symbol having multiple meanings" is a problem, then basically all languages have a problem.

Well Java isn't too bad in that regard. It uses = for assignment and == for equality.

Re: Revisiting Java in 2021 – Part II

#127
post #91

Earlier quoted context omitted.

what woud be a lean alternative for microservices to spring boot?

The most lean and interesting alternative IMO is Helidon SE. It's backed by Oracle and uses very sane approach. The most pragmatic alternative IMO is Quarkus. I don't really like it, but it seems to be the most popular alternative to Spring and probably will become standard de facto, unless Spring will jump ahead with some revolutionary changes. It's backed by Red Hat and seems to have the most momentum. The best app…

What's your opinion on vert.x vs quarkus? For more general purpose web stuff, it seemed to me vert.x had more libraries.

Also, as for database, I really got fed up with hibernate (all configuration and stuff), do you know any simpler asynchronous / reactive alternative that handles object mapping? (automatically serializing from / into SQL objects).

Re: Revisiting Java in 2021 – Part II

#128
post #85

I think when Project Loom comes out that Kotlin on top of the JVM will be a tough combo to beat. 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 th…

Java seems to be heading for ML-like features while Kotlin is a "better Java". I think Kotlin lack a vision for the future, and might lose market share as Java itself gets better.

Since Java is now a neglected, second-class, incompatible elder citizen on Android, this is unlikely to happen.

Re: Revisiting Java in 2021 – Part II

#129
post #26

Changing companies led me from C# to Java. I feel so much less productive in Java, so much extra boilerplate everywhere. C# is just as mainstream as Java, so learning curves and nicheness arguments don't apply, it's just better. I wonder if MSFT will ever make C# run on JVM.

That's basically how C# came into being in the first place. Microsoft "bought" Anders Hejlsberg of Borland Delphi fame, and had him create a "better Java". And IMHO Visual J++ was a much superior Java, with a visual designer that was much more advanced than anything else available back then. The problem? It was very much Windows Only (tm) if you wanted to use the advanced features. Sun was not happy about this. And the end result of the legal struggle was that Microsoft used Visual J++ as a base for C# and scrapped Java compatibility.

Re: Revisiting Java in 2021 – Part II

#130

> Build tools such as Maven and Gradle are fast, stable and effective Exactly the opposite of what comes to mind when I think of these.

Maven is quite stable and effective - maven pom's can remain unchanged for years and still build. However it is not fast.
Post reply on HN