8 ms·
Micronaut 2.0: a full stack Java framework for modular, testable applications
- vips7L 6y agoI personally don't like the reactive model especially with RxJava. You quickly end up in Observable hell.
- jswny 6y agoI agree. Having used reactive Java and the Elixir/OTP model of message passing, I can safely say that I'd never go back to reactive Java unless I was forced to. It feels like you are fighting the language the whole time.
- vips7L 6y agoHopefully Loom will be our savior.
- lliamander 6y agoI haven't used reactive Java, but I have used the async/await model of JS as well Erlang/OTP, and I definitely prefer message passing. The mental model is so much easier to reason about.
- zmmmmm 6y agoIt's a shame because it seems to me like RxJava is eclipsing what was previously a pretty fertile ecosystem of Actor based approaches, but RxJava itself is not very nice to use compared to those which are much more natural.
- apta 6y agoLoom should solve all that.
- unscaled 6y agoI think Loom is thrown around too haphazardly here. Loom will present an ergonomic alternative for concurrency that is strictly superior to futures, but it will not replace or significantly simplify RxJava[1]. Project Loom is also orthogonal to actors - it really doesn't dictate any specific concurrency model, it just provides fiber support in the JVM. We will definitely see actor libraries once project loom is released, but these are already available now, and they are not widely used. The only thing Loom can help them with (I hope) is better performance, but I don't think that's the reason the actor model lost ground in the Java world. [1] Project Loom can be the basis for some minor simplifications, as JetBrains did in kotlinx.coroutines.flow.
- mping 6y agoI have never used Rx libraries. What are the cases where you have low friction coroutines such as loom (no "coloured" functions afaik) where you want to use RxJava? Handling backpressure? Modelling complex flows? Honest question
- apta 6y agohttps://wiki.openjdk.java.net/display/loom/Main https://wiki.openjdk.java.net/display/loom/Main
- MrBuddyCasino 6y agoIt is terrible, and has hidden gotchas. Use it only if you really really have to, then check if you can't do it in Kotlin instead with native async/await syntax, and only if the answer to those questions is "no", continue to shoot yourself in the foot.
- The_rationalist 6y agoThe reactive model is not here because people like it but because it enable to do optimizations that are normally mostly impossible to do. The real breakthrough is to use reactive programming + Rsocket which allow true asynchronous real time applications. And rejoice yourself, Kotlin Flow/coroutines has a clean API that feels synchronous and that still manage to be reactive streams compliant! It's mostly perfect and project loom will be the ice on the cake! Others platforms (non JVM) really have a lot to learn in this regard
- diroussel 6y agoHave you got any links, or can you explain the optimisations that are possible in RxJava? I've done some vert.x and creating new Futures all the time is a bit cumbersome, but I understand it. With RxJava it's another layer on top, and you are even more removed. The whole non-blocking experience in java feels like there is a lot of plumbing. I know it's fast for IO reasons, but it really feels like the JVM/CPU has to jump through a lot of glue code to make it work.
- The_rationalist 6y agocan you explain the optimisations that are possible in RxJava? Here's the fundamental problem that reactive programming solve: Here's a kotlin function from https://kotlinlang.org/docs/reference/coroutines/flow.html#suspending-functions https://kotlinlang.org/docs/reference/coroutines/flow.html#s... suspend fun foo(): List<Int> { delay(1000) // pretend we are doing something asynchronous here return listOf(1, 2, 3) } This function is not reactive but it is at least async. suspend ~= async keyword in js or C# As you can see its return type is not colored: List<Int> In inferior languages you would have a Promise<List<Int>> and need to check yourself for its resolution before accessing the value. (Promise == CompletableFuture) But this is not what matters here This example function is will be executed asynchronously, it will do processing on a list then return the list. It means that it will need to wait for all elements of the list to have been processed each before being able to use the result. The big idea is that with reactive streams we can process list elements asynchronously, individually https://kotlinlang.org/docs/reference/coroutines/flow.html#flows https://kotlinlang.org/docs/reference/coroutines/flow.html#f... fun foo(): Flow<Int> = flow { // flow builder for (i in 1..3) { delay(100) // pretend we are doing something useful here emit(i) // emit next value } } A flow is just an asynchronous list, an array of CompletableFutures if you want. Each time you emit() a value from the flow, the processed element will be received at call site, on demand Beyond this base idea, reactive programming add on to of it many useful concepts like: Cancellation primitive, automatic multithreaded dispatching, lazy or eager evaluation, many things and the ability to choose a specific scheduler (a blocking io friendly one for example) Reactive streams are fantastic ideas but API wise even with reactor it needed a lot of boilerplate and had incidental complexity. Kotlin flow bring the best of both world and is to me the state of the art asynchronous programming model, transcendanting goroutines.
- _bxg1 6y agoI've used a reactive model on the front-end for several years now (MobX at one job and then RxJS at another) and haven't encountered anything I would call "Observable Hell". I will admit that cascading side-effects can be hard to debug, but they're also a code smell. The whole point of the reactive pattern, IMO, is allowing you to have as few open-ended side-effects as possible. i.e., reactions that change state (instead of re-computing a pure function) should be scrutinized heavily and kept to a minimum. If they're kept to a minimum, then in my experience they remain manageable and fairly easy to reason about.
- thecupisblue 6y agoOh, you didn't do it in java. The mere boilerplate and heaviness of the language makes it Observable hell. Well, it got improved with lambdas the last time I used it, but it's still a clusterfuck of Observables, Singles, wrappers and knee-deep stacktraces. JS allows you a lot more flexibility as a language and it is a far better experience using RxJs.
- leonidasv 6y agoMicronaut supports Kotlin coroutines since 1.3. You're mostly stuck to Rx outside Kotlin, tho.
- zmmmmm 6y agoIt's wrong to focus on the reactive part - it's a feature that it is fully supported, but Micronaut is a generic framework that has both synchronous and async support. It's real secret sauce is the ability to make API building extremely concise, well type checked and performant (for JVM based apps - 10-100ms scale startup times etc.). For example, this is a Hello World API in Groovy (this is almost literally the entire Application): @Controller('/hello') class HelloController { String index() { 'Hello World' } }
- Nursie 6y agoWhile that is concise, the sparkjava version (without boilerplate): get("/", (req, res) -> "hello world") Is just as clear to me. Not saying micronaut doesn't have things to offer, but simplicity of setting up an http endpoint isn't unique.
- zmmmmm 6y agoSure - I was mostly just responding to the commenter implying that Micronaut leads you to "observable hell". The point is, if you apply it in standard synchronous mode it's just like any other framework these days.
- bcrosby95 6y agoAs someone that uses Java in my dayjob, I wish annotations were never invented. Debugging problems with them is hell. Why can't we just use method calls?
- pjmlp 6y agoBecause method calls don't compose as compiler plugins or runtime reflection. They were also not invented by Java, other languages like Dylan, Python and .NET actually go them first. Actually they are like a poor man's Lisp macros kind of.
- deleted 6y ago[deleted]
- mister_hn 6y agoBut I also hate to see my colleagues spawn threads and polling the whole time waiting for something happening, all without timeout
- greenie_beans 6y agoyour link is broken :/
- el_duderino 6y agoYeah. It's very slow to load right now.
- zaltekk 6y agoThis link seems to be working. You can at least read about the updates. https://docs.micronaut.io/2.0.0/guide/index.html#whatsNew https://docs.micronaut.io/2.0.0/guide/index.html#whatsNew
- dang 6y agoWe've changed the URL from https://objectcomputing.com/news/2020/06/26/announcing-micronaut-20 https://objectcomputing.com/news/2020/06/26/announcing-micro... to that documentation page. When a project hasn't been discussed on HN before, it's usually best to have the submission be about the overall project rather than the latest release. (This is the exact opposite of the usual pattern, by the way! if anyone's curious: https://news.ycombinator.com/item?id=23071428 https://news.ycombinator.com/item?id=23071428)
- ibejoeb 6y agoI'd try the 2.0. The 1.x line is really pretty buggy. I spent more time on gitter and trying to work around it than actually using it. I'm glad they're targeting performance, but the ergonomics of the API could use a lot of work. I was implementing an API that was designed without a particular technology in mind--and it was a good design--and Micronaut couldn't conform without significant hoop jumping. It's probably better suited to greenfields development.
- liquid153 6y agoBig fan of this project. I try and avoid reflection heavy frameworks
- gojomo 6y agoWhat's Micronaut? (Of course I've found more info by searching, but my real question is: why do teams proudly make major announcements without even including a link to their project, or at least an inline blurb about it for those first hearing about it via the announcement?)
- noisem4ker 6y agoA Java framework which tries to do at compile-time what other frameworks usually do at run-time (dependency injection, SQL query generation, etc.) (Yours is a lost cause.)
- Twirrim 6y agoSame old same old, this drives me nuts on so many open source project websites. I wonder how many good libraries languish in obscurity because of the lack of something simple like an elevator pitch on their landing page, or worse there is one but it's an overload of incomprehensible-to-outsiders jargon.
- stunt 6y agoNot only open source projects. Even many SaaS and PaaS projects have the same issue. They try too hard to make themselves distinguish from others that they end up with a fancy landing page that does not say anything useful and straight about them but some vague description. You really have to dig into to find out what is that they are doing. I like to think that's just a bad marketing tactic because I can't believe that they can't explain themselves clearly.
- dang 6y agoSince the project doesn't seem to have been discussed on HN before, we've changed the URL from https://objectcomputing.com/news/2020/06/26/announcing-micronaut-20 https://objectcomputing.com/news/2020/06/26/announcing-micro... to one that answers this question more directly.
- _old_dude_ 6y agoThere are actually 3 frameworks in Java that are competing head to head with Go, Micronaut, Quarkus and Helidon. Helidon is spearheaded by Oracle and currently fails to get some tractions. Micronaut is the baby of Graham Rocher one of the father of Grail (RoR in Groovy) and Quarkus is the baby of Emmanuel Bernard one of the father of Hibernate and supported by RedHat. All of them run on either a standard JVM or let you use Graal SVM which compiles Java to native with roughly the same trade off as Go (latency is more important than throughput). At my company, we have prototyped the migrating of a Go application that relies heavily of Kafka to Micronaut or Quarkus. We have found that Micronaut is less polished and more buggy than Quarkus but take it with a pinch of salt because it's just 5k of code.
- The_rationalist 6y agoWhat are concrete advantages of micronaut vs modern spring boot? Did anybody benchmarck startup time vs spring boot With lazy beans instanciation? Micronaut marketing must really address the rational fear that everybody should have: how much does micronaut (by trying to do more at compile time) slow down compilé time??? slowing compile time and making a LSP unresponsive is order of magnitude worse than slowing down startup time!! Also, a la Grails I would like to be able to use micronaut in combination with a spring lib (with spring boot application context) such as their rsocket integration or spring data / messaging
- ww520 6y agoThis looks good. Glad to see more microframework coming out of Java with emphasis on performance, memory footprint, and development ergonomic. Will try it out.
- hokkos 6y agoThe point of Micronaut is Graal, you can compile it native, it consumes 10 times less memory and starts in few milis.
- abeppu 6y agoCan you comment about how to actually use this approach for something useful? I've gotten toy services working with graal nativeimage, but every time I try moving a pre-existing project, I find that some library causes a problem.
- hokkos 6y agoGraal is a lot of work on some libraries, I had to use an xsd to pojo mapper, and it was a lot of profiling with the tracing agent that save the reflection and ressources used, when using spark java micro framework. But micronaut has a facility to automatically handling the mapping lib, so it is less work if it is supported. When porting the tracing agent and a lot of integration tests that test all the code branches is key.
- unscaled 6y agoI think it's a bit of misleading marketing. Sure, Micronaut (just like Quarkus and Helidon) is ready to be compiled with Graal out-of-the-box. But it doesn't magically make any library you use work with Graal, and it also doesn't mean you cannot get code based on other frameworks like Vert.x or Spring Boot work with Graal (with varying degrees of extra effort). Also, from all the benchmarks I've seen, GraalVM is not a free lunch. Native images trade peak performance for faster startup times and lower memory usage. It's a worthwhile trade for some people, but not for everyone. And yes, I know there are features like Profile-guided Optimization that can theoretically bring Graal closer to JIT in terms of peak performance, but these requires a very expensive Enterprise license ($18 per core/month).
- suyash 6y agoI prefer Helidon which also came out with 2.0 release
- sidcool 6y agoMicronaut with Kotlin is much more productive than with Java. A must try