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

On the future of Akka and Lightbend

discuss.lightbend.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: On the future of Akka and Lightbend

#41

Post by __jem »

mwcampbell wrote: post #15
eropple wrote: post #6

Earlier quoted context omitted.

I really enjoyed Play V1. I got some stuff done with V2, but (and I say this as somebody who really liked Scala at the time) I think it absolutely disappeared into the morass and never came back. Ninja is pretty cool. It works well with Kotlin, which is what I reach for today with the JVM, but tbh the easy path today is pretty much Spring Boot so I have some trouble rationalizing using anything else.

> tbh the easy path today is pretty much Spring Boot so I have some trouble rationalizing using anything else. My main reservation with Spring is the heavy dependence on runtime reflection. I'd like to see a Java web framework designed for conventional server-rendered web applications (as opposed to API backends), with authentication, CSRF protection, form validation, and so forth, but without heavy use of runtime re…

The functional Spring APIs in Kotlin allow you to write Spring apps with minimal reflection, and are honestly great, although a bit immature.

Re: On the future of Akka and Lightbend

#42

Post by mountainriver »

nekitamo wrote: post #5

It’s a shame that the Play framework is being abandoned. v1 had a lot of great ideas, but v2 kind of jumped off the cliff into Scala lala-land, where it got lost in the weeds. It never really recovered. If you’re looking for a straightforward Java framework similar to Play v1 check out Ninja: https://www.ninjaframework.org/ For me at least, it hits a sweet spot of enabling fast productive development and maintainable…

You could say that again, play v1 was so simple and productive. Then v2 was pure insanity. I switched from v2 to golang and it felt like I had been punishing myself.

This is what really sold me in Go as a language and I’ve used it liberally since then. Nothing beats just being able to get your head around things.

Re: On the future of Akka and Lightbend

#43

Post by lmm »

bostonsre wrote: post #3

Has anyone had great success with akka? It seems like it could definitely solve some problems elegantly. My team has had trouble with maintainability due to complexity (not clear if that's inherent in akka or just with how we implemented it). It can be somewhat managed by senior engineers but has seemed to be difficult for junior engineers to effectively maintain akka code.

I found that akka (akka-core) was not just bad, but bad enough that it dragged down the reputation of Scala. Most (maybe all) of the time simple future-based code accomplishes the same thing in a much clearer way, and without sacrificing the type safety that's one of the biggest strengths of Scala.

(Some higher-level things under the akka umbrella e.g. akka-http (formerly spray-http) and akka-streams might be useful; not coincidentally they also tend to be more type-safe)

Re: On the future of Akka and Lightbend

#44

Post by lmm »

KptMarchewa wrote: post #39
hardlianotion wrote: post #30

Earlier quoted context omitted.

I agree, it is a mess. I had a little success by simplifying the interop layer. If you can wrap your scala code in simple classes that expose only Java-compatible structure, then you can remove additional complexity of java into scala interop.

I agree - unfortunately I work with 3rd party scala code in this case.

You might be able to write a shim layer in Scala. Java interfaces, Scala classes that implement those interfaces and call the third-party code. That's the nicest way to do it IME.

Re: On the future of Akka and Lightbend

#45

Post by cryptos »

lmm wrote: post #40
mwcampbell wrote: post #15

Earlier quoted context omitted.

> tbh the easy path today is pretty much Spring Boot so I have some trouble rationalizing using anything else. My main reservation with Spring is the heavy dependence on runtime reflection. I'd like to see a Java web framework designed for conventional server-rendered web applications (as opposed to API backends), with authentication, CSRF protection, form validation, and so forth, but without heavy use of runtime re…

I'd highly recommend Wicket. It's quite different from the conventional page-oriented MVC style; it's built around components in a way that leverages the advantages of OO (and I say this as someone who's usually an OO sceptic). HTML is kept very close to the corresponding code but there's no confusing intermixing (e.g. there's no control flow in templates); your component hierarchy corresponds to your data hierarchy…

Oh, no, not Wicket anymore! Something like 12 years ago I was a fan of this framework and thought: "Finally, Swing for the web!". I really don't like the technical approach of Wicket with server-side UI stuff. The framework contradicts the nature of HTTP.

I think it is much cleaner to have a clean separation between server and client frameworks and use, for example, something like Quarkus on the server and Angular on the client and get the best on each side instead of a strange mixture.

Re: On the future of Akka and Lightbend

#46

Post by lmm »

cryptos wrote: post #45
lmm wrote: post #40

Earlier quoted context omitted.

I'd highly recommend Wicket. It's quite different from the conventional page-oriented MVC style; it's built around components in a way that leverages the advantages of OO (and I say this as someone who's usually an OO sceptic). HTML is kept very close to the corresponding code but there's no confusing intermixing (e.g. there's no control flow in templates); your component hierarchy corresponds to your data hierarchy…

Oh, no, not Wicket anymore! Something like 12 years ago I was a fan of this framework and thought: "Finally, Swing for the web!". I really don't like the technical approach of Wicket with server-side UI stuff. The framework contradicts the nature of HTTP. I think it is much cleaner to have a clean separation between server and client frameworks and use, for example, something like Quarkus on the server and Angular on…

Grandparent explicitly asked about "conventional server-rendered web applications (as opposed to API backends)". IMO Wicket does a really good job of doing everything in a clean, consistent way (on the server), so you don't actually have a problem of mixing e.g. server- and client-side form validation (and while a network roundtrip is always going to be slower than local validation, the AJAX integration is very good and makes it a lot lighter than a full page load).

I go back and forth on whether that's a good architecture in principle - a client-side UI calling an API has clear technical advantages, and it's much easier to build first-class applications that can run in JavaScript than it used to be. But certainly if you want that architecture then I think Wicket is still the best way of doing it - indeed I'd say it's the best UI framework I've used anywhere, the model/component split forces you to clearly decouple your data from your UI in a way that's not as thoroughly enforced in e.g. Qt.

Re: On the future of Akka and Lightbend

#47

Post by pjmlp »

zz865 wrote: post #2

Biggest problem I had with Akka was that it was that it worked better with Scala than Java. As Java recently has re-taken most of Scala's momentum its a bit awkward fit.

Lesson number one for all adopters of guest languages on other runtimes, the platform always makes them irrelevant with enough time.

And if the platform dies, it isn't only the main language that dies, everyone else that was seating as guest dies as well.

Re: On the future of Akka and Lightbend

#48

Post by nickkell »

guhidalg wrote: post #27
nickkell wrote: post #24

Earlier quoted context omitted.

You might be thinking of Orleans, but it's not exactly core.

We use Orleans on my team and it has been 99% worth it. The 1% is mostly problems due to bad configuration, easily remedied.

I'm glad to hear that somebody's using it in the wild. It was rejected at my place of work in favour of a BPMN-driven process engine. The thinking was that it's too difficult otherwise for business-people to understand the process.

Does your company write about its experiences?

Re: On the future of Akka and Lightbend

#49

Post by KptMarchewa »

lmm wrote: post #44
KptMarchewa wrote: post #39

Earlier quoted context omitted.

I agree - unfortunately I work with 3rd party scala code in this case.

You might be able to write a shim layer in Scala. Java interfaces, Scala classes that implement those interfaces and call the third-party code. That's the nicest way to do it IME.

I think that's what we plan to do. Still, it introduces some additional problems: we were able to target all the supported Scala versions with one package, now we'll have to do separate ones for 2.11, 2.12, and 2.13.

Re: On the future of Akka and Lightbend

#50

Post by aliswe »

emodendroket wrote: post #25
aliswe wrote: post #21

Earlier quoted context omitted.

Not at all, what I know. well it runs stuff in parallel but i believe thats where the similarities end.

That jogged my memory; what I was thinking of was TPL Dataflow. https://docs.microsoft.com/en-us/dotnet/standard/parallel-pr... > The Task Parallel Library (TPL) provides dataflow components to help increase the robustness of concurrency-enabled applications. These dataflow components are collectively referred to as the TPL Dataflow Library. This dataflow model promotes actor-based programming by providing in-process…

I stand corrected! Thank you!
Post reply on HN