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

41–50 of 155 posts

Re: Ten Years of Erlang

#41

Post by porker »

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…

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

Re: Ten Years of Erlang

#42

Post by pault »

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…

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.

Re: Ten Years of Erlang

#43

Post by macintux »

y4mi wrote: post #37
macintux wrote: post #33

Earlier quoted context omitted.

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…

Using an atom doesn’t require any extra characters in Erlang. Update: just realized you mean the single quotes when you need an arbitrary atom name. Understood.

I definitely wish Erlang had the same macro capability. I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.

Re: Ten Years of Erlang

#44

Post by toast0 »

PasserBy2020 wrote: post #20
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…

Comparing Erlang to C# is a bit unfair. The latter is a general purpose language that can be used to build software on every layer of every platform. The former is a distributed programming DSL (an awesome one granted). There is 0 Erlang-native GUI libraries, there is no documented Erlang pipeline for iOS apps etc.

> There is 0 Erlang-native GUI libraries

Have you seen ex11? [1], it's Erlang native, and at least 0.1 of a GUI library. X11 and Erlang actually go together really well, although a lot of important functionality for a real application is missing; I used this to display images generated by an Erlang application, and it felt a lot nicer to me than using wxWidgets; I added a few bits of functionality to the library while I was in there, and it wasn't that hard to turn the X11 protocol docs into Erlang code for the things I needed.

I imagine if someone had a real need here, it wouldn't be that hard to get it into shape. Caveat: X11 is dying, etc.

[1] The most active fork appears to be here https://github.com/skvamme/ex11 -- it's been somewhat retargeted to mobile, but the examples for desktop should still work as well as they did.

Re: Ten Years of Erlang

#45

Post by peterwwillis »

Riak convinced me that any language pretending that it could magically create better products was full of shit.

Riak is not great. It performs well, but doesn't scale well. It has tons of operational overhead, a lot of bugs (and it didn't help that a slowly disintegrating company left less time to fix those bugs "until next release"), and any changes to the cluster while it's being used heavily leads to instability/unavailability. And many of its features were not implemented great; the SOLR functionality is a pig, for example, and "enterprise" replication is flaky.

On our team, we had a few engineers who could write Erlang, but they slowly moved to other teams, so troubleshooting production issues became a black box of pain. I'm so glad the product we had using it was sunset.

Re: Ten Years of Erlang

#46

Post by thomasfortes »

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.

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.

Re: Ten Years of Erlang

#47

Post by bitwalker »

PasserBy2020 wrote: post #20
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…

Comparing Erlang to C# is a bit unfair. The latter is a general purpose language that can be used to build software on every layer of every platform. The former is a distributed programming DSL (an awesome one granted). There is 0 Erlang-native GUI libraries, there is no documented Erlang pipeline for iOS apps etc.

> The former is a distributed programming DSL (an awesome one granted)

I mean, that's a completely incorrect characterization of Erlang, regardless of how you feel about the comparison to C#.

Erlang is just as much a general purpose language as C#, it is just a different paradigm, i.e. functional programming rather than (mostly) object-oriented.

> There is 0 Erlang-native GUI libraries

This isn't true at all. There is a tight integration with the wxWidgets framework (in fact, one of Erlang's handiest tools is built with it, Observer). Scenic, as mentioned elsewhere in the comments, is for Elixir (perhaps there is an Erlang-native API for it, not sure), but provides a native framework for OpenGL, and a UI paradigm that meshes nicely with processes and supervision.

Of course, Erlang is not perfectly suited for all environments (e.g. iOS apps), but that is true of essentially all general purpose languages - there are some places where they aren't well suited or have flaky support. I wouldn't build an iOS app in C# either, it makes little sense to use anything other than Swift/Obj-C in that environment. Likewise if I'm primarily building Windows-based apps, I would use C# before I would reach for Erlang. But for backend services, infrastructure, networking, etc., it is extremely well suited, and I think the domains that it can provide a compelling solution for will continue to grow (e.g. embedded).

Re: Ten Years of Erlang

#48

Post by loxs »

I was there. Had a full time Erlang job even before the line numbers in stack traces. Later migrated to more enterprise-y languages... and for me, the big missing thing in Erlang is the IDE. And a company (or a big community) that is dedicated to catering to the developers. This was never a thing in Erlang.

Re: Ten Years of Erlang

#49

Post by andrenth »

derefr wrote: post #31
seisvelas wrote: post #27

Earlier quoted context omitted.

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

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.

Re: Ten Years of Erlang

#50

Post by brightball »

1_player wrote: post #35
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…

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

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