mrjoelkemp

Not really. Working on a 2+ year, large, monolithic phoenix liveview app at Spotify. VS Code runs dialyzer on file save, which shows type mismatches. I also run dialyzer on pre-commit for a sweeping check. Ideally, we'd have the same optional typing flexibility with a compile time check, but it seems like a marginal gain over the current setup.

Google does provide elixir clients for most of their products: https://github.com/googleapis/elixir-google-api

I have https://elixirdaily.link (an elixir/beam news aggregator running) on the smallest, free Gigalixir VM just fine. Does a ton of memory intensive work and doesn't go OOM (had to be careful with # outbound http connections).

1.5 years in and Phoenix Liveview is perfect for internal webapps. Have personally seen development take half as much time with half as much people compared to traditional stacks. You don't need super rich interactions nor offline mode for internal apps, plus they might be harder to prio against customer-facing feature work. Elixir and LiveView are really powerful tools to have in your toolbelt. Even if you can't use Elixir, look at Hotwire or Livewire for a similar programming model. You won't get zero-setup fault tolerant components (nested LiveViews can crash and not take the entire page with it, and retry side effects automatically), but you'll still cut out the JS side of the development.

And we haven't even spoken about an app-aware repl that lets you manipulate/inspect your running app (even in prod). There are so many game-changing layers in this stack. It's hard to beat once you've explored it.

Very happy customer here.

For completeness, you should check out Elixir and Phoenix (channels and presence) for the server. Easy websockets, isolated player processes, non-blocking VM, plus deep introspection for debugging issues. https://youtu.be/JvBT4XBdoUE. We see more and more indie games being built with Phoenix LiveView.

Actor model with Elixir/Erlang and the BEAM VM.

I find building a simple game (like tictactoe) in Phoenix Liveview to be a good learning project. You can layer on multiplayer using Phoenix pubsub once you have a working one player version. You can also then layer on structs, typespecs, or any other idiomatic features of the language that you need practice in.

In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations). If concurrency isn't an issue, then the massive amount of libraries can help you a lot.

In high-traffic environments, that ignorance punishes you. I've always felt Java and the JVM are of the mindset that you need a Ph.D. to even understand how it works or how to configure it, and if you can't get it, then you're just a bad programmer.

You need to know if you're blocking threads, if there's memory contention, and if libraries you pull in are using the forkjoin common pool (which you're likely using as a default threadpool). And when something blows up, finding the reason (even for any of the above issues) is really tough. You can use flight recorder, heap dumps and gc logs all day, but good luck navigating it all unless you're a genius. I've seen too many devs end up shrugging and hoping the issues are transient.

Even figuring out proper threadpool usage isn't straightforward. Look at the number of concurrency abstractions just to model concurrency in your system: https://www.youtube.com/watch?v=yhguOt863nw. It's ridiculous.

Lots of large tech companies "seem" to "make it work." But if my experience is at all similar, they're just relying on a handful of Ph.D.'s to hold the hands of the rest of the company when it comes to troubleshooting.

Part of the reason I fell in love with Elixir/Erlang and the BEAM is that it provides a simple (actor) concurrency model (with a single concurrency primitive, a process) and guardrails (time-slice scheduling) to prevent libraries from shooting you in the foot. OTP's observer makes finding bottlenecks a breeze.

For the web, taming concurrency feels way more important than any cpu-crunching perf gains the JVM can give you. I'm too stupid for the JVM; I'll stick to tools that take away numerous categories of complexity and get me closer to mastering my system.

I found that my JS experience made a lot of Elixir feel very familiar (lambdas, destructuring, default args, string interpolation, optional typing).

And compared to Node, the BEAM is a godsend in terms of its non-blocking process scheduling and fault isolation. A single uncaught exception in Node and kaboom. Plus, if you do anything cpu intensive with Node, your app stalls. In the BEAM, infinite loops are even fine due to time slice scheduling.

A talk in ElixirConf this year showed that the pipe operator in Elixir is just a macro. A Code BEAM V conf Q&A with Jose had a (playful, trolling) question about implementing right handed assigns and Jose said that you can just write a macro if you want it. That all reinforces that the core lang doesn't need to change really; it's extensible enough to let you do whatever you want on top. Pretty cool.

Thanks Kevin.

This has been fixed. Thanks for trying linklink.

Cheers for mentioning the closure compiler; I'll look into it. I haven't noticed much literature on its use in current build systems; I guess r.js gets all the fame due to its easier api.

Interesting. Something else that I should have included as a con for 3 is that Backbone would then be a requirement for the model-based solution. It sacrifices flexibility for smaller projects that need services.

Thanks Jeremy. You're right and the point is obvious in hindsight.

I think the end of your comment should be shared with others; for those that are eager to try, but not fully aware of the consequences of client-side rendered apps.

I'd like to include your statement somewhere in the post to further emphasize the point; I hope that's okay. Thanks!

You're right about not mentioning why I didn't use it. Thanks for bringing this up.

I had the rare opportunity to re-imagine the profile app in the context of another app that was being built from scratch and went with the server-rendered approach.

The phantomjs approach is totally valid. Thanks for reading!

Macbook air. Beautiful tools create beautiful products.