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

Would you still pick Elixir in 2019?

github.com

Post reply on HN
Print view View original

221–230 of 246 posts

Re: Would you still pick Elixir in 2019?

#221

Post by artellectual »

josevalim wrote: post #158
arcticfox wrote: post #83

Earlier quoted context omitted.

> If you need multi core and distributed features (which is generally more common than you think) elixir is truly your friend. Is it though? At least in my line of work I don't think I've ever run into this. I feel like I've always been able to distribute just fine with workers/queues. If I even suspected it would I'd look into it more, but generally I find distributing across systems to be a software architecture-le…

Because those features are accessible, you end-up using them a lot more frequently and find new and exciting ways to use them. For example, I am really happy that Elixir and its tooling does pretty much everything using all cores: compiling code, running tests, generating documentation, etc. and all of this has a direct impact on the developer experience. The other part is that you can build more efficient systems by…

Exactly right, just the pure fact that it's at your disposal makes you think about problems in a whole new way. For example, I recently just abstracted my solutions away from Redis. I have nothing against redis however removing a dependency makes things more simple, which is important for my setup.

For caching you have SO many options which are already built in, ets, agent, ets + gen_server, or even reaching out for a library like nebulex.

Another example is recurring jobs, you can create a gen_server that will run a job every x hours in roughly 50-100 lines of code depending on how complex your problem is.

I rarely feel the need to reach out for external dependencies. Not that there is anything wrong with that, it's just that you now have a wider array of tools to work with and some problems are just solvable with a couple of lines of code instead of having to reach out for external tooling.

I recently built a distributed work queue, generally in Ruby I would use something like sidekiq, however elixir made me feel like "hey you can write your own" which generally is not recommended since you don't want to re-invent the wheel, but if you are doing something that breaks away from the existing solution, having the ability to craft a custom solution that works for your specific set of problems is extremely powerful, you can get much more creative, and the important thing is it got done fast (I wrote a distributed job scheduler in 2 weeks + 1 week to clean it up and work out the kinks, it's already running stably in production)

Re: Would you still pick Elixir in 2019?

#222

Post by latch »

pmarreck wrote: post #186
latch wrote: post #60

Earlier quoted context omitted.

It's the synergy between the language, the runtime and the standard library to deliver the actor model. Elixir "threads" are called "processes". It's a bit confusing at first, but there's a good reason for it. So from hereon in, when I say "process" think "thread". Elixir processes, like OS processes, are fully isolated from each other. If Process A has data than Process B wants, Process A has to ask it (send it a me…

Spotted the BleacherReport guy (...I think!) ;)

Nope. I work at https://www.secondspectrum.com/

Re: Would you still pick Elixir in 2019?

#223

Post by undersheet »

GordonS wrote: post #203
undersheet wrote: post #192

Earlier quoted context omitted.

> I’ve been integrating a bootstrap framework You do this for legacy systems. New systems should not use Bootstrap, there is much better out there.

Don't be so dogmatic - Bootstrap works just fine, and if it's what you know, you need some very good reasons to switch and learn a new framework.

Not about being dogmatic. Bootstrap is just wrong in 2019.

Re: Would you still pick Elixir in 2019?

#225

Post by andy_ppp »

undersheet wrote: post #223
GordonS wrote: post #203

Earlier quoted context omitted.

Don't be so dogmatic - Bootstrap works just fine, and if it's what you know, you need some very good reasons to switch and learn a new framework.

Not about being dogmatic. Bootstrap is just wrong in 2019.

I agree but this type of comment also shows your lack of experience. Very rarely do you personally get to make a choice about the technology used. In this case I’ve come onto a project to fix a load of bugs and restyle something that already existed. I’m not going to come in and redo everything from scratch before delivering something...

Re: Would you still pick Elixir in 2019?

#226

Post by rs86 »

I have mixed feelings about using Elixir (or Erlang); as far as I understand the platform, it is about building fault tolerant systems/high availability, specially in the presence of hardware failure. I think those are handled well by cloud service providers; they didn't exist during the 80s.

I think performance is better compared to Ruby and Python, but then again my experience with web applications is that the domains are best modeled using classes.

For writing networking code and protocols, the binary pattern matching is amazing, though. The Plug libraries are a pleasure to use also.

Re: Would you still pick Elixir in 2019?

#227

Post by GordonS »

undersheet wrote: post #223
GordonS wrote: post #203

Earlier quoted context omitted.

Don't be so dogmatic - Bootstrap works just fine, and if it's what you know, you need some very good reasons to switch and learn a new framework.

Not about being dogmatic. Bootstrap is just wrong in 2019.

OK, so how am I supposed to take a reply like this - it sounds... well, dogmatic!

Given you haven't even attempted to explain your reasoning, I can't possibly agree.

Re: Would you still pick Elixir in 2019?

#228

Post by GordonS »

ludwigvan wrote: post #207
GordonS wrote: post #155

Earlier quoted context omitted.

I guess you're not a regular HN reader? :) Many HN commentors routinely think that they are "the programming world", which is rather far from the truth. For years, dynamic typing has been hyped on HN, while statically typed languages such as C# were routinely scoffed at. Something in the air has definitely changed recently, with many discovering the very trait they eschewed is actually a major boon - very likely beca…

> Something in the air has definitely changed recently - Type inference becoming commonplace is an important factor. Previously it felt kind of silly in statically typed langs to supply some of the things compiler could figure out. - Strict null checking becoming commonplace increased confidence. Previously, even if your code compiled, you would still get null pointer exceptions. - Type checking became kind of opt-in…

These are some great points I hadn't considered, thanks

Re: Would you still pick Elixir in 2019?

#229

Post by [deleted] »

pdimitar wrote: post #215
hota_mazi wrote: post #86

Earlier quoted context omitted.

The fact that it's dynamically typed is also often overlooked, while it's at the top of my deal breaker list. The programming world is strongly moving toward statically typed languages, because today, there's pretty much zero reasons to use a dynamically typed language.

Pattern matching is strong typing. It just doesn't assert on a type alone -- it also asserts on the shape of the data itself. Example: def handle_data(%{ customer: %{ date_of_birth: %NaiveDateTime{} = dob, account_balance: %Decimal{} = balance, name: name, count_purchases: purchases } }) when is_binary(name) and is_integer(count_purchases) do # work with the data here end ^ This both asserts on a particular data stru…

[deleted]

Re: Would you still pick Elixir in 2019?

#230

Post by phtrivier »

yawaramin wrote: post #164
hota_mazi wrote: post #86

Earlier quoted context omitted.

The fact that it's dynamically typed is also often overlooked, while it's at the top of my deal breaker list. The programming world is strongly moving toward statically typed languages, because today, there's pretty much zero reasons to use a dynamically typed language.

I agree and believe that it's harder to maintain a dynamically-typed codebase, but Elixir has a well-thought-out gradual typing solution: typespecs ( https://hexdocs.pm/elixir/typespecs.html#basic-types ). This builds on Erlang's Dialyzer tool and is supported by editor plugins like VSCode's ElixirLS extension. In practice, you do get instant typechecking while you code, if you write down the typespecs properly.

Purely anecdotal: our experience with Dialixir was rather disapointing (slow, lots of false positive, hard to express types coming from external libraries and generated code.)

Unfortunately, the tradeoff at the time made us stop using specs altogether.

Post reply on HN