This is ultimately not very different than what you would get with any firewall or network rules in any business, and it's an issue shared by most deployments regardless of whether you get containerized or not.
2,658 karma · joined March 17, 2009
While I can argue in favor of tooling being roughly on-par (sometimes better, sometimes worse), I can't really discuss syntax since this is often just related to taste more than anything.
My stronger argument would usually be in favor of the community you end up with. While both communities are starting to merge and grow closer over time, your average Erlang dev is likely to work on infrastructure components, and your average Elixir dev is likely to be working on web apps. I personally like working on the former better, so there's more limited interest for me in terms of most Elixir jobs anyway, even if it's not like no infra work exists in Elixir.
Both can have a great time working on APIs of any kind, and both can reuse most libraries of each other's community, so as I said, this is starting to become a moot point though. I personally have no problem with either.
The effort mentioned here of getting newer people to read the content and/or produce it is something I've done a lot in the past, and one of the ways I've used in on-boarding people as well. We (the co-authors of Adopting Erlang) tend to do it with topics where we don't know everything the other authors know, and provide feedback to each other about things that lack clarity.
I've also taught Erlang stuff in multiple places and started knowing some of the things people find confusing as a kind of pattern, which may get easier to address early on with time.
The thing that can never be done well, though, is predicting the things someone with an entirely different background from yours would find confusing; the context carried by their experience influences the things they understand and the information they extract from a text. Teaching to a functional programmer is different from teaching to a developer who has done OO their entire career. Teaching to someone doing front-end work is going to be a different experience from teaching to someone doing mobile or back-end work. The same may often extend to sociological, economical, or cultural factors as well.
All of this means that each teaching experience has new surprises as well and you can't just cover them by thinking very hard. Frequent reviews, both technical and from editors can help, though, along with your own experience when teaching.
I've got:
Learn You Some Erlang, which has been published with No Starch Press. This was my first one, which I assume is the one you're talking about. Lots of drawings, something I no longer really have the time and energy for these days compared to early in my career. It's the big basics of Erlang. A bit dated now, particularly since the ecosystem evolved around it, but all the basics are still well-covered I think.
Erlang in Anger, only available as a self-published short e-book available for free, meant to teach people to operate Erlang in production.
Property-Based Testing with PropEr, Erlang, and Elixir; my latest published one (with Pragmatic programmers), covering property-based testing both with Erlang and Elixir at once. Pragprog have let me keep the initial website online, which only covered Erlang.
And Adopting Erlang is the latest one. We're still writing it (this time I'm a co-author rather than the sole author), and there's no physical or ISBN'd copy of it available at this point in time.
All of them have to be labours of love, just because it's a lot of work and effort, and at this point in my career, my name's well-known within the Erlang and Elixir communities, so you could say there are diminishing returns. I still enjoy writing though, it's just harder to make time.
There is a large overlap with Elixir stuff, mostly at a higher level; whatever covers OTP, handling supervision, releases, docker image practices, approaches to testing, production practices, etc. will very likely be useful to Elixir users.
But the lower-level details like handling dependencies, build tool commands, test framework specifics, the code snippets and samples, and so on are all going to be Erlang-specific.
I use both languages frequently for work and there's far more in common between them than there are differences. If that's not your cup of tea and Elixir is really all you're after, you can look for Ben Marx's Adopting Elixir (https://pragprog.com/book/tvmelixir/adopting-elixir) book. We are not affiliated with it and don't aim to cover the same content (we just have similar titles), but it's a good option that goes Elixir-first.
It's an ongoing effort to gather all the resources that will help you use Erlang in a business. The booksite is divided in three sections focusing particularly on Erlang/OTP’s higher level concepts in the current open source ecosystem, how to use it in production (while setting up a pipeline for continuous development and delivery), and how to build a team when you’re starting from scratch.
We're working mostly linearly in each section, but they're not all progressing at the same pace. We have nothing yet on "building a team" although our outlines are all planned; the "hard things to get right" chapter was supposed to come in later but we saw enough questions about these topics to rush it out.
We might release things from each section as they are ready and we see fit. In the meanwhile, we're always appreciating feedback and people checking in to see what's new in terms of content.
This “but we can’t fix it all alone, it’s a global issue” thinking mode has to go. All contributions are important in reducing the speed of warming, whether your neighbour participates or not.
Interestingly, the longer you wait, the more you can expect people with more extreme agendas to pop up around the globe because they will see the point in coercion to save the world. Early investment at a massive scale is worth it.
I'm not really disappointed Erlang didn't catch on more. As I said in the post, I wanted to take a bit of time to reflect over most of that decade, the ladder of ideas, and things that changed.
That’s why I downvoted you. It’s not because of your opinion, it’s because it’s probably not in the right thread.
It’s become near-official for OSS Erlang work and the OTP team has moved the repo under their GitHub organisation (https://github.com/erlang/rebar3)
Erlang.mk tends to be the other option otherwise.
All these bigger projects tend to have a bit weirder idiomatic build setups because they had to haphazardly reimplement bits of (at the time) yet non-existing build systems by hand.
What companies frequently do instead is offer "pay N months, get N+1 months", such as getting 13 months for a yearly subscription. Spotify just never felt like modifying their offer for local laws, but I've nevertheless been a premium member for years now.
Also do note that the text is heavily copying The Little Prince, to the extent that all characters are also malicious caricatures of adults, with only one of them actually being perceived positively, so I tried to play to the original.
The handler and filter structure with both global and per-handler filters is fairly clever as a way to turn these things on and off easily, and the module and level checks are done the earliest since they can allow to eliminate the most amounts of logs the cheapest way possible.
Then there's also ways to prevent just printing huge terms out. That's what parameters like `term_depth` in many handlers do (I believe it's just `depth` in the default handlers). They limit how deep you go into outputting some data. So even if you have some very large strings or deeply nested structure, they can get elided when they reach a certain threshold.
I'm sure there are plenty of tricky traps that regulars have learned to work around and "just know how to use it without breaking it"; I have a suspicion a lot of unsatisfied people are those who come with different expectations of what the tool should do and how it should behave.
In these cases, they'll have a frustrating experience. I'd be interested to learn what it is so that we can make the whole thing better.
But this means that the VM is entirely allowed to interrupt you halfway through a call to sorting a list obtained through a message. No qualms about it. You reach you function call limit, you're phased out and put back in the queue.
The three ways I know about to hog a scheduler for yourself are:
- write C code that misbehaves and stalls the scheduler (there is now a dirty scheduler if you want the code to run there)
- hardcode a sequence of arithmetic operations (which are not subject to reduction counts) that can take a very long time to execute -- something that never happens naturally in code
- set your process to the max priority and do busy looping while the rest of the system is at a lower priority. Your process will now have a higher priority and prevent others from running
That's about what you can do. It requires a kind of explicit effort to do and is very easy to spot from afar.
Sounds like it would even be better in the long run.