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

Switching to Elixir

leemeichin.com

Post reply on HN
Print view View original

271–280 of 283 posts

Re: Switching to Elixir

#271

Post by ljm »

gv83 wrote: post #221

while bracing myself for the downvotes storm: why is this frontpage? it's very bland content harping the same old story about immutable data and pipes, without any real insights other than "3 months of a new thing and it seems cool". are we really at the point where rust or elixir in the title = instant karma shower?

I'm the author and it was a surprise to see the post here, and I find that flattering and quite warming that someone liked it enough to share (and enough people liked it enough to upvote it).

I respect your opinion but might I suggest you were not the audience for it? There are maybe three or four posts saying the same thing as you. Nobody has to like or agree with anything that hits front page on HN. And yes, I do agree that HN has a soft spot for Elixir lately, same as AI and LLMs.

Re: Switching to Elixir

#272

Post by ljm »

andsbf wrote: post #7

`...If you call model.update(params) in Ruby, then it returns false if it fails and updates model.errors with what went wrong. Mutable state.` This is Rails stuff, not Ruby

Yeah, the example is Rails-specific but Ruby is full of methods that mutate existing state. Most of the time they're marked with `!` at the end, but not always.

Re: Switching to Elixir

#273

Post by ljm »

da39a3ee wrote: post #117
lawn wrote: post #103

Earlier quoted context omitted.

And Erlang (and Elixir) is also closer to the original definition of OOP, with it's focus on message passing between processes ("objects").

Right exactly. The author implies that Elixir isn't an "OOP language" but I agree with you that (AIUI) it's almost the opposite -- it's descended from Erlang whose, AIUI, entire raison d'etre is programming in a style that is strongly oriented around objects (i.e. instances that usually represent entities in the application domain, and communicate by message passing). Immutability is orthogonal.

I mean, I agree as much in that OOP in its classical Alan Kay definition has little to nothing in common with what we currently call OOP.

Erlang definitely has more in common with Smalltalk and even Lisp in terms of its architecture and also the ability to modify it at runtime. At least in elixir, state and behaviour aren't intermingled as in Java-style OOP (which PHP, C# and Ruby do mostly)

Re: Switching to Elixir

#274

Post by ljm »

lucasyvas wrote: post #166
mstipetic wrote: post #156

Earlier quoted context omitted.

Every time an elixir discussion starts a vocal segment of people just starts complaining about types. Ok we get it you like types, can you leave the rest of us in peace

To be fair, it's the author's fault this time. They brought it up at the very beginning in the third paragraph. The author's joy will also be short-lived because static typing is coming and will likely win out if the implementation is solid.

Author here... I wasn't the one who posted this article to HN and upvoted it. Hell, I don't even have analytics on my website, so I had no idea. You can't really blame me for sharing my thoughts.

But yeah, static typing in some circles is a racket. Typescript has been a royal pain in the ass because people think a type system solves everything, but it can't solve side-effects no matter how well-typed they are.

Tests are always going to be my safety harness, not a promise from the compiler that my shit is sound.

Re: Switching to Elixir

#275

Post by h0l0cube »

59nadir wrote: post #258
h0l0cube wrote: post #251

Earlier quoted context omitted.

> incorrect even in the face of the simplest examples I haven't found this in my experience. Most issues arise from a lack of typespeccing. If one were to rely on type inference, then, yes, it's not going to catch much. Specifying types is a requirement of a strictly-typed language, so to make a claim of deficiency with Dialyzer's type checking, you'd be comparing code that's fully specced with that of a strictly typ…

I've used dialyzer since 2015, it's not a question of "holding it wrong". I have an example of this that I literally demonstrated live in a talk online. It's very likely you haven't used dialyzer enough if you think it's actually correct 100% of the time even with type specs. Dialyzer is an exceedingly poor implementation of static type checking and not sufficient with any level of use.

I thought Dialyzer never raised false positives at the expense of false negatives, though perhaps your example is a false negative? I’ve only used it in the last 4 years. Is it possible the bugs have been fixed by now? Or is this just an inherent to this kind of type checking?

Re: Switching to Elixir

#276

Post by rednafi »

I usually pick up languages that allows me to write and ship high quality CLIs quickly. Over the years, I’ve written and shipped a few. If a language comes up with a VM where the CLI startup time is too long, it’s a show stopper for me. I know, weird requirement.

Re: Switching to Elixir

#277

Post by riffraff »

macintux wrote: post #197
riffraff wrote: post #82

Earlier quoted context omitted.

Why do you think riak was well ahead of its time? (actual question, I'm not arguing) IIRC it was a few years after the dynamo paper came out, and at a time when a bunch of other nosql+high scalability solutions did (e.g. Cassandra)

I suspect the parent comment is primarily referring to Riak Core, which was another layer of abstraction above Erlang’s OTP for distributed processing. Riak the database used Riak Core, but it could be used independently of the database. I hadn’t thought about Core in a long time, I should take another look. Looks like someone is carrying the idea forward: https://riak-core-lite.github.io/

Ah that makes sense, thank you.

Re: Switching to Elixir

#278

Post by 59nadir »

h0l0cube wrote: post #275
59nadir wrote: post #258

Earlier quoted context omitted.

I've used dialyzer since 2015, it's not a question of "holding it wrong". I have an example of this that I literally demonstrated live in a talk online. It's very likely you haven't used dialyzer enough if you think it's actually correct 100% of the time even with type specs. Dialyzer is an exceedingly poor implementation of static type checking and not sufficient with any level of use.

I thought Dialyzer never raised false positives at the expense of false negatives, though perhaps your example is a false negative? I’ve only used it in the last 4 years. Is it possible the bugs have been fixed by now? Or is this just an inherent to this kind of type checking?

I don't think the implementation itself is at fault (I phrased that poorly in my previous post), but yes, I do think that the design of dialyzer makes it an (at times) faulty type checker. The unfortunate reality of a type checker that fails sometimes is that it makes it mostly useless because you can never trust that it'll do the job.

To be clear, I've had it fail in a function where I've literally specced that very function to return a `binary` but I'm returning an `integer` in one of the cases. This is a very shallow context but it can still fail. Now add more functions, maybe one more `case`. Dialyzer will just never keep up over a long enough time frame.

I think an entire rethink of type checking on the BEAM had to be done and that's why eqWalizer[0] was created and why Elixir is looking to add an actual sound, well-developed type checker. Gleam[1] I would assume is just a Hindley-Milner system so that's completely solid. `purerl`[2] is just PureScript for the BEAM so that's also Hindley-Milner, meaning it's solid. `purerl` has some performance issues caused by it compiling down to closures everywhere but if you can pay that cost it's actually pretty fantastic. With that said my bet for the best statically typed experience right now on the BEAM would be `gleam`.

0 - https://github.com/WhatsApp/eqwalizer

1 - https://gleam.run

2 - https://github.com/purerl/purerl

Re: Switching to Elixir

#279

Post by SamFold »

hartator wrote: post #249
SamFold wrote: post #64

Earlier quoted context omitted.

SumUp (8B valuation) uses Elixir and I'm sure there are more. https://www.crunchbase.com/organization/sumup https://www.sumup.com/careers/positions/berlin-germany/engin...

SumUp backend is built on Go. They use Elixir only for some hardware things. It seems more like a toy thing for them. Ref: https://www.sumup.com/careers/positions/

I wouldn't go as far as saying it's a "toy" for them, I know some engineers there and someone who joined recently who spent significant time learning Elixir before joining.

Re: Switching to Elixir

#280

Post by keep_reading »

deviprsd wrote: post #254
keep_reading wrote: post #215

Earlier quoted context omitted.

Elixir is my excuse for refusing to entertain the idea of an k8s cluster at work. Completely unnecessary.

k8s solve a different layer of problems, to me they are a complemental tool to elixir when there is a need for that layer, otherwise yes it is completely unnecessary.

Why would you want to deploy an Elixir app on a system that adds an unacceptable amount of latency to the network? K8s is trash for all the stupid network packets being copied from user space to kernel space and back
Post reply on HN