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

Ten Years of Erlang

ferd.ca

Post reply on HN
Print view View original

51–60 of 155 posts

Re: Ten Years of Erlang

#51

Post by markkanof »

porker wrote: post #41
brightball wrote: post #29

Earlier quoted context omitted.

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…

> 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 r…

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.

Re: Ten Years of Erlang

#52

Post by arendtio »

I have never written a single line of Erlang, but I run my own ejabberd. However, looking at the package build scripts and build instruction, I have the impression that compiling a project like ejabberd can be complicated.

Does someone know if this is an inherent Erlang problem or just due to some weird project setup in this case?

Re: Ten Years of Erlang

#53

Post by rikkus »

porker wrote: post #41
brightball wrote: post #29

Earlier quoted context omitted.

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…

> 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 r…

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.

Re: Ten Years of Erlang

#54

Post by dpeck »

ngrilly wrote: post #23
Jedi72 wrote: post #15

Earlier quoted context omitted.

I work with Ruby and Elixir daily and Elixir is 10x faster. Phoenix recently added functionality to display response times in microseconds, partially as a showcase for its good performance. I dont doubt you can get more performance in C++ or something but its still lighting compared to Ruby.

What Phoenix did to improve display response times that much?

For one, they leveraged the speed of iolists on the BEAM very well.

https://www.bignerdranch.com/blog/elixir-and-io-lists-part-1...

Re: Ten Years of Erlang

#55

Post by mononcqc »

arendtio wrote: post #52

I have never written a single line of Erlang, but I run my own ejabberd. However, looking at the package build scripts and build instruction, I have the impression that compiling a project like ejabberd can be complicated. Does someone know if this is an inherent Erlang problem or just due to some weird project setup in this case?

Ejabberd runs with a lot of legacy. Essentially the first build tool that could pull deps in Erlang dates from 2007-2009, and it took another few years before more modern tools came to be in what their current form is.

All these bigger projects tend to have a bit weirder idiomatic build setups because they had to haphazardly reimplement bits of (at the time) yet non-existing build systems by hand.

Re: Ten Years of Erlang

#56

Post by saberience »

sergiotapia wrote: post #10

Here's to another 10 years of Erlang/Elixir. The programming stack for the boring software developer that wants to clock out at 5 sharp. It's fantastic I tell ya. I have been blessed with opportunities to work with Elixir fulltime and it's hands down the best experience I've had. Compared to C#, Rails, Nodejs, it's miles ahead. (Although C# with dotnet is coming up fast and _crazy_ compared to what it was 9 years ago…

I think you should add to this comment "in my opinion."

Because in my opinion C# is miles ahead of Erlang. If I want to create an application, back-end, front-end, running on a wide variety of platforms, Mac, Linux, PC, IOS, etc, I would use C# 1000 times over versus Erlang.

The tools available, documentation, huge amount of libraries and support mean that developer efficiency in C# land is light-years ahead of Erlang. I could make a website + backend + IOS/Android app with all shared code while using tons of pre-existing OSS frameworks / packages and get it all up and running and prod/enterprise ready in no time at all and have it ready for enterprise load and scalability. Try that with Erlang!

Re: Ten Years of Erlang

#57

Post by PhilippGille »

strmpnk wrote: post #38
woeye wrote: post #34

Earlier quoted context omitted.

Isn't Blazor in ASP.NET basically what LiveView is in Phoenix? https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=as...

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…

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.

Re: Ten Years of Erlang

#58

Post by peterkelly »

pault wrote: post #42
brightball wrote: post #29

Earlier quoted context omitted.

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…

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.

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.

Re: Ten Years of Erlang

#59

Post by Nelkins »

strmpnk wrote: post #38
woeye wrote: post #34

Earlier quoted context omitted.

Isn't Blazor in ASP.NET basically what LiveView is in Phoenix? https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=as...

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…

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-...

Re: Ten Years of Erlang

#60

Post by hartator »

Jedi72 wrote: post #15
alberth wrote: post #7

Fantastic article; it paints a great picture of the journey taken & accomplished achieved. My personal take is that the next major milestone for Erlang/Elixir will be a significantly more performance BEAM. Be it JIT or reworked Hipe. Elixir (& Phoenix) brought a ton of interest from the Ruby community. The only remaining aspect that would keep a Ruby developer using Ruby is the perf vs Erlang. Today, for many raw per…

I work with Ruby and Elixir daily and Elixir is 10x faster. Phoenix recently added functionality to display response times in microseconds, partially as a showcase for its good performance. I dont doubt you can get more performance in C++ or something but its still lighting compared to Ruby.

Phoenix is faster than Rails, however Ruby is faster than Elixir when doing CPU intensive tasks. Like parsing text.
Post reply on HN