Hacker News Reader

Comment by MarcusE1W | Hacker News Reader

What sometimes puzzels me is that ERLANG is described as quirky and difficult to read.

I find that once you learned a bit about it for just one day or so it is a very simple to write language that just flows on the screen from your thoughts.

So it might look quirky, but really not for long and then it's quite fun to use. And that's before looking at the ease how you use concurrency, process restart, hot swap..

View on HN

Yeah, this phenomenon definitely exists. Probably just the unfamiliar syntax, — somehow enough to make people see Erlang as “complicated”. While in reality Erlang is one of the most simple and consistent languages out there.

While functional programming is imo easier to understand in general, you can really get screwed with spaghetti when passing modular lambdas around. Take a look at the OTP tftp server code. It's a nightmare.

I think the application of the language is quirkier than the language. There is a fairly high barrier to doing something ideal. In languages like python or c you can pretty much just write a few lines and you got something representative of what you can do. In this thread for example people are arguing whether you should make command line programs even in elixir: https://elixirforum.com/t/elixir-static-app-binaries/15335/4...

Let them argue.

https://erlang.org/doc/man/escript.html

> There is a fairly high barrier to doing something ideal.

Can you elaborate on what you mean here? I don't quite understand your message.

I mean that if you want to do something with e.g. python it is pretty easy to access what is good about python. You can make a script, make it "pythonic", use some modules and package it. And that sort represents a good, useful, python program.

With Erlang it is generally a lot harder to access what it is good at. Not only do you have to learn the language, which is a bit different, but things like how to configure and distribute the virtual machine, how the concepts of otp works and maybe even things like dialyzer.

I realize that I don't have to learn all that, but still the distance from writing a simple program to what is the unique features is still a lot longer. At least that is my impressions.

So my follow up question then:

How would you do distributed programming in Python? Could you do it quickly and easily in a Pythonic way without needing to learn those same kinds of things as Erlang?

I feel that you may be close to an apples-and-oranges comparison there. Erlang is several things: language, distributed system, and almost-OS.

If you want to do distributed systems in any language, it'll be a steep learning curve. I cut my teeth on that in college with OpenMPI (paired with OpenMP for local parallelism) in C and Fortran. It wasn't too hard, but someoene else had set up the server to actually distribute the MPI jobs across all the nodes, I had no idea how to do that setup. With Erlang, if someone else has already set up the nodes for you it's not really any harder than MPI to handle distribution of work across those nodes. Once you start trying to configure and administer the distributed system, yes it'll be somewhat complex. Same thing with the various Java application servers I used a decade or so ago.

The language itself, however, permits programming in an Erlangic way without needing to involve OTP or multiple nodes or dialyzer. Processes and message passing are very accessible and easy to use, permitting a way of structuring programs that's very Erlangic. OTP permits a more consistent and uniform way that's in line with what other systems do and might expect (if you were to pass your modules off to them to be put into a larger system), but it's not needed for writing an Erlangic program. Pattern matching and recursion are other quintessential features of Erlang and encourage a particular program design, also accessible without reaching for those other tools.

It is an apples and oranges comparison because they are. Python exposes it's feature fairly readily in a relatively similar context. If I can open "Erlang Studio", plot my nodes, write my recursive functions and run them to some effect on some "Erlang Application Server" then Erlang would be as well. But as far as I know I can't. And I think that makes the application of Erlang somewhat inaccessible.

One could of course "just" use Erlang the language, but that use case has a lot more competition.

I started moving my team to elixir mix tasks and it really feels like a sensible shell script. 1) our scripts must live in our repo, so changes are tracked with the evolution of our software, 2) many of these scripts are deployment and resource management, so they share elixir code anyways. 3) debugging and testing are easier than shell, or even python. 4) one of the things I'm doing is PXE booting, and we have functional DHCP, tftp, and http services that are very easily instrumentable can run the lifetime of the script instead of turning then on and off using some fragile config file twiddling and sudo systemctl dhcpcd incantation or whatever.

Do you mind elaborating a bit on your use case for PXE booting?

sorry, can't give too many details on the specific, but the PXE booting spec requires that you start up a:

- DHCP server that responds to broadcasts on 0.0.0.0

- TFTP server that responds to requests for the bootstrap image

- HTTP server (for most linux distros, anyways) that fetches more boot resources that are big enough that TFTP is probably not the best protocol (UDP doesn't have packet transmission guarantees).

I use a dead-simple, transient erlang HTTP server that my buddy wrote: https://github.com/StoneCypher/htstub

And hand-rolled custom DHCP and TFTP servers (existing options are not exactly what I need) that basically operate like htstub.

This is all tied into a mix task, so you start the mix task, then walk over to your target machine (or IPMI), reboot it, and then it's provisioned from scratch, reproducibly, with two-touches. Since everything is done in a single language, if something is wrong in your provisioning scheme, it's really easy to figure out what went wrong and deploy a fix.

That does seem interesting. I could definitely see that as something I would want to use for the functionality rather than the "underlying feature". The story around this is pretty weak in most language ecosystems from what I have seen.

Reply on news.ycombinator.com