5 ms·
Disckaimer: I have never used Elixir in any serious capacity, but I have done a good chunk of Erlang. Concurrency in Erlang sort of frustrates me...not because
by tombert 3y ago
Disckaimer: I have never used Elixir in any serious capacity, but I have done a good chunk of Erlang.
Concurrency in Erlang sort of frustrates me...not because it's bad, but because when I use it I start getting pissed at how annoying concurrency is in nearly every other language. So much of distributed systems tooling in 2023 is basically just there to port over Erlang constructs to more mainstream languages.
Obviously you can get a working distributed system by gluing together caches and queues and busses and RPC, but Erlang gives you all that out of the box, and it all works.
- brigadier132 3y agoCan you give some examples?
- fredrikholm 3y agoIf you want to dig into some code: The Elixir 'Getting started'[0] guide has you building a concurrent, distributed KV store using nothing but the basics of OTP (effectively the std of BEAM). 0. https://elixir-lang.org/getting-started/introduction.html https://elixir-lang.org/getting-started/introduction.html
- macintux 3y agoI fell in love with Erlang pretty quickly, and it’s hard for me to enjoy writing other languages. Simple concise syntax, pattern matching, immutability, error handling without branches all over the place, concurrency… it’s hard to walk away from that.
- ralphc 3y agoHave you tried Elixir? So many blogs etc. talk about coming to Elixir from Ruby, which I don't understand, little similarity beyond def...do...end. Elixir uses the same VM with a different, some including myself would say better syntax. Do you still prefer Erlang syntax?
- macintux 3y agoI dislike Elixir’s syntax for two reasons: it seems unnecessarily verbose, and it’s too much like Ruby/Python. When I see Erlang syntax, it helps me think in Erlang. Anyway, I haven’t given Elixir a fair chance, but it’s hard to get past my knee-jerk dislike of all the extra verbiage. I’d rather use LFE if I wanted an alternative syntax with more powerful macros.
- fndex 3y agoThis is coming from someone who likes Elixir. Not much for its distributed systems features, but mostly because of the language design. I keep hearing everyone talk about how Erlang/Elixir gives everything out of the box and you don't need to worry about Queues, RPC or whatever... But in reality, people don't really recommend using Distributed Erlang that much, on most Elixir gigs I worked, they didn't use Distributed Elixir at all, just plain old Kubernetes, Kafka, Redis and GRPC.
- andsoitis 3y ago> they didn't use Distributed Elixir at all, just plain old Kubernetes, Kafka, Redis and GRPC There must be a good rationale for that decision. Do you know what it is?
- sarchertech 3y agoThere may or may not be “good” rationale. Could just be that most people using elixir are coming from other languages/ecosystems where all of that is normal. Also in my experience, most of the time, the infrastructure team doesn’t know anything about elixir.
- sodapopcan 3y agoThere's a good article about BEAM + k8s by José Valim [0] [0] https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchestration-on-the-large-and-the-small https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest... You could certainly get away without some of the other stuff but, as another comment has mentioned, it requires some infra know-how. Like, you can't "just" use ETS as a Redis replacement without setting it up in a way that its data won't get blown away during a blue-green deploy.
- weatherlight 3y agoWell, in big orgs, that adopt Elixir/Erlang, along with other technologies with poor concurrency stories, those other ecosystems still need Kubernetes, Kafka, Redis and GRPC, to get by. elixir isn't going to make ruby or python apps magically concurrent. So that make sense. However, in orgs that are primarily Elixir shops, I don't see a lot of Kafka or gRPC. (Redis is just useful, its more than just a queue and K8s and Elixir/Erlang compliment each other, btw.)
- westoque 3y agoregarding concurrency, language plays an important role and pretty much dictates how code is written which is i believe where it has most of the frustration. in erlang it’s in a functional style, in javascript it’s in an asynchronous style. what i’ve come to realize is that it’s still better and more maintainable to think synchronously and have the core of the tech handle concurrency, for example golang with it’s goroutines or multi process in ruby/python. admittedly it’s not as concurrent/distributed as erlang but should be easier to work with.
- weatherlight 3y agothats the thing though, elixir you can write it in a synchronous style and to make it concurrent is usually very easy because the semantics of regular and concurrent code is essentially the same. for example refactoring something like this: File.stream!("path/to/some/file") |> Stream.flat_map(&String.split(&1, " ")) |> Enum.reduce(%{}, fn word, acc -> Map.update(acc, word, 1, & &1 + 1) end) |> Enum.to_list() to be async, concurrent, (Flow uses GenServers under the hood, A GenServer is a process like any other Elixir process and it can be used to keep state, execute code asynchronously and so on.) File.stream!("path/to/some/file") |> Flow.from_enumerable() |> Flow.flat_map(&String.split(&1, " ")) |> Flow.partition() |> Flow.reduce(fn -> %{} end, fn word, acc -> Map.update(acc, word, 1, & &1 + 1) end) |> Enum.to_list() The point is the code isn't radically different and is easy to understand if you understand the first block of code.
- chefandy 3y agoYeah— as a primarily python guy, I find concurrency much more palatable in elixir than in js. As a relatively infrequent js user, I have tripped on its asynchronicity for decades. After learning in Perl, shell scripting, and a smidge off C in the early 2ks, then PHP and python in the subsequent decade, I rage quit js every time I picked it up for anything significant until like 10 years ago. For the first few years, I always forgot basic facets of the language like the scope of "this" in anonymous callback functions. While it's not a close analog, the way Unreal Engine's node-based "no code" Blueprints language approaches asynchronicity just feels so much more natural. Even hopeful pre-hello-world coders seem to conceptually get "well I can't get that because this hasn't happened yet." Having graphical representations of things both in nodes and in-game obviously helps in ways that wouldn't make sense in js, but being built from the ground up to handle it does show that it can be approached more intuitively.
- hinkley 3y agoAny sufficiently complicated distributed program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang
- whalesalad 3y agoI've done this multiple times. I will not make the mistake again. Next big system is being born in Elixir.
- pdimitar 3y agoWell, give me a call if you need help. Just looking for work again lately.
- whalesalad 3y agoFeel free to shoot me your cv/resume to the address in my profile! We just hired two new engineers this week, so the timing is not perfect, but I would like to have your info around for a rainy day which might come sooner than later.
- pdimitar 3y agoJust did. Thank you.
- nesarkvechnep 3y agoSame as @pdimitar. I’m looking for part-time work.
- whalesalad 3y agoplease see comment to @pdimitar and do the same ;)
- mikhailfranco 3y agoVirding's First Rule of Programming: http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-programming.html http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-...