Comment by marceldegraaf

Comment by marceldegraaf 6 hours ago

11 replies

It's funny that you mention this, and it made me take some time to appreciate I've been working with Elixir full-time for almost 10 years now, and the entire experience has been so... stable.

There's been little drama, the language is relatively stable, the community has always been there when you need them but aren't too pushy and flashy. It all feels mature and – in the best possible way – boring, and that is awesome.

jacquesm 3 hours ago

Being boring is the hallmark of technology that it is worth to invest a career into.

  • [removed] 2 hours ago
    [deleted]
noosphr 5 hours ago

I've moved from Linux to OpenBSD for this reason.

It's all so boring it's wonderful.

  • christophilus 3 hours ago

    I like OpenBSD, but I like Docker and Steam too much to daily-drive it.

[removed] 6 hours ago
[deleted]
zwnow 4 hours ago

For me it took a tremendous amount of work to somewhat understand the OTP stuff though. Its one of those languages where I can never be confident about my implementations, and thankfully it has features to check whether you have stale processes or whatever. A language I am humbled by whenever I use it.

  • toast0 3 minutes ago

    Here's a trick to confidence in a BEAM system. If you get good at hot loading, you significantly reduce the cost of deployment, and you don't need as much pre-push confidence. You can do things like "I think this works, and if it crashes, I'll revert or fix forward right away" that just aren't a good fit for a more common deployment pattern where you build the software, then build a container, then start new instances, then move traffic, etc.

    Of course, there are some changes that you need confidence in before you push, but for lots of things, a bit crashy as an intermediate step is acceptable.

    As for understanding the OTP stuff, I think you have to be willing to look at their code. Most of it fits into the 'as simple as possible' mold, although there's some places where the use case is complex and it shows in the code, or performance needs trumped simplicity.

    There's also a lot of implicitness for interaction between processes. That takes a bit of getting used to, but I try to just mentally model each process in isolation: what does it do when it receives a message, does that make sense, does it need to change; and not worry about the sender at that time. Typically, when every process is individually correct, the whole system is correct; of course, if that always worked, distributed systems would be very boring and they're not.

  • asa400 2 hours ago

    Thank you for this post and I'll add a note for people who are seeing this and are maybe discouraged about learning Erlang/OTP/Elixir.

    I generally agree with you that learning Erlang stuff can be daunting.

    I will say that many things worth doing are not easy! Erlang and the whole OTP way of thinking is tough to learn in part because it is genuinely different enough from everything else that is out there that one's odds of being familiar with its conceptual underpinnings are low.

    If you have trouble learning Erlang (and OTP specifically) it's not because you're dumb, it's because Erlang is different.

    Learning Erlang is not like learning any other dynamic language you've learned. Learning Erlang is closer to learning a bespoke operating system designed to build reliable low-latency long-running systems. It's a larger conceptual lift than going from one dynamic OOP language to another dynamic OOP language.

  • simoncion 13 minutes ago

    It also took me quite a bit of time to understand OTP. In fact, I had to have a project that actually required what OTP offered to really get it.

    Two things that definitely helped me understand were reading the somewhat-dated-but-still-useful material on the topic in Learn You Some Erlang, as well as reading through the "OTP Design Principles" section of the Erlang System Documentation.

  • giraffe_lady 2 hours ago

    I love saying this but OTP is a really roughneck standard library. They just added shit to it as they needed it without apparently putting too much consideration into the organization, naming, or conventions.

    It makes it very powerful but very disorienting and experience gained with one part of it often does not really prepare you for other parts. Usually each specific tool was created by someone who used it immediately, so it's all reliable in its way. But there is a lot of redundancy and odd gaps.

    Elixir's almost extreme attention to naming, organization, and consistent convention is almost as far as you can get from this approach too. It's fun to have them in the same ecosystem and see that there are actually pros and cons to each approach.