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

91–100 of 283 posts

Re: Switching to Elixir

#91

Post by realusername »

byhemechi wrote: post #34

I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so muc…

Elixir is a bit in the middle, with the massive amount of very specific pattern matching for each function and the fact that modules are just plain collection of functions and not objects I would say it's the most static of dynamic languages.

They are working on typing it now from the blog posts I've seen and they will probably be successful because the language is well suited for that in my opinion

Re: Switching to Elixir

#92

Post by csan_gonzo »

byhemechi wrote: post #34

I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so muc…

I've been using Elixir for over a year now and the only thing that's missing for me is a static type system, really looking forward to this: https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua... Also keeping an eye on Gleam: https://gleam.run/ .

Re: Switching to Elixir

#93

Post by olivermuty »

jbmsf wrote: post #39
superdisk wrote: post #14

For me the big sell of Elixir/Erlang is that it makes running "background jobs" a complete breeze with no concern for blocking IO bringing the entire server to a halt, especially in a web server context. At my last job I had to do a bunch of HTTP requests in a webhook handler and if enough happened at once, the entire site would just crash due to all the OS processes being busy. I found myself desperately wishing I w…

Meh. I don't want background jobs to be a breeze in quite this way. I want background work to live on different compute capacity than http requests, both because they have very different resources usage and because I want to have state or queues in front of background work so there's a well-defined process for retry, error handling, and back-pressure. I get it, of course, it'd be lovely if these complications didn't…

If you want a language and VM that makes it easy to run jobs on different compute then boy do I have great news for you ;)

Running heterogenous loads on an elixir cluster is almost trivial. Certainly trivial compared to other languages. No external deps required.

Re: Switching to Elixir

#94

Post by mdx97 »

mijamo wrote: post #85
byhemechi wrote: post #34

I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so muc…

I think it vastly depends what you're writing. Any kind of function that does not have a fixed input and output gets a lot more complex with static types. And by extension any code that depends on that also gets more complex. I tried at some point to use Rust for an API but then I depended on making calls to a very complex API. In JavaScript I would have just gotten back a complex object where I can then pick whateve…

> I tried at some point to use Rust for an API but then I depended on making calls to a very complex API. In JavaScript I would have just gotten back a complex object where I can then pick whatever I want progressively through object access methods. In Rust I ended up with more than 500 lines of type definition for the API and it still wasn't enough so I gave up.

You can always deserialize things as `serde_json::Value` instead of making types for everything to get similar behavior out of Rust.

Re: Switching to Elixir

#95

Post by threatofrain »

byhemechi wrote: post #34

I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so muc…

I think static typing (without escape hatches) slow you down when you're a library or framework author, or you're doing something high performance. The reason being that there are many trivial and non-trivial propositions which the field has ironed over but the core language/compiler team hasn't caught up yet.

I've seen a lot of authors do crazy type things to get around the type system (like typing out recursion to the n-th level by hand), and I think many open source projects are slowed down by the lack of a type wizard on their team.

Re: Switching to Elixir

#96

Post by baq »

jb3689 wrote: post #76
zoogeny wrote: post #56

I have been watching Elixir YouTube videos pretty much every day for the last few weeks. I guess there was an Elixir conference recently and after I watched a couple, YouTube has been sending me a consistent stream of Elixir content. I really want to try out this language. I love the idea of Erlang but the few times I've had to deal with it (an ejabberd chat server was one) I found it to be a bit too quirky. Every vi…

You are overthinking some of it at least when it comes to concurrency. Look at what a process is and how send works. GenServer is a natural generalization of a pattern you’d write a thousand times. Knowledge of actors is transferable. Go has libraries which implement actor abstractions for example. Process mailboxes are just message queues like Go’s channels are. There are differences with respect to how the interpre…

Riak was pretty bad at ops. Leaving and joining nodes took ages and god forbid you tried to use any of the added features like solr search. If you settled on a very small subset of all features it worked nicely... it just wasn't very useful if anything went wrong due to app or user error.

Re: Switching to Elixir

#97

Post by curtisblaine »

threatofrain wrote: post #95
byhemechi wrote: post #34

I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so muc…

I think static typing (without escape hatches) slow you down when you're a library or framework author, or you're doing something high performance. The reason being that there are many trivial and non-trivial propositions which the field has ironed over but the core language/compiler team hasn't caught up yet. I've seen a lot of authors do crazy type things to get around the type system (like typing out recursion to…

In my experience, static typing greatly slows you down when you're prototyping, at least for a short time, then it moderately speeds you up when you're productionizing and maintaining.

Re: Switching to Elixir

#98

Post by conradfr »

sinuhe69 wrote: post #19

Coming from F# and only dabbled in Elixir, I find the language unfortunately a bit confusing. For instance, the signature of a function only reveals the name and number of the parameters but not type, so in a big library, it’s quite hard to recognize (mentally) what goes into what and one can only see one plugged the wrong parameters after one had ran and debugged the code. In strict-type language like F#, such issue…

The lack of typehinting for function parameters is definitely the biggest productivity hit for me in Elixir.

You can go by with typespecs, pattern matching and guards but that's kind of exhaustive and not really IDE / Intellisense friendly (at least with the community-led Jetbrains plugin).

Re: Switching to Elixir

#99

Post by rTX5CMRXIfFG »

mijamo wrote: post #85
byhemechi wrote: post #34

I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so muc…

I think it vastly depends what you're writing. Any kind of function that does not have a fixed input and output gets a lot more complex with static types. And by extension any code that depends on that also gets more complex. I tried at some point to use Rust for an API but then I depended on making calls to a very complex API. In JavaScript I would have just gotten back a complex object where I can then pick whateve…

The perceived difficulty of static typing depends on the type system itself. For example, there was a version of Swift where it became extremely painful to work with String and Substring, or Array and ArraySlice, which you’d intuitively just pass around whenever you’re making smaller pieces of collections but which the compiler complained about during type-checking when you are substituting one type for another. They solved the problem by just defining a protocol such as StringProtocol (and just reusing Sequence for arrays I think) and using that protocol wherever parameters are passed around, so it became possible again to swap those types for each other.

So then there’s more code for the language devs to write of course, but that’s just the cost of safety, which is highly desirable if you want the technology that you are building to be attractive for use in systems where correctness is critical, which also tend to be highly valuable. As a working professional it’s in my best economic interests to have such valuable tools in my skillset.

Post reply on HN