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

Scala isn't fun anymore

alexn.org

Post reply on HN
Print view View original

331–340 of 394 posts

Re: Scala isn't fun anymore

#331

Post by Shorn »

I wonder what this means for Gatling (the load testing tool)?

Gatling achieves it's relative low-overhead characteristics (compared to a naive approach like JMeter's) by leveraging Akka. Does this mean Akka lawyers will be coming for Gatling customers, or will they go after a slice of Gatling's pie?

Either way, hopefully someone will reproduce the Gatling functionality on the JVM using the Loom programming model. Then we can wait a few years and start the whole dance again.

I don't have a workable solution to propose. I guess I'll just quietly polish my dancing shoes and get ready for the next song.

Re: Scala isn't fun anymore

#332

Post by closeparen »

cube2222 wrote: post #106
valenterry wrote: post #100

Earlier quoted context omitted.

Go fails at the error-handling and resource-safety part. The compiler does not cover you properly.

The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it, as it has very good primitives for handling them. Error handling and deferring for resource closure work just fine. Sure you could say "but the compiler doesn't guarantee it". But that's not much of a point if it's not a real problem in practice.

Not a real problem in practice is just another way of saying rare. But given enough scale and enough time, rare things do happen, and they cost inordinately more programmer effort to chase down. I actually don’t mind if the compiler lets me ship very dumb bugs: those will be auto-rolled back out of production in seconds. It’s the subtle stuff that kills me.

Re: Scala isn't fun anymore

#333

Post by hayd »

the_duke wrote: post #24

The big takeaway here for me is that Akka has changed license to BSL. It's almost crazy to me that such a fundamental and widely used project would switch to such a restrictive license. Some more details here: https://coralogix.com/blog/akka-license-change/ > Lightbend are operating on a “per core” model, with their base license starting at $1995 per core (defined as a thread or vCPU) > The license is only enforced i…

Surely it's the death of Akka inside large enterprises (outside of very niche, already written, applications). How can they justify the enormous departmental cost? If a small team in a large company is creating a new product why on earth would they choose to use Akka?

If you're a small company, likely to never hit $25m ARR, this won't affect you... Or is a ticking time bomb should you ever cross that threshold.

Re: Scala isn't fun anymore

#334

Post by azernik »

cube2222 wrote: post #37
azernik wrote: post #33

Earlier quoted context omitted.

1. Because different projects will want different monads 2. In my experience, having up-conversions between different monads is intuitive low-noise

> Because different projects will want different monads It doesn't look like that to me, based on how the ecosystem currently converges on a single one. I understand there may be some projects that do that, but if the majority converge, then it's still needles complexity. However, I might be wrong. I've been an external observer for a while already.

One example:

Any project using a transactional database will want a monad for actions that occur within a single transaction (see e.g. the Slick `DBIO` monad).

Re: Scala isn't fun anymore

#335

Post by hither_shores »

auggierose wrote: post #216
valenterry wrote: post #206

Earlier quoted context omitted.

Monads are like numbers. You can think they are not a good idea, but they are just a matter of fact and existence. Also, in a 100 years maybe our brains will be completely different. How do you optimize your programming language for that? I don't think you can.

Given that our brains have been the same for a few thousand years, maybe I don't need to optimise for that. Anyway, what we currently have as programming languages are all workarounds. Necessary for now, because how else would we program? But in the end we need to converge programming, math and logic, and once this is done, we will be ready for anything. And we won't need monads as a crutch, forced upon us by a type…

> But in the end we need to converge programming, math and logic, and once this is done, we will be ready for anything. And we won't need monads as a crutch, forced upon us by a type system.

1. Math is filled to the brim with monads, it's just that mathematicians are necessarily specialists, and tend to think about things in terms of their applications to their specialties: they talk about closure operators or algebraic theories or formulas in a formal language, rather than monads as such. But that doesn't mean the monad structure isn't there.

2. Convergence between math and programming (which I agree is desirable) will almost certainly see type theory become more prominent, not less. There is some chance that programmers turn to constraint solvers or ML models for program verification instead, but if they do, mathematicians will not follow.

Re: Scala isn't fun anymore

#336

Post by mumblemumble »

erik_seaberg wrote: post #304
mumblemumble wrote: post #204

Earlier quoted context omitted.

Working on projects that involve big frameworks with deep and ever-shifting dependency trees. So upgrading an existing dependency or taking a new one could often be a risky move. Ground zero for most of them was Guava, which I unfortunately could not avoid due to it being a transitive dependency. And, even more unfortunately, Guava types were being exposed on the direct dependency's public API, so package relocation…

Guava is an outlier. While they do honor semver, they’re already on version 31.1, meaning they have felt they needed to break backward compatibility dozens of times, and it’s likely your dependencies require conflicting versions just by accident of when they were written. I guess it’s because the maintainers live in a monorepo and just force any changes they need?

The other interesting corollary to this is: if your package relies on one like Guava, and it is not bumping its major version number every time it updates the version of Guava it depends on, then your package does not itself honor semver.

Re: Scala isn't fun anymore

#337

Post by erik_seaberg »

mumblemumble wrote: post #336
erik_seaberg wrote: post #304

Earlier quoted context omitted.

Guava is an outlier. While they do honor semver, they’re already on version 31.1, meaning they have felt they needed to break backward compatibility dozens of times, and it’s likely your dependencies require conflicting versions just by accident of when they were written. I guess it’s because the maintainers live in a monorepo and just force any changes they need?

The other interesting corollary to this is: if your package relies on one like Guava, and it is not bumping its major version number every time it updates the version of Guava it depends on, then your package does not itself honor semver.

Much like libraries that run on Scala 2.11 or 2.12, I can imagine a system where I maintain several compatible minor versions (or named forks) of a library, each patched to use a different major version of Guava, and letting a caller solve for exactly which version of everything is compatible with everything else. But the more API churn we face, the harder this is.

Re: Scala isn't fun anymore

#338

Post by clhodapp »

layer8 wrote: post #186
zokier wrote: post #77

Earlier quoted context omitted.

> Basically, a single approach that would solve this, irrespective of the language, would be isolating dependency trees of every library from each other Doesn't solve the problem completely because it is normal that applications need libraries to interoperate; consider case where application is passing objects between two libraries that both use types from a third library.

A major problem is that Maven (and friends) doesn’t distinguish between API dependencies (the API of a library using types from the API of another library) and implementation dependencies (a library depending on another library as an implementation detail). If that distinction were made consistently, implementation dependencies could indeed be separated into a dedicated classloader for each library, and you’d only ha…

I believe that separating interface from implementation doesn't really solve the problem, it just shrinks it. E.g. what if you depend on two libraries that re-export classes from different versions of a third library?

I think that if you truly want to solve the problem, you need to extend the definition of the fully qualified classname to include the notion of a breaking version reference. Kind of like what folks now sometimes do the hard way by encoding it into the package name.

This would make it possible to directly address the two different versions from the same calling source file.

Re: Scala isn't fun anymore

#339

Post by pqyzwbq »

Scala was fun when my company was small.

Later, we need to recruit more people, it became harder and harder. Each need to learn a lot before they can contribute bug fix to product. They need to learn:

  - Scala

  - Akka

  - very basic of sbt (if they need to change more than basic usage, they come to me for that change, as I'm the only one who learned complex sbt syntax in our team currently)

  - Play framework

  - Slick
But now, several years later, Akka's license change really make us to consider switch back to plain Java and Maven one part by another. For the actor model, I really like it, it can simplify Synchronization A lot, we researched Vert.X, which seems can do most of Akka (Although I haven't research whether Akka Clustering, persistent can work similar in Vert.X yet).

Re: Scala isn't fun anymore

#340

Post by lern_too_spel »

valenterry wrote: post #111
geodel wrote: post #103

Earlier quoted context omitted.

Okay, are you going to give reason or is it more of a Thought leader style pronouncement?

Haha, I guess you are right. The reason why it is a mistake is because it is essentially trying to solve the rpc problem once again even though it has been tried many times without success. There just is a difference between making a synchronous call within your own OS thread vs. making such a call against anything else (the filesystem, the network, ...). Because you can assume that a synchronous call either succeeds…

Loom doesn't hide exceptions. Now you just write the exception handling the same way you would write synchronous exception handling.
Post reply on HN