Live data from Hacker News

Switching to Elixir

leemeichin.com

221–230 of 283 posts

Re: Switching to Elixir

#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?

Re: Switching to Elixir

#222
post #159

Earlier quoted context omitted.

I believe this as well. I like dynamic typing, because it often feels to me that rigour of static typing is slowing the prototyping phase. Plus overusing types creates a lot of boilerplate. In one of the frontends I've seen adding a boolean field to a form required changing over 10 files - thank you Typescript. On the other hand, sometimes I feel like it has a lot to do with test writing. I feel people enjoy static t…

> If you do write tests, all the type errors get caught pretty immediately anyway, so I just don't see the benefit. That's a pretty big if , though. You will never catch me in my typed backyard, writing tests that say: if typeof(arg) =! string then return error("Not a string!") An additional problem of course is that solutions that assume extra work from people, tend to be brittle ones (also thinking about "manual ba…

You will never find me in my dynamic backyard writing such tests neither - I will write normal tests and they still expose type errors.

And, if you do not write tests, there is a bunch of other problems that will surface, which will not be caught by the compiler itself. What I'm saying is static types give you feedback loop:

write code -> make the project compile -> fix bugs

while the dynamic ones give you:

write code -> fix bugs (including type ones).

Obviously, YMMV. For me it works. And to be honest, from my experience nothing is more brittle than a type hierarchy designed early in project lifetime and then fixed repeatedly until it "works", but again - to each their own.

Re: Switching to Elixir

#223

Earlier quoted context omitted.

Does José need to write up an elixir-lang.org blog post every other week on the status of their type system project for HN's collective memory to know it's in the works?

While you're waiting for official support in the language, just properly document functions with @spec and change them to @spec! after adding TypeCheck to your project and viola, you get powerful type checking at runtime with almost no performance impact. The error messages it produces are so beautiful. https://github.com/Qqwy/elixir-type_check

In a functional language where you're writing a lot of functions it's a bore and feel very dated.

Especially as you have to write the function name so copy/paste from other @spec doesn't really at least speed it up.

It is what it is I guess.

Re: Switching to Elixir

#224

Earlier quoted context omitted.

Does José need to write up an elixir-lang.org blog post every other week on the status of their type system project for HN's collective memory to know it's in the works?

While you're waiting for official support in the language, just properly document functions with @spec and change them to @spec! after adding TypeCheck to your project and viola, you get powerful type checking at runtime with almost no performance impact. The error messages it produces are so beautiful. https://github.com/Qqwy/elixir-type_check

> and viola

Nice to see you are a musical aficionado too. More seriously, how does this compare to other type checking alternatives for Elixir/BEAM were I to start a new project, including Gleam and Witchcraft (which at least seems to be unmaintained for now)?

Re: Switching to Elixir

#225

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…

It's really hard to prototype w/ static typing. It's not really about mechanics; annotating parameters or return types, that stuff's easy. The problem is that in prototyping you're changing a lot of stuff because you don't necessarily know what the structure or types will look like, and every time you change something or rethink your taxonomy you have tons of type updates to do.

Re: Switching to Elixir

#226
post #76
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…

I was gonna say the actor model stems from state machines I believe. It's a nice way to manage state and communication. It reminds me of supervisors and processes in general but not program language specific.

Re: Switching to Elixir

#227
post #87
post #81

Earlier quoted context omitted.

Behaviours might be what you're looking for, they're the closest thing to inheritance in Elixir. And you're absolutely right about genservers being objects :)

They are, but it's not as natural as A specializes B that specializes C.

It's maybe not quite as formalized inheritance, but (at least in Erlang) you can make behavior B that is a behavior A, and in module C (which implements behavior B), do B:start(C, ...) B;start/? Most likely does A:start(B, ...) and when the callbacks come in, B may call functions from C or not depending on things (such as if there is an optional callback defined).

If your boilerplate turns out to not really be that samey though, it's easier IMHO to have a template and customize it where applied.

Re: Switching to Elixir

#228

I've been programming in Erlang since 1991, every day; and that has been my intention all the time. I've done things in Haskell, Rust, Elixir, etc.. over the years. Strong typing is extremely valuable but what it all boils down to is where I have the most fun. Erlang is the prog.lang that gives me most joy and I plan to continue hacking Erlang, at least, until I retire in a few years.

What kinds of projects have been the most fun for you to work on?

Re: Switching to Elixir

#229
post #107

Earlier quoted context omitted.

Lack of proper types is what killed the joy of programming in Elixir for me (I lasted 6 months, hoping I would somehow adapt, but the experience was so miserable that I decided to move on). I simply can't understand how anyone can be productive in a big codebase without the rigor of static typing, but those people exist, so I guess there must be something about our brains that divides us in the dynamic vs static typi…

Nice to see that I'm not the only one - lasted 9 months trying to adapt to Elixir and couldn't. My background is Scala/Rust with heavy use of effect systems and reliance on writing the types out and then solving the puzzle of how to make everything fit. The tooling is pretty poor due to lack of investment compared to some of the other languages, and the debugging story is not great either. But hey, it works for some.

same here, mate. though mine is haskell. I'd rather waiting for gleam to mature enough to mess around with it than to be miserable with the dynamics of the data. I just don't like to guess stuff down the line.

Re: Switching to Elixir

#230

Earlier quoted context omitted.

While you're waiting for official support in the language, just properly document functions with @spec and change them to @spec! after adding TypeCheck to your project and viola, you get powerful type checking at runtime with almost no performance impact. The error messages it produces are so beautiful. https://github.com/Qqwy/elixir-type_check

In a functional language where you're writing a lot of functions it's a bore and feel very dated. Especially as you have to write the function name so copy/paste from other @spec doesn't really at least speed it up. It is what it is I guess.

well, you can avoid this if you try to limit the number of public functions so you don't have to do this as often. make as many defp functions as possible, really.
Post reply on HN