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

Ask HN: Is Erlang an albatross to Elixir adoption?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 109 posts

Re: Ask HN: Is Erlang an albatross to Elixir adoption?

#51

Post by handsaway »

myth_drannon wrote: post #4

It's the same way that the Java/JVM prevents Clojure being picked up more. To figure out Clojure's errors you need to be familiar with Java/JVM (most of time). Elm is a great example of a language that doesn't suffer from being written in Haskell, you basically completely unaware of it and not required to dip your toes into Haskell's ecosystem.

Well to be fair Elm runs on a completely different platform, it's just the compiler is written in Haskell. "Leveraging the Haskell ecosystem" isn't part of Elm's value prop.

Re: Ask HN: Is Erlang an albatross to Elixir adoption?

#52

Post by derefr »

alberth wrote: post #42
derefr wrote: post #37

Earlier quoted context omitted.

> While BeamASM (JIT) is very exciting, the reality is that the Erlang runtime has only speed up by ~25% over the last decade Yes... because perf hasn't really been a focus for Erlang until about 1.5 years ago. Various (usually academic) third parties have contributed big performance-enhancing patchsets (the earlier JIT; Dialyzer and then HiPE based on Dialyzer analysis; etc.) but these have then languished, with att…

> perf hasn't really been a focus for Erlang until about 1.5 years ago. The core maintainers have been working on JIT/perf for 10-years. You can see Lukas own described 10-year journey documented below. https://drive.google.com/file/d/1hHCs90kDX_wJ9AbLzGNu5bZKdIV...

I've had this conversation on HN three times now, and I'm misunderstood each time I say it. It's getting a bit frustrating.

I'm not saying that the Erlang maintainers haven't been trying to work on perf. I'm saying that their approach to working on perf has, until recently, been to focus on building on top of large blobs of relatively-opaque third-party code — either in-tree code, like HiPE; or library code, like LLVM. These approaches haven't been maintainable, and have eventually been dropped.

The difference in the last 1.5 years is that the perf enhancement this time is purely due to optimizations to the emulator and runtime — and improvements to the way the compiler works enabling better runtime insight into the code — with no big blobs of opaque code being relied upon. There's nothing extra to maintain; no big experimental perf-hack to enable with a feature flag. It's just the runtime itself being improved.

With previous attempts, the perf improvement was a sigmoid sawtooth: perf increased, levelled off, and then dropped back down. This time, the perf improvement is a linear ratchet function.

---

My other point, is that until fairly recently, most of Erlang's biggest users were "enterprise" customers with embedded use-cases, whose #1 concern was stability — they didn't care about perf-enhancing new language features, because they weren't about to rewrite their working+tested+certified code just to get better perf. They were only interested in "transparent" perf enhancements.

More recently, though, large non-"enterprise" corporate users of the Erlang runtime, like WhatsApp and Discord, have been migrating their work developing third-party perf-enhancing feature modules upstream as language features, because they are interested in rewriting code to increase perf — as long as that rewritten code is also just as maintainable (if not moreso.)

Re: Ask HN: Is Erlang an albatross to Elixir adoption?

#53

Post by pera »

> The notion that to learn a language you also need to learn a second one is not great

It depends on how far you're trying to go maybe? You could argue that, for any given programming language, there is always a point where you will have to learn some intermediate representation language to achieve certain tasks; I personally don't think this is unique to Elixir.

Re: Ask HN: Is Erlang an albatross to Elixir adoption?

#54

Post by adamors »

ch4s3 wrote: post #25
adamors wrote: post #3

I feel like this is an issue with all superset languages or however you want to call them and should be taken into account by anyone learning one of these. You can't really learn Elixir without also learning _some_ Erlang, you can't really learn TypeScript without learning some Javascript, you can't really learn Clojure without picking up some Java. The platform/base language is abstracted away to some extent but not…

> You can't really learn Elixir without also learning _some_ Erlang I'd argue that you end up learning a good bit about OTP, Erlang's standard library, and some stuff about the VM but very little Erlang in practice. Although if you know about BEAM, and some of the standard library there isn't much "Erlang" to learn after that. It doesn't seem to leak into Elixir the way Java does in Clojure, and the surface area of E…

If you use these superset languages day-to-day you will end up interfacing with the base/platform language at some point.

Just recently I had to figure out why the Elixir Kafka library didn't support something and I ended up using the wrapped Erlang library at the end. Without some Erlang knowledge I would have been completely lost.

Re: Ask HN: Is Erlang an albatross to Elixir adoption?

#55

Post by SOLAR_FIELDS »

_acco wrote: post #39
chrismccord wrote: post #29

As the creator of Phoenix, I've never written an Erlang program fwiw. That said, I frequent the Erlang docs and most seasoned Elixir developers will do the same because the standard library is a wealth of features, and the documentation while not 2022 polished, remains a remarkable resource. > I don't know what a solution is, but perhaps a concerted effort to create a documentation and library ecosystem that never li…

Highlighting an important distinction Chris makes: there's a huge difference between needing to learn to read/understand the basic syntax of a language and needing to learn to write it. When writing Elixir, yes, you'll be exposed to Erlang syntax/docs sooner or later. But you're not writing Erlang, so you never need to learn how to: - Compile more than a couple lines of Erlang into a function - Create an Erlang modul…

I can read C++ pretty well, I know how to build, compile, and run C++, but I probably couldn't write very good C++. I think it's like reading a book about how a machine gun is used in action and constructing one vs. given a machine gun with no hands-on training and trying to use it myself.

Re: Ask HN: Is Erlang an albatross to Elixir adoption?

#56

Post by alberth »

derefr wrote: post #52
alberth wrote: post #42

Earlier quoted context omitted.

> perf hasn't really been a focus for Erlang until about 1.5 years ago. The core maintainers have been working on JIT/perf for 10-years. You can see Lukas own described 10-year journey documented below. https://drive.google.com/file/d/1hHCs90kDX_wJ9AbLzGNu5bZKdIV...

I've had this conversation on HN three times now, and I'm misunderstood each time I say it. It's getting a bit frustrating. I'm not saying that the Erlang maintainers haven't been trying to work on perf. I'm saying that their approach to working on perf has, until recently, been to focus on building on top of large blobs of relatively-opaque third-party code — either in-tree code, like HiPE; or library code, like LLV…

> I'm saying that their approach to working on perf has, until recently, been to focus on building on top of large blobs

Totally agree.

Off topic: I really love Erlang/Elixir - but I'm beginning to losing hope in being able to see a path where it can 3x improve performance. There has be a lot of people for a very long time been hoping this major improvement will come "soon". I'm unfortunately just not seeing it happening or a path to it ever happening. I hope I'm wrong.

Re: Ask HN: Is Erlang an albatross to Elixir adoption?

#57

Post by derefr »

alberth wrote: post #50
derefr wrote: post #46

Earlier quoted context omitted.

> One of the more elegant ways to do such interop is to isolate your number crunching code to a separate process group Or, if you want to maximize perf inside some hot section of code (say, a game-engine renderer) while also retaining Erlang semantics for how it interacts with the rest of the system, you can write your code as a "threaded NIF" — a native thread (in C or Rust or whatever) that sends messages back over…

What concerns me is I see people talk about using NIFs like no big deal. BUT, they come at the cost of potentially bringing down the entire Erlang runtime. People use Erlang, more times than not, because they want a fail-safe runtime ... so recommending NIFs shouldn't be taken lightly. Just my 2 cents.

> People use Erlang, more times than not, because they want a fail-safe runtime

I disagree; 99% of people running Erlang runtimes are running them in use-cases where it'd be fine if any individual node crashed and got restarted.

(E.g. running a Phoenix web-app as a K8s replicated Deployment, with no durable internal state, only the mesh-replicated Phoenix.Presence data that can be recovered from peers after node restart; where, for users, even having a long-running websocket is just an optimization over long-polling, and so it's no skin off the clients' backs if said connection gets dropped once in a blue moon, requiring them to reconnect to another node in the cluster.)

I agree that you should only be using NIFs after you've exhausted the other options — "C nodes" being my favorite of those, personally.

But downplaying NIFs ignores a whole other segment of use-cases, where you're not adding native code to Erlang, but rather you're starting with a "core" of native code (e.g. an HFT trading engine), and then building an app by wrapping that native code in Erlang, where the code presents itself to Erlang as a NIF.

If efficient shared-address-space high-throughput interaction between your native "core" and your higher-level "glue" is the whole point, then Erlang+NIFs is a pretty great way to get a bunch of advantages without losing much. It's a lot better than what you get from the alternatives — where those alternatives are "loading the native core as an FFI module in some other dynamic language runtime."

Re: Ask HN: Is Erlang an albatross to Elixir adoption?

#58

Post by ch4s3 »

adamors wrote: post #54
ch4s3 wrote: post #25

Earlier quoted context omitted.

> You can't really learn Elixir without also learning _some_ Erlang I'd argue that you end up learning a good bit about OTP, Erlang's standard library, and some stuff about the VM but very little Erlang in practice. Although if you know about BEAM, and some of the standard library there isn't much "Erlang" to learn after that. It doesn't seem to leak into Elixir the way Java does in Clojure, and the surface area of E…

If you use these superset languages day-to-day you will end up interfacing with the base/platform language at some point. Just recently I had to figure out why the Elixir Kafka library didn't support something and I ended up using the wrapped Erlang library at the end. Without some Erlang knowledge I would have been completely lost.

I don’t exactly disagree, but what I mean is that in learning Elixir you’ll learn about the BEAM and by the time you need to peek under the hood, it’s just syntax that’s different mostly.

Re: Ask HN: Is Erlang an albatross to Elixir adoption?

#59

Post by jacquesm »

dimgl wrote: post #36
jacquesm wrote: post #15

Earlier quoted context omitted.

Typescript requires an intermediate step though. We had the Typescript vs JS debate when starting out with pianojacq.com and I was pretty strongly committed to doing it in plain JS and not to have any tooling dependencies or build step. Which I think is the one thing that makes JS at least moderately interesting: that it is a language that in theory does not require any tooling beyond the browser. Of course, the day…

I agree that just JavaScript is okay for simple applications. In fact I didn't use TypeScript for a really long time because getting the tooling going can be cumbersome at first. TypeScript shines with complex webapps. Having the typing prevents a whole class of issues and helps with refactoring quite a bit.

Yes, agreed. And small projects tend to grow to much larger projects over time so it may well make sense to choose Typescript even if your project is still small.

Re: Ask HN: Is Erlang an albatross to Elixir adoption?

#60

Post by dogleash »

> "cool, learn python, but oh, you also should brush up on cobol while you are at it, you know." It's just bizarre.

It's more like learning python and also c. Depending on the library, python can smell a lot like the c underneath.

Sometimes you'd never know a python library is written in c, sometimes it's a manageable leak like the socket module, and sometimes it's opencv. Write enough python and you'll find C library wrappers so atrocious and/or badly documented that you just whip out ctypes and hack out a replacement wrapper yourself.

The reason you're hearing the answer you preemptively dismissed in the OP is that the distance between erlang and elixer is thin, much smaller than python and c. That's sorta the bed that elixir made itself.

If people believe elixir is held back by erlang, and that elixir should do it's best to hide erlang, then the the albatross is probably elixir around erlang's neck. Mindshare and time spent contributing (e.g. to documentation) should be further split between two very similar ecosystems? For what? Because it doesn't look enough like Ruby?

Post reply on HN