[derefr]

Re: those infrastructure components written in Erlang not attracting Erlang users in any permanent way—it’s not so much that they have more users than contributors, but rather just the bare fact of them being infrastructure components. A black-box infrastructure component can’t be a “killer app” for a language.

Rails is a killer-app for Ruby because it’s a framework; a developer who uses Rails in their project is inherently a Ruby developer. People learned Ruby to use Rails.

But you don’t need to write a single line of Erlang to use CouchDB or Riak or Ejabberd. They’re self-contained. (And, in fact, scriptable in not-Erlang languages; CouchDB for example spawns and manages a JavaScript engine to run its “design documents” on.)

Thus, these infra components becoming popular doesn’t cause there to be any more Erlang programmers than there were before.

In that sense, I would say that Erlang has never had a true “killer app” yet. (Outside of a few specialized domains, like telecom and fintech, where the OTP platform itself is Erlang’s killer app.)

And even in the places where Erlang itself is a “killer app”, it’s also not so much a viral thing that the whole industry gets excited about; rather, Erlang is more of a “secret sauce.” Nobody’s learning Erlang in their basement because their friend told them it’d be the next big thing in their industry.

How does anyone learn Erlang, then? Well, usually, engineers are forced to learn Erlang at one job (where the system architect there decided on it); they get to liking it; and then, when they later become a system architect themselves in another job, and choose a stack, they choose Erlang, thus forcing a new wave of engineers to learn it.

[brightball]

Agreed. This is actually why I think the killer apps for the BEAM are 2 Elixir based ones.

Nerves, which is already being heavily used for embedded systems and only getting stronger thanks to the likes of Scenic.

And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks.

The combination of those two will likely fuel things long term.

[1_player]

> Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks.

LiveView still needs more work to be really ergonomic, wouldn't work for all use cases, but I'm personally holding my breath here in excitement to adopt it in my Elixir projects.

Still, I find it ironic that the next server side web technology leap, after the famous Rails demo referenced in the article, comes from another Ruby-inspired language.

[ashton314]

I've been using LiveView for a small project. It's pretty bumpy right now, but man it's going to be a game-changer for me.

[brightball]

Elixir isn't really Ruby inspired though. The only thing about it that really derives from Ruby is the focus on developer productivity.

[mtarnovan]

The syntax is heavily inspired by Ruby.

[sjtgraham]

Having written Elixir every day for the last 5 or 6 years, and Ruby for the 10 years before that I don't think it is.

[mtarnovan]

I have also written Elixir in the last years, after 10 years of Ruby, and the syntactic similarities are obvious to me. Luckily you don't have to take my word for it, as the author of Elixir said multiple times that, while Elixir is not about syntax, its syntax was inspired by Ruby.

[brightball]

That is what I was getting at. Having people who came from the Ruby world and some very mild surface level bits is all that's there.

The issue I have with the statement is that it pulls all of the negative connotations that some people have with Ruby onto Elixir...and Elixir is not at all like Ruby.

[etxm]

What, the words def and do?

[0_gravitas]

Jose himself has cited ruby for syntax inspiration multiple times, because he himself started in the ruby community

[burlesona]

It’s hard to say it’s not inspired by Ruby when Jose and many of the core contributors came from the Ruby world.

It’s not at all the same thing as Ruby on Beam though - it’s a very different language, but it does borrow a lot of good ideas from the Ruby ecosystem while improving on them in many ways.

[woeye]

Isn't Blazor in ASP.NET basically what LiveView is in Phoenix?

https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=as...

[strmpnk]

Not quite. Elixir code isn't set to the client as Blazor does with .Net IL. LiveView leverages a small runtime loaded onto the client which uses websockets to load deltas.

While it sounds expensive at first, the template engine has been extended to support delta tracking and the process model that Elixir inherits fits well for a heavily interactive system with thousands or millions of users. The end result is that it's a very lightweight client setup and outside of using the template system properly, there are no gotchas with learning which code runs where.

[PhilippGille]

There's two distinct Blazor development models: Client side Blazor uses Mono (running as WebAssembly) to run C# code on the client side, but server side Blazor only updates the DOM via SignalR (like WebSockets), which works like LiveView.

I didn't use Blazor yet, but that's what I understand from the documentation.

[strmpnk]

Thanks for the correction and clarification. The early parts of the docs didn’t make this distinction clear so I assumed the WASM half was required.

[Nelkins]

I don't think that's correct. Blazor supports both client-side (what you are describing, sending IL to the client and running it as an app) and server-side (what LiveView is doing). More details here: https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...

[ljm]

I was going to go as far as saying that elixir itself is the ‘killer app’. It doesn’t make you an Erlang developer but it is also arguable that knowing Rails isn’t necessarily sufficient to fully grok Ruby. You’ll still make some headway though.

I’ve interviewed plenty of people who cut their teeth on Rails and fall apart as soon as you present them, say, Sinatra. Or a gem that provides an API client. Once it comes to writing non-Rails code (with all the helpers and the magic), it’s as good as learning a new language that happens to look exactly the same.

[porker]

> And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks.

LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy.

And unless you replicate to many locations, or can deploy it to edge compute nodes (no idea) then this will always be a problem compared to 'true' client-side development.

I want it to work but I don't see how it can beat the laws of physics.

[nickjj]

> LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy.

If you built a traditional SPA, aren't you still making loads of calls to your server?

I don't see how LiveView would be more laggy than that. In both cases you're making network calls from the user's machine, to your server, getting a response from the server and then rendering output on the client when it's received.

Of course you can cheat and do optimistic rendering on the client (like outputting what you wrote instantly in some DOM element instead of waiting for a response and validating it after the fact) but I believe that enhancement could be done with both techs.

The only place where LiveView falls short is a true offline / fully client side app, but those are such a rare breed and way out of the norm for a typical web app. In 20 years of web dev as a freelancer, I've been asked 0 times to build an offline / client side JS app.

[porker]

> If you built a traditional SPA, aren't you still making loads of calls to your server?

For data loading, yes. But here's a few random thoughts:

* I can pre-emptively load data in a SPA (think: 3 screens-worth of a datagrid) and keep fetching in advance, so the user rarely feels the lag.

* Much of my investigation has been around adaptive forms, wizards, validation and keeping logic in a single place. Having to define models and logic once, rather than client-side and server-side would save so much time.

My testing suggested that client-side validation still gave better results, because it was instant. Moving forward & back through a wizard was better if client-side rather than each screen rendered server-side.

I experimented early May so am a little hazy on details (and can't find which PIM I put my notes in, sigh) and look forward to seeing other people's experiments. Particularly when not run on their local machine.

[nickjj]

> My testing suggested that client-side validation still gave better results, because it was instant.

In some cases yes, but I don't think you can get away with client side validation for a lot of things because they depend on the state of your database to return the correct result.

For example, how would you validate an email or username on the client when the availability of the name depends on you making a database call to see if a user exists already? You have to make a network call, get the result and then update your validation errors on the client based on that server side result.

But for validating something like a phone number or twitter handle, sure, client side works all the way but I don't think having even 200ms of delay for that validation is going to make for a bad user experience. 200ms is a lot too. That's about what it takes to ping a server in Tokyo from New York.

Your other points are valid tho. I guess we'll see where LiveView ends up going.

[rikkus]

LiveView was always going to have this limitation. Its design makes it suitable for low latency links - such as local network.

It’s not going to fail to ‘work’ because of this. It just has a niche and isn’t a general purpose web framework.

I’m looking forward to building some admin tools with it, reducing the complexity required when having to deal with server and client separately.

[porker]

> LiveView was always going to have this limitation. Its design makes it suitable for low latency links - such as local network. [...] I’m looking forward to building some admin tools with it

All our tools are now hosted in the cloud - we don't run any servers on the local network. With a 20-30ms RTT perhaps it will feel smooth - or the micro-delays will be noticeable.

[markkanof]

That's a fair point, but it does seem like a solvable problem. There are multiple companies offering gaming services where the game is running on a remote system. I haven't tried any of these services, but from what I hear they are very useable for casual games, but still have some work to do for FPS type games where milliseconds count. That would indicate to me that getting a web UI to work with this type of setup should be very possible with geographically distributed servers.

[pault]

Honest question: if liveView does catch on in a big way, what will the front end developers do? I can't see the huge FED community going back to writing HTML and CSS templates. I wonder if that resistance will hurt adoption.

[peterkelly]

They'll have to start thinking of themselves as "developers", not just "frontend developers". Boxing yourself into one specific type of software development is a bad idea given how the industry changes so rapidly and dramatically. Flexibility is key to long term success.

[thomasfortes]

LiveView is great for writing form validations or simple admin stuff. Even though the examples show that you can do 60fps animations, it is not the intended use case, you're not going to write anything that needs small latency or that needs a ton of processing using LiveView, front end developers are fine.

[imtringued]

Even in very simple CRUD projects I have to write a few hundred lines of Javascript to enhance the UI. Stuff like: if you check this box 4 more options appear. Or here is an autocomplete field/dropdown that autofills in 4 other form fields. A lot of basic stuff that cannot be done with raw HTML alone. I can see how something like LiveView would replace the need for mucking around with jQuery when your project doesn't need a big and heavy SPA framework.

[Qwertystop]

Hiding things with unchecked checkboxes, at least, can be done entirely in simple CSS.

  .optional {
      display: none;
  }
  input:checked ~ .optional {
      display: inherit;
  }

[1_player]

I've recently adopted two libraries for my server-side backend app:

1. unpoly to handle common JS behaviours (such as show this div when this checkbox is selected)

2. Web components to handle more complex pieces of UI while maintaining compatibility with LiveView: rendering a functional jQuery carousel via LiveView/Websockets is much harder than just pushing a <carousel> element through the socket. Admittedly I haven't tested if the DOM diffing library LiveView uses plays nice with web components.

[seisvelas]

I don't think this counts, but I imagine a significant portion of people learning today learn it because they are Elixir programmers.

[derefr]

It actually might. You can write Elixir for years without learning Erlang syntax, but if you’re a perfectionist, you’re gonna notice bugs in your Erlang deps just as much as in your Elixir deps, and you’re gonna want to submit PRs for them, and that leads you to learning Erlang.

Also, IMHO, if you want to have a solid foundation when learning Elixir, it’s simpler to learn Erlang/OTP as a cohesive whole (from e.g. ferd’s Learn You Some Erlang book) and then “chase it” with an Elixir book; rather than trying to understand OTP through the lens of how it’s exposed in Elixir. Everyone in the elixir-lang Slack that asks how to get started learning Elixir, I tell them to learn Erlang first. So “being a simpler jumping-off point to Elixir knowledge” is also kind of a killer app.

I would guess that this is only true in cases where there are killer apps for a secondary language on a runtime, but no killer apps for the primary language. Like, I wouldn’t say that Clojure is a killer app for Java. But then, is that because Java is already popular? Or is that because Clojure developers don’t necessarily end up knowing Java as well as Elixir developers end up knowing Erlang?

[andrenth]

There's a lot in the Erlang stdlib that is not available in a wrapped form from Elixir's. As of now I think you need to know at least a bit of Erlang (e.g. to understand the stdlib docs) to be able to use Elixir more productively.

I'm not sure if Elixir developers plan on providing complete wrappers for Erlang's stdlib in the future. This is in fact one criticism I have of the language, because even for simple things like serialization you have to drop to Erlang and call :erlang.term_to_binary(), which feels a bit second-class.

I really like the language otherwise though.

[klibertp]

> you have to drop to Erlang and call :erlang.term_to_binary(), which feels a bit second-class.

Well, to be honest, :erlang module has many functions, many of which have literally nothing in common with each other. That's because that module is imported by default in Erlang - it's like `__builtins__` in Python. Exposing it as `Erlang.term_to_binary/1` module/wrapper wouldn't really fit well with the rest of the Elixir stdlib, which is (commendably) very neatly organized, with each module doing just what its name suggests.

On the other hand, wrapping just `erlang:term_to_binary/1` and `erlang:binary_to_term/1` in a `Serializer` module would be probably ok, but then there are tens of such modules you'd be pressed to implement for `:erlang` alone, and it gets worse with a rather extensive Erlang stdlib and OTP apps.

One of the Elixir selling points was (and probably is) the simplest possible FFI to (and back from) other BEAM languages (like Erlang or LFE). Calling an Erlang function is exactly the same operation as calling Elixir one - literally, the only difference is that, syntactically, most Elixir functions live in CapitalizedModules. That's it - there's no runtime overhead, no difference in handling arities, arguments, guards, exceptions or return values. The feeling of second-classiness is definitely there - the argument order and naming conventions (for args and functions both) differ, and the Erlang/OTP docs (used to - not sure it's still the case) look less than appealing in comparison with Elixir. But, realistically, Erlang's stdlib is a result of 30 years of accretion of tools and it's not small by any means. Wrapping entirety of it would take many years at least and it would consume a lot of developers' time, possibly hindering the development of the language itself. Elixir is still a young language, without a very large following and secure position in the industry - it's dangerous to divide your forces and pursue to many goals at once in a situation like that.

To summarize: in my opinion, the feeling of second-classiness is not a serious enough problem to invest resources in making it go away, at least at this point. While they may look less than pretty, Erlang/OTP docs are very well written and the functionalities tend to be rock solid. The stdlib is... not the prettiest in terms of organization, owing to decades of evolution, but with the FFI as trivial as it is, it's more than usable from Elixir. I think that was the original plan: the stdlib of Elixir was intentionally kept small and very clean, which was supposed to be Elixir's appeal, but it's only possible if reaching for the functionality missing from stdlib is simple. Just a hunch of mine, we'd need to ask Jose to know for sure :)

[andrenth]

I agree, but my point wasn't about the erlang module specifically. Maybe :ets would have been a better example.

At one point I suggested in the forums that, inspired by how Elixir understands [foo: bar] as equivalent to [{:foo, bar}], maybe it could allow foo:bar() as equivalent to :foo.bar(). That would make the syntax exactly like Erlang's, which would be pretty nice to signal "I'm calling an Erlang function here".

I still think it's a good idea, but it wasn't met with a lot of enthusiasm :)

[klibertp]

> I still think it's a good idea

Hm, it definitely looks like it. What arguments against it were raised?