Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Elixir (2014)

theerlangelist.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Why Elixir (2014)

#31

Post by jefc1111 »

sph wrote: post #2

From the author of this post, here's one of the best demos of Elixir, Erlang and modern distributed computing in general: "The Soul of Erlang and Elixir • Saša Jurić • GOTO 2019" - https://www.youtube.com/watch?v=JvBT4XBdoUE When you feel sufficiently amazed by this demo, I also recommend the Elixir in Action book, by this same author, to get started with this incredible ecosystem and paradigm. --- It's hard to imagi…

I read Elixir in Action which was a great intro, but it was Concurrent Data Processing in Elixir [1] that really made the penny drop for me.

I have only finished one Elixir app. It was a lot fun and the app has proven rock solid. For me it felt a bit like using microservices but with lots of the footguns and ops overhead removed. I would love to use it for more than a hobby project.

[1] https://pragprog.com/titles/sgdpelixir/concurrent-data-proce...

Re: Why Elixir (2014)

#32

Post by toast0 »

theonething wrote: post #8
sph wrote: post #4

Earlier quoted context omitted.

Anything that spends most of its time waiting on IO, and doesn't do a great deal of number crunching: i.e. any kind of server talking over a network socket. Go, and any other language, lowers the barrier to running concurrent code, but there is much more to concurrent servers than concurrency: fault tolerance, isolation, shared state management, instrumentation, introspection, clustering, process migration. The BEAM…

> Data races are impossible As far as the application code goes, but most systems have databases which opens you up to all kinds of race conditions. Does Elixir help in that case?

My experience with databases in Erlang was using the pattern where one process recieves a high level message and does the database work was best. If you can split the queue in a sensible way, that gives you concurrency; for example if all the requests address a single user, you can hash users into as many buckets as you need for concurrency; if the individual requests take a long time, it might make more sense to keep a scoreboard of if a user has a process working for it, and send further requests there, otherwise to an idle process (or spawn).

You do need to manage this somehow, but the building blocks are there. Of course, the building blocks for transactionless database access are there too.

Re: Why Elixir (2014)

#33

Post by tres »

dragosmocrii wrote: post #24

Elixir is amazing. Had a stab at it back in 2018, then shifted to work with other traditional langs/stacks, but Elixir has always stayed in the back of my head teasing me. It's an elegant language, that you can see that the authors have put effort in keeping it lean, powerful, expressive. Phoenix (which is the goto web framework) may seem magical in the beginning, but once you dive in you realize that there is no mag…

Not sure what you're looking for in IDE support...

If you're a Jetbrains addict, there's this IDE extension which has worked well for me: https://github.com/KronicDeth/intellij-elixir

Re: Why Elixir (2014)

#34

Post by toast0 »

gv83 wrote: post #28

“Why not Elixir” is a more interesting question and I suggest you go ask it to engineering managers of polyglot organizations. They will usually bring you the super low nps from not-elixir-only devs and the resignation letters from elixir “talents” that are asked to do non elixir stuff.

> super low nps

Net Promoter Score?

> resignation letters from elixir “talents” that are asked to do non elixir stuff.

I mean, I would prefer to be working in Erlang, but I took a Rusty job recently. OTOH, if I was working in Erlang for you, and you made me switch to something else, I would most likely not be happy and if my job is changing, I may as well change jobs, or at least consider it. Leaving behind simple concurrency and hot loading means it takes a lot longer for me to get things done, and it's one thing to work at a job where things take forever, but it's even worse to go from being able to get things done quickly to slowly.

Re: Why Elixir (2014)

#35

Post by doawoo »

dragosmocrii wrote: post #24

Elixir is amazing. Had a stab at it back in 2018, then shifted to work with other traditional langs/stacks, but Elixir has always stayed in the back of my head teasing me. It's an elegant language, that you can see that the authors have put effort in keeping it lean, powerful, expressive. Phoenix (which is the goto web framework) may seem magical in the beginning, but once you dive in you realize that there is no mag…

VSCode support for the language is better than ever, outside of VSCode too! NextLS and ElixirLS provide the editor integration you’re probably looking for :)

Re: Why Elixir (2014)

#36

Post by doawoo »

Not a lot of technology I have work with every day “sparks joy”.

But the Elixir language is one that’s usually an exception!

I really encourage people to take a look at it even if you don’t end up using it right away- the OTP actor pattern is elegant yet powerful and extremely fun to prototype with.

Re: Why Elixir (2014)

#37

Post by doawoo »

gv83 wrote: post #28

“Why not Elixir” is a more interesting question and I suggest you go ask it to engineering managers of polyglot organizations. They will usually bring you the super low nps from not-elixir-only devs and the resignation letters from elixir “talents” that are asked to do non elixir stuff.

Funny, this happened to me specifically.

We were an all Elixir (and legacy Ruby) shop with some wildly smart engineers.

Got acquired and jammed into another larger org. Got pressured to switch to Java and Go without considering that maybe our system was designed around the way OTP apps work.

Fast forward a few years and lots of us left, and found successful Elixir jobs where we were much happier elsewhere, making much more interesting technology.

Sounds more like an org problem to me.

Re: Why Elixir (2014)

#38

Post by mal-2 »

I like a lot of things about Elixir but I struggled with what felt like clumsy IDE capabilities. Stuff like 'go to definition' that I use all the time in other languages didn't work right. Lack of strong types makes autocomplete problematic. I've started to mess around with Gleam hoping that it spans this gap because I want to like this ecosystem.

Re: Why Elixir (2014)

#39

Post by zelphirkalt »

sph wrote: post #10
dpflan wrote: post #9

Earlier quoted context omitted.

Sounds good, you make it sound like that Elixir is now your de-facto, even for non-distributed systems projects?

Servers are 99% of the code I write, so yes I choose Elixir, though for very conservative clients and small projects I use Go. For everything else, which is not a lot, there's Rust, Scheme, Lisp and many other fun languages to explore. My focus these days is on my business rather than consulting, so I have a lot of freedom.

How do you manage to convince employers of such language choices? (Do you need to convince?) And what kind of jobs or positions are that? I would love to use my skills like that, instead of building CRUD in Python, not really being able to apply my skillset, but employers are not ready to make the smallest leap it seems.

Re: Why Elixir (2014)

#40

Post by mekoka »

gv83 wrote: post #28

“Why not Elixir” is a more interesting question and I suggest you go ask it to engineering managers of polyglot organizations. They will usually bring you the super low nps from not-elixir-only devs and the resignation letters from elixir “talents” that are asked to do non elixir stuff.

You've successfully been dealing with a sand problem with shovels. Then the new boss tells you about these amazing forks that they've used in the past to address any and all issues and wants you to start using them too.

Quitting is not you being difficult. It's just opting out of a bad developer experience. Contrary to popular belief, you're entitled to also be happy as a professional programmer.

Post reply on HN