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

31–40 of 50 posts

Re: On the future of Akka and Lightbend

#31

Post by coreyoconnor »

drewhk wrote: post #11
coreyoconnor wrote: post #8

Earlier quoted context omitted.

I've had good success with akka at multiple companies. At Protenus the core ETL is based on akka streams. Which has worked great. No notable issues. Tho we don't run in clustered mode. At glngn we didn't use akka streams (outside of akka http) but did use event sourced, persistent entities powered by akka typed in clustered mode. Deployed to k8s. Which definitely took effort to set up nicely and enable smooth deploym…

I used to work on the Akka Team, mostly on streams, but I was doing different stuff elsewhere in the last years, not touching Akka much. To be honest, I am quite emotionally distanced nowadays from Akka... That said, it still feels good reading success stories from people who used it. Thanks, you made my day!

You're welcome! I think akka has been making great strides in polishing the rough edges. (Along with the rest of the Scala ecosystem TBH). Unfortunately that doesn't seem to generate the hype I'd argue akka deserves shrug

Re: On the future of Akka and Lightbend

#32

Post by yumraj »

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…

I can concur. Many years ago, I had used Play v1 to solo develop a reasonably functioning website, in part time. But then came Play v2, and for some reason it never clicked for me.

Haven't looked at Ninja. Currently I'm looking at Phoenix as my go-to framework for side projects.

Re: On the future of Akka and Lightbend

#33

Post by yumraj »

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…

> 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 reflection for wiring up objects.

Add Phoenix style LiveView and we'll have a winner..

Re: On the future of Akka and Lightbend

#34

Post by daniel-grigg »

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…

Take a look into micronaut too, I’ve used it for a couple things and it’s pretty full featured even though it’s geared towards micro services. Very easy to migrate to from spring too.

Re: On the future of Akka and Lightbend

#35

Post by NicoJuicy »

emodendroket wrote: post #13
lvice wrote: post #10

Earlier quoted context omitted.

I've now worked for about six months on a Akka.NET codebase. I find it a very elegant high-performance framework that gives you a lot of flexibility in how you want to solve a wide range problems. This being said, I've been burned already several times by the complexity and its raw power. The codebase tends to become verbose and difficult to navigate (everything being an ActorRef). Debugging is difficult and coding i…

Doesn't .NET now have a very similar core library anyway?

Also https://getakka.net/ , but haven't used it myself

Re: On the future of Akka and Lightbend

#36

Post by helsinki »

angelzen wrote: post #20
AnotherGoodName wrote: post #12

Earlier quoted context omitted.

No. In fact the Play Framework 1.x (before it went to Akka) was simple perfection. Like Ruby on Rails but with so many improvements. Super simple but fast, performant and not really lacking anything a web framework needs (coordinating background periodic jobs between servers required setting a config file but it wasn't a big deal). In play framework 1 a new API method could be the following >@Check("administrator") /…

Not familiar with Akka of Play2, but you articulated the point of overcomplicating the task of returning a simple response to a simple request via a litany of rarely useful concepts quite clearly. OTOH, I wish popular web frameworks had a clearly documented 'no magic' option that doesn't critically depend on global methods and decorators. Again, not familiar with Play1 other than your example, but I recently did spen…

Yeah, I agree, despite being an advanced Python programmer and a fan of the language. Writing a production grade web app requires some proprietary boilerplate black magic that is quite difficult to get right at first, but once you get it right, it’s something you carry along with you across projects.

Declaring, managing, and providing a proper test fixture for the ‘app context’ in a Flask app can be rather hideous. Having said that, despite the poor aesthetics and contours, that black magic is incredibly reliable once you get it right.

Re: On the future of Akka and Lightbend

#37

Post by johnnycerberus »

nodejs_rulez_1 wrote: post #19
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.

Same story with .NET - less and less reasons for F# to exist with each new version of C#. Only F# doesn't even bring any new useful frameworks to the table.

Sad to hear that, F# is an excellent programming language. Scala has matured a lot, there is no "better-Java" anymore, that's the reality, there are three ecosystems today, Akka, Typelevel and ZIO. The competition between these is also seen in the social media and other mediums. There's also Clojure, which in my opinion is still an uncharted territory.

Re: On the future of Akka and Lightbend

#38

Post by dxxvi »

debarshri wrote: post #17
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'm not sure if you have heard about java spark [1]. Back in the day, around 2-3 years ago we used to implemented all our java service in java spark. [1] https://sparkjava.com

Its last release was in Oct 2020. I think io.javalin:javalin is a bit more up-to-date.

Re: On the future of Akka and Lightbend

#39

Post by KptMarchewa »

hardlianotion wrote: post #30
KptMarchewa wrote: post #9

Earlier quoted context omitted.

Using anything build in Scala from Java is abysmal. Have fun with no default parameters, creating Seq$.MODULE$ everywhere etc. I'm not from US, so I've never have seen so much dollars anywhere.

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.

Re: On the future of Akka and Lightbend

#40

Post by lmm »

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…

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 and ultimately your DOM hierarchy.
Post reply on HN