Live data from Hacker News

The BEAM Has Spoiled Me

gvaughn.github.io

61–70 of 88 posts

Re: The BEAM Has Spoiled Me

#61
post #49

I've written a decent amount of Elixir for a personal project, and have come to a few conclusions. For a start, it's very different. That will become self evident if you try to learn either Erlang or Elixir, when coming from a language like Python/C++/etc (and though Elixir looks a lot like Ruby, it's still more like Erlang, tbh). So that can be classed as a negative. Secondly, fault tolerance in Erlang/Elixir/OTP is…

>I recently debugged a production issue by opening a console connected to a running system, and calling the functions I suspected to be failing to see what they were returning directly. Not sure if any other language has that facility. Clojure has it.

It does get a little more involved in Erlang/Elixir though. It has a built in GUI program called 'Observer' that can even print out a real-time visualisation of your object and process tree. Amongst many other things.

Re: The BEAM Has Spoiled Me

#62
post #4

Earlier quoted context omitted.

The killer feature for me was the documentation. I got thrown into an Elixir application that uses Ecto and Phoenix and literally everything I ever had to do was documented and explained in Hexdocs.

Seriously, the Elixir documentation should be considered the gold standard. Almost everything is documented with exactly what kind of situations the library/module/function should be used for, combined with illustrative examples showing how it should be used.

Coming from Erlang to Elixir - I find Elixir docs lacking in both coverage and terseness.

Re: The BEAM Has Spoiled Me

#63
post #32

Earlier quoted context omitted.

I just couldn’t get past ecto! It never seemed to “click” for me. Maybe I need to go back and learn it more in-depth, it sounds like it’ll be fantastic once I get the hang of it.

It's definitely not an orm, as it was stolen from c# linq. Imo this is actually much better than an orm because it really hits home that the data in memory are stale as soon as you receive them because database transactions are explicit, and not hidden behind getters and setters. ORMs can get you into trouble because they try really hard to hide the problem of distributed state and sources of truth.

Coming from (the much-maligned) ActiveRecord, I wasn't really impressed.

It has this cute macro-based syntax, and that seems to inform even the "functional" API as well. Yet when you I wanted to do something just a bit more advanced like joining on an association whose name I don't know in advance (or, say, want to parameterize the function with), I had to resort to writing a macro myself and then eval-ing it an runtime.

Re: The BEAM Has Spoiled Me

#64
post #49

I've written a decent amount of Elixir for a personal project, and have come to a few conclusions. For a start, it's very different. That will become self evident if you try to learn either Erlang or Elixir, when coming from a language like Python/C++/etc (and though Elixir looks a lot like Ruby, it's still more like Erlang, tbh). So that can be classed as a negative. Secondly, fault tolerance in Erlang/Elixir/OTP is…

>I recently debugged a production issue by opening a console connected to a running system, and calling the functions I suspected to be failing to see what they were returning directly. Not sure if any other language has that facility. Clojure has it.

Ruby does, too (DRb). Though one would need to set it up on on the production server to use it. That means writing some boilerplate.

Re: The BEAM Has Spoiled Me

#65
100% in agreement.

One nit: OTP instead of BEAM. The supervised processes and modules as application is due to the OTP framework. What that means is that, it's possible to have it in other programming languages as well. Or not, and managed the application with some OS process manager.

Re: The BEAM Has Spoiled Me

#66

Earlier quoted context omitted.

I think the author's use of the microservices is unfortunate and confusing. With the BEAM, it is easy to create fully independent process trees. The architecture enables it. In fact, you can pull in dependencies and add them as "OTP applications" (which is in essence a fully independent process tree, doing its thing.) The BEAM lends itself very well to structuring parts of your application as independently supervised…

What's the practical difference between a "real" microservice and an independent process tree potentially running on a different machine? Erlang/Elixir really doesn't have any trouble being distributed across multiple nodes, you just get a lot more latency on your messages.

You're correct, there's barely any difference, from a structural point of view.

I was mainly taking issue with the author's comparison of processes with microservices:

> You can consider each process a logical microservice

But as you said, the process trees can be considered (micro)services, but I wouldn't say that each process represents a microservice. It's just not accurate in my opinion.

Re: The BEAM Has Spoiled Me

#67
post #62

Earlier quoted context omitted.

Seriously, the Elixir documentation should be considered the gold standard. Almost everything is documented with exactly what kind of situations the library/module/function should be used for, combined with illustrative examples showing how it should be used.

Coming from Erlang to Elixir - I find Elixir docs lacking in both coverage and terseness.

I could agree. Coming to Erlang from Elixir, I truly appreciate the simplicity and small size of the Erlang language. Making it possible to write exhaustive documentation. In fact, in Joe's book he defers a lot to the online docs/manual for in-depth treatment of a lot of topics.

Re: The BEAM Has Spoiled Me

#68
post #4

Earlier quoted context omitted.

The killer feature for me was the documentation. I got thrown into an Elixir application that uses Ecto and Phoenix and literally everything I ever had to do was documented and explained in Hexdocs.

Seriously, the Elixir documentation should be considered the gold standard. Almost everything is documented with exactly what kind of situations the library/module/function should be used for, combined with illustrative examples showing how it should be used.

IMHO many function docs could have more examples.

Especially for a dynamic language which uses tuples/maps for a lot of arguments.

Re: The BEAM Has Spoiled Me

#69

I still write Elixir only, and don't really leverage BEAM (not yet) but the sheer performance of the system amazes me. Phoenix is very largely scalable, and makes some really clever decisions in terms of architecture unlike Rails/Django. The learning curve has been a little steep and there is a paradigm shift but I've encountered situations where it really ended up helping me navigate through code with precision and…

all languages I know have async tests

Re: The BEAM Has Spoiled Me

#70
post #62

Earlier quoted context omitted.

Seriously, the Elixir documentation should be considered the gold standard. Almost everything is documented with exactly what kind of situations the library/module/function should be used for, combined with illustrative examples showing how it should be used.

Coming from Erlang to Elixir - I find Elixir docs lacking in both coverage and terseness.

While you might be right, I dislike the style of Erlang docs.
Post reply on HN