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

31–40 of 155 posts

Re: Ten Years of Erlang

#31

Post by derefr »

seisvelas wrote: post #27
derefr wrote: post #22

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

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

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?

Re: Ten Years of Erlang

#32

Post by davidw »

Good observations.

'Getting' OTP, and especially how to structure an application the right way is definitely tough, because there's not a lot out there like it if you come from the world of C or scripting languages. It's not just code organization, but thinking about how to structure all the processes so that things fail in a 'good' way, and you have everything talking in the right way.

A big thanks to Fred for his book, and the many hours he has spent helping people on the mailing list, IRC and elsewhere.

I miss my time working with Erlang. I think it's still an indicator of an environment willing to try new things, but like he writes, you have to be wary of the places that are 'serial early adopters' too; I've encountered a few of those in my Erlang career.

Re: Ten Years of Erlang

#33

Post by macintux »

y4mi wrote: post #30
macintux wrote: post #13

Earlier quoted context omitted.

Disagree with “cleaner”.

Disagree with "disagree" ...see where that leads us? Please actually voice reasons how it's not cleaner, as it's most definitely less verbose, And having less clutter is generally seen as cleaner

It’s more verbose when defining functions, calling anonymous functions, and referencing atoms.

Calling functions with and without parens makes for a less clean syntax. Less consistency (plus mandates the dot notation for calling anonymous functions).

Re: Ten Years of Erlang

#34

Post by woeye »

brightball wrote: post #29
derefr wrote: post #22

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

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…

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

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

Re: Ten Years of Erlang

#35

Post by 1_player »

brightball wrote: post #29
derefr wrote: post #22

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

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…

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

Re: Ten Years of Erlang

#36

Post by walterstucco »

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?

Compiled views

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

Re: Ten Years of Erlang

#37

Post by y4mi »

macintux wrote: post #33
y4mi wrote: post #30

Earlier quoted context omitted.

Disagree with "disagree" ...see where that leads us? Please actually voice reasons how it's not cleaner, as it's most definitely less verbose, And having less clutter is generally seen as cleaner

It’s more verbose when defining functions, calling anonymous functions, and referencing atoms. Calling functions with and without parens makes for a less clean syntax. Less consistency (plus mandates the dot notation for calling anonymous functions).

> It’s more verbose when defining functions, calling anonymous functions, and referencing atoms.

and we're finally finding out how both opinions are correct

when people say that elixir code is cleaner, they're normally talking about the significantly reduced amount of code they have to write because of the macros. its not specifically about how they're defining a function or calling them anonymously

while i cant say that i agree with atom reference, (its 1 char in elixir, two in erlang), you're definitely correct about that annoying idea they've had about dropping parenthesis on functions without parameters... that was just misguided i think.

Re: Ten Years of Erlang

#38

Post by strmpnk »

woeye wrote: post #34
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…

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's a very lightweight client setup and outside of using the template system properly, there are no gotchas with learning which code runs where.

Re: Ten Years of Erlang

#39

Post by jjnoakes »

macintux wrote: post #13
brightball wrote: post #8

Earlier quoted context omitted.

Cleaner syntax, macros and a whole lot of developer productivity focused tooling.

Disagree with “cleaner”.

It'd be nice if dissenting opinions came with elaboration to continue the discussion instead of shut it down.

Re: Ten Years of Erlang

#40

Post by dmix »

animesh wrote: post #26

This is how the page looked when Erlang posts caused HN to become slow. http://www.waybackhn.com/?date=2009-03-11

That was my favourite moment in HN history. I believe it was even pg who started the whole “post erlang articles so HN appears boring” thing.

Edit: yes of course, he mentioned it in the text post in your link but as a joke: https://news.ycombinator.com/item?id=512145

Post reply on HN