Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Modern Java Platform – 2021 Edition

jamesward.com

Post reply on HN
Print view View original

251–259 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#251

Post by diroussel »

erikds wrote: post #111
sandGorgon wrote: post #61

Really the future of the Modern Java Platform is Graal - https://www.graalvm.org/reference-manual/embed-languages/ Java is not Spring Boot. For example, this is Python 3.8 compliant runtime on top of Graal - https://www.graalvm.org/reference-manual/python/ You can also compile your application into a native image (like Go?) - https://www.graalvm.org/reference-manual/native-image/ you can try it in the next 5 mins 1.…

Never heard about Graal before. When reading the description it reminds me of WebAssembly. Can anyone compare how they compare?

The simplest way to think of Graalvm is that it’s not a VM, it’s just a plungin replacement for Hotspot. Hotspot is written in C++ and hard to change. So once the java JIT is written in java it will be easier to innovate.

But then they took the base and used the java to machine code capabilities to be able to do ahead of time compilation to machine code.

But the most amazing part is that if you use the graal apis to define an interpreter for a language (any language) then graal can generate a compiler from that interpreter. It will compile all that is known at compile time and leave to runtime what needs to happen at runtime. So essentially it does partial compilation.

Re: The Modern Java Platform – 2021 Edition

#252

Post by diroussel »

selfhoster11 wrote: post #150
zaphar wrote: post #136

Earlier quoted context omitted.

I'm not critical of spring because real life software projects are messy. I'm critical because I rarely if ever do greenfield development and when I'm debugging a production exception caused by something that Java's type system was perfectly capable of treating as a compile time error that is suddenly a runtime error I'm a little bit sad. And the sheer frequency that I encounter them indicates that just getting more…

The real solution is to bite the bullet and build Spring's features into Java. Make as many failures as possible detectable during compilation, and go back to hard typing.

Micronaut gives you that. Compile time validation of your bean wiring.

Re: The Modern Java Platform – 2021 Edition

#253

Post by reda-alaoui »

lmm wrote: post #21

There's some great stuff on the JVM today, but Spring Boot is recapitulating all the problems of J2EE. Everything is extremely "decoupled" to the point that you have no idea where anything comes from or why, and just adding a new dependency to your classpath will radically change the behaviour of your application (oh, you added a dependency on a library that has a transitive dependency on the MongoDB client? Guess th…

I think too that Spring Boot opt-out autoconfiguration is an issue.

Take a look at https://github.com/spring-projects/spring-boot/issues/25742#...

I included a workaround allowing to opt-in for autoconfiguration instead of opting out. I have used the filter for more than 2 years without issue.

Re: The Modern Java Platform – 2021 Edition

#254

Post by kaliszad »

NOGDP wrote: post #173
kaliszad wrote: post #36

Earlier quoted context omitted.

Actually, Java, its syntax, the explicit types and how its often taught only obscure the solutions that could be much more obvious. Since I have seen Clojure, I was swearing why nobody has shown it to us right in the beginning when I was in the university. Back then, Clojure was already an established, stable language and that has been a decade. I could just skip the C, Java and other classes and would be a much bett…

You're not saying anything specific about what's wrong with Java. Java is not perfect, but you haven't actually given a single good reason. The type system alone is a huge benefit over languages such as Python/Ruby. Lisp has existed and been taught for a long time, and I like Lisp languages such as Clojure, but the allusion to Clojure being some kind of magic bullet is also pretty baseless.

Well, I did say at least 2 specific things (syntax, explicit types). But maybe approach this a bit differently and talk about what is great in Clojure that is not good in Java: - persistent datastructures that can easily be made transient in specific performance critical cases - consistent syntax - the language itself is a datastructure so manipulating of code is very easy and you have a serialization format (again EDN) basically for free - the REPL - most of the code transfers 1:1 to ClojureScript, that is not the case for Java and JavaScript which are completely different languages and have very different strengths - dynamic types, but out of the box type hinting is available for some corner cases where it improves performance/ makes interoperability a bit clearer and e.g. using clojure.spec you can with some effort make something approaching depend type systems/ very strong tests incl. generative testing - Clojure/ ClojureScript interoperability with the Java/ JavaScript ecosystem - developer productivity - actually performance especially compared to Python/ Perl/ Ruby, very carefully written Java would win microbenchmarks but in Clojure you can probably improve the overall performance of a large codebase because in the same time as you would need with Java you can do many, many iterations more and therefore explore the optimal solution - you can become very proficient in Clojure in about 6 - 12 months where with Java you probably need maybe 3-5x that time to tackle the same problem space

Yes, some of those things are not so specific to Java. If you only care about performance in micro-benchmarks Java would probably win but probably 95% of the problems in the real world are way more complex. Also, good luck writing correct multi-threaded code in Java vs Clojure. Clojure is uniquely positioned for multi-threaded workloads thanks to persistent datastructures, atoms, agents etc.

Re: The Modern Java Platform – 2021 Edition

#255

Post by kaliszad »

Aperocky wrote: post #38
kaliszad wrote: post #31

Earlier quoted context omitted.

Types almost never save the day and they don't add much to the understanding. The code should be structured and documented in such a way that you are able to understand it, reason about it and swap implementations of stuff in the places where such flexibility is handy. E.g. in Clojure, I can trivially test my functions in the context of the application using the REPL. I don't have to reload anything, I do it right in…

That's strongly dependent on how big the code base is. I'm a huge python fan, and I don't like/use IDEs on my personal projects. But eventually I still gravitated towards typescript because it had typing and the compiler + unit tests giving me a huge boost in ability to extend my project beyond a certain size. I think the threshold is around 50-100 files, but smaller code bases also benefits from the typing structure…

At OrgPad, we are well over 100, maybe even 200 namespaces in Clojure and ClojureScript and I don't think we have any trouble keeping up. Most of the problems we have are frankly not in any capacity connected to Clojure or ClojureScript but rather half-baked, inconsistent technologies and their implementations like CSS, browser interoperability/ APIs mostly. The server-side (Clojure) is rather boring currently, so can't say much about that - most of the stuff seems to be just ok. There seems to be a lack of libraries for transforming image/ video formats in Java for the newer formats like WebP, AV1. Probably most people drop to imagemagick/ ffmpeg? That is kind of a problem, but not really pressing. We have lost much more time to CSS and bad browser APIs.

Re: The Modern Java Platform – 2021 Edition

#256

Post by kaliszad »

tiew9Vii wrote: post #119
kaliszad wrote: post #31

Earlier quoted context omitted.

Types almost never save the day and they don't add much to the understanding. The code should be structured and documented in such a way that you are able to understand it, reason about it and swap implementations of stuff in the places where such flexibility is handy. E.g. in Clojure, I can trivially test my functions in the context of the application using the REPL. I don't have to reload anything, I do it right in…

> Types almost never save the day and they don't add much to the understanding. There’s a saying in strongly typed languages “make illegal states unrepresentable”. Java doesn’t let you get all the way there but it’s better than nothing. When you look at strongly typed languages with a good type system, often when you compile it just works. Besides hello world, I’ve never written program beyond a few lines that has ju…

Can you be more specific about your friends codebase? How large, what industry/ problem space?

Of course, you can write bad/ unmaintainable code in any language. I have seen such code in Clojure(Script) as well. But some languages really encourage bad code where other languages already feel like you are doing something wrong when you write bad code. (e.g. Using many atoms in Clojure, doing boolean transformations etc. just from the top of my head.)

Strongly typed languages in my experience don't help anything, make programming harder for everybody and the benefit is (for most software) questionable. Compilers should handle most types for us and only give us a hint something could be better, if we were more specific e.g. with a type hint. Humans should think about the problems not about deep implementation details (like integer vs float vs double), when not strictly needed.

Re: The Modern Java Platform – 2021 Edition

#257

Post by slt2021 »

eecc wrote: post #212
marcosdumay wrote: post #177

Earlier quoted context omitted.

Enterprise as in "sold to enterprises" or as in "created by enterprises"? Both are complex, but for different reasons. Software that is sold to enterprises is complex because they compete on number of features (in checklists), and there is no pressure for quality since the software users have little saying on what software gets brought. Software that is created by enterprises for internal use is complex because the e…

> Software that is created by enterprises for internal use is complex because the enterprises themselves are complex. They are full of rules, created by different people with very different goals, that add up with time, and the applications must deal with them. Maybe it's just me and my scarce disposition for forgiveness, but after several years I tend to believe complexity emerges as a consequence of superficial und…

agree on poor analytical skills. top talent devs tend to work on front-office apps that generate $, and not the backoffice intranet type apps for internal employees and processes. i think it is a function of compension difference as well and dev self-selection

Re: The Modern Java Platform – 2021 Edition

#258

Post by ksec »

vips7L wrote: post #123
oblio wrote: post #98

Earlier quoted context omitted.

I've never seen or heard anyone major use GraalVM in production. I only hear Oracle and a small bunch of other folks hyping it. Tech also lives on hype and a long time until a tech reaches a critical mass is generally a band indicator (i.e. if something doesn't reach the mainstream in less than N years, it never will). There are some exceptions (Ruby took off after Rails was launched, Python was adopted by Linux dist…

Twitter runs graal in production.

Also Shopify.
Post reply on HN