5 ms·

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 yo

by njepa 7y ago

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/42 https://elixirforum.com/t/elixir-static-app-binaries/15335/4...

lelf 7y ago
Let them argue. https://erlang.org/doc/man/escript.html https://erlang.org/doc/man/escript.html
Jtsummers 7y ago
> 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.
- njepa 7y ago
  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.
  - Jtsummers 7y ago
    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.
    - njepa 7y ago
      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.
dnautics 7y ago
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.
- pieix 7y ago
  Do you mind elaborating a bit on your use case for PXE booting?
  - dnautics 7y ago
    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 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.
- njepa 7y ago
  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.

by njepa 7y ago

lelf 7y ago

Let them argue. https://erlang.org/doc/man/escript.html https://erlang.org/doc/man/escript.html

Jtsummers 7y ago

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

njepa 7y ago
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.
- Jtsummers 7y ago
  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.
  - njepa 7y ago
    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.

dnautics 7y ago

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.

pieix 7y ago
Do you mind elaborating a bit on your use case for PXE booting?
- dnautics 7y ago
  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 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.
njepa 7y ago
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.