[jurgenkesker]

This year I also switched from Ruby to Kotlin on my hobby/light commercial backends. I just can't stand the way Ruby is not statically typed, and the resulting insecurity around if everything is actually doing what it should do. Kotlin gives me joy, and performance is actually better (trading memory requirements ofcourse, but that's not a big problem anymore). I still love Ruby, but only use it for simple scripts now.

[blandflakes]

This has sort of been my issue with Elixir. I've been doing Scala for years but I think Phoenix is really the best web story at the moment for how I want to be building web apps. And while I believe that the benefits of static typing somewhat decrease in the web arena, it's still frustrating to have to manage type relationships in my head.

I'm hopeful that the incoming type system work makes me happier there, though I'd also prefer a nicer editor experience than is currently available.

[dmux]

> I believe that the benefits of static typing somewhat decrease in the web arena

I’ve seen this sentiment expressed numerous times and have never found it to be true in my own work (e-comm), do you mind mentioning _what_ type of domain your web apps are in?

Edit: or if not domain, what do you mean by “web arena”

[blandflakes]

I find that if most of my logic is relatively gluey, then the fields in my API boundaries are heavily optional, at which point types add a lot less than they do when most of my logic is more internal, and in cases where what I'm doing is just getting some JSON and doing something with it, I'd rather just have the dynamic shape of the JSON in a lot of cases than have to declare an entire schema/codec.

We have so much boilerplate and tooling to share request/response types between services and it's just... heavy. The same feeling arises when I'm sitting here trying to share a shape between a web app and the backend service, where FINALLY I just want the types to get out of my way instead of having to go through all this ceremony.

And my domain is relatively precise and typeable - streaming video with a deterministic set of parameters.

Generally though I'm more likely to agree with the value of types than to undersell them; I just can't find a ways to describe the above experiences such that they reflect that perspective.

I think it's not that I don't want types, it's that I want simple types that play slightly more dynamically - maps of <string, heterogeneous values>, for example, and reasonable means of interacting with them (like various "safe traversal" operators that some languages have added).

[tasuki]

Have you tried Gleam? It's a simple, strongly typed functional language running on the Erlang VM.

(I also come from Scala and so far, like what I see with Gleam.)

[blandflakes]

Yes; my only critique is that Elixir is already a niche. You could argue it two ways:

1. A niche within a niche is a bad idea 2. If you're going niche, going further niche hardly makes a difference

[duckydude20]

what advantage/disadvantages does Scala/jvm have over Elixir/otp/beam?

i am learning Elixir and liking the concepts. i am coming from kotlin/jvm and i like kotlin, apart from kotlin-coroutines. planning to migration all threading code to virtual threads. but biggest problem is threadlocal.

[blandflakes]

I think they're pretty different, but there are some places where you can compare them:

1. Hiring and job market - the JVM is simply more employable

2. Ecosystem - in general you can expect the JVM to have library support for most things you're going to need.

3. Typing - if you like static types, you're probably going to miss that in Elixir/Erlang. They're working on a gradual type system for Elixir that looks quite pragmatic, so I'm excited to see how that works out.

The Elixir side of things has some real advantages, though. Runtimes like the JVM are slowly adding threading paradigms that start to look like how the beam works, if you squint enough. Naturally, Elixir already has that, and already has technologies that work very well with it. Virtual threads on the JVM are a smart effort that will take a long time to be complete and will always have to take backwards-compatibility into account, especially if you're in Java itself.

Phoenix is also IMO a best-in-class web framework. I don't think it's universally applicable, but if any JVM language had something like Phoenix I doubt I'd be considering Elixir nearly as strongly (due to my affection for types). So while the JVM ecosystem is broader, it's not uniformly stronger.

I also think that "domain" is much broader for JVM stuff. The web technologies there feel pretty baroque rather than empowering, but you can still do web on the JVM, and Kotlin or Scala in particular IMO serve better for systems where the bulk of the code is internal business logic. I think that even if I adopted Elixir entirely, I'd probably retain some "second language" for deeper systems.

[RomanPushkin]

> the JVM is simply more employable

How do you know it? Today you have to re-assess what you've learnt in the past. If you think JVM is "simply more employable" and haven't tested the waters in last 1-2 years, chances are you're just wrong.

The feeling I have: more simpler the tech is (and JVM/Ruby/other CRUD), the highest salary cuts you're getting. And you're actually less employable.

It is that counter-intuitive, because it's one person with a coding agent vs a team in the past.

[blandflakes]

This is patronizing. I'm a professional and am constantly hiring and being hired. The JVM has far more jobs and engineers willing to do those jobs, _and_ in terms of your own employment, a better salary market, and this is not only self-evident, but reinforced by even a cursory investigation into the trends. In fact, your claim is so outrageous (that I'm wrong and that somehow Elixir has more to offer on either side of the hiring bar) that I think the onus is on you to somehow prove it.