Live data from Hacker News

Switching to Elixir

leemeichin.com

61–70 of 283 posts

Re: Switching to Elixir

#61

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 just moved from typescript to javascript and for me it was just that I own the database, i own the api surfaces and as such I don't need to enforce any kind of type checking as the api schemas are sufficient for my case. I would definitely use type safety if I had a lot of external data sources. or if there are lots of people working with me. Otherwise, I am beginning to go back to dynamic languages at least for we…

That's an interesting decision, because it's the reverse of one of the big complaints about Typescript: that it only works up to the API boundary, and doesn't include external data sources (unless you use libraries like Zod to combine runtime and static type checking).

For me, Typescript is more useful, the more of the codebase I "own", because it means I can be more confident that all the types reflect the true types of the runtime data, which means I can change things more confidently and quickly. Do you find that you're refactoring and changing things less with dynamic languages? For me, I think that's the number one magic feature that I miss when I use languages without explicit type systems.

Re: Switching to Elixir

#62

And still 0 successful startup has been built on top of elixir.

Real talk. HN posts on anything OTP continue to be the same echo chamber of responses, with most readers just leaving them to it. Many people have been trying to nicely point out that "uses Elixir in some places" is not the same as "built on Elixir". ie It's exceedingly rare for any system to have a secret sauce called Elixir and none of them have sparked a race to use it. How many decades before someone points out i…

> The no-side effect philosophy is a dead end.

??? Erlang and Elixir have of tons of side effects. You must not either know the languages well—or maybe you mean immutability?

If you mean immutability, have fun building highly concurrent systems without it. The local reasoning and safety guarantees that immutability gives you makes building large scale applications sane—that’s the only way I’d want to program.

Re: Switching to Elixir

#63
post #46

Write after you’ve been there for 2 years, instead of at the start. That new thing always looks like a flawless shiny new silver bullet when starting out.

I work professionally as an elixir developer for longer than that before starting a PhD program; Elixir was and still is a gem. It’s not perfect. It holds up incredibly well though.

Re: Switching to Elixir

#65

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…

static typing is a means to an end. if you can achieve the same end without static typing, good right? that is the goal of spec. the creator of the language has a fantastic talk on this https://youtu.be/giYbq4HmfGA?si=LgSHZupSuR-kMXmj

For me, a huge part of it is that I find static typing to make the code a lot more self-documenting.

I can easily see what is passes or returned, and if I'm unsure about the details of the type the answer is a click away, or a short web search away at worst.

Significantly reduces my mental load, allowing me to be vastly more productive.

Re: Switching to Elixir

#66

Earlier quoted context omitted.

because of unification/pattern-matching you have a pretty good idea, just looking at function name + args what the shape of the data is going to be.

As someone who worked with Elixir for the past couple years, and maintains multiple libraries in Elixir - nah not really. Static typing is the thing I'm missing with Elixir. No matter how much pattern matching you do, and how many typespecs you add to get a better understanding of what's behind a variable, you'll still run into issues at runtime frequently that could have been avoided if it was statically typed. Dial…

I miss static typing for two separate and quite opposite cases:

* trivial errors, that still cause a crash and waste my time ("foo(:yo, 7)" but was "foo(7, :yo)") - sometimes spotted by Dyalizer

* complex nested structures. In Java I never have surprises as to what foo.bar.baz is and I can use autocomplete reliably. Expressing the same invariant in Elixir is something less straightforward

Re: Switching to Elixir

#67

“In fact, I might go as far as saying that Elixir gives you a fun language (like Ruby) while leaving out the stateful footguns OOP languages give you. There are no classes, no instances, no inheritance…it's immutable and functional and you're not bogged down by a static type system.” I want this but with types. I’m convinced strongly typed is the way to go for larger code bases as it hides the magic of a lot of thing…

I'm a contrarian here. I really wished we had inheritance in Elixir for GenServers - because those are objects, interacting out of messages and not just glorified structs with associated functions.

So I wish I could have a generic template for a project's GenServer (for basic common registration, memory configuration, logging), that is specialized for a specific task, of which there are three flavours.

Speaking of footguns, Elixir patches this problem with macro code generation, but it is not so good. Any my GenServers are full of trivial repetitions.

Re: Switching to Elixir

#68

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 just moved from typescript to javascript and for me it was just that I own the database, i own the api surfaces and as such I don't need to enforce any kind of type checking as the api schemas are sufficient for my case. I would definitely use type safety if I had a lot of external data sources. or if there are lots of people working with me. Otherwise, I am beginning to go back to dynamic languages at least for we…

I'm currently working on a data engineering team, unborking some things on a team where all the original developers of the codebase had left. Up until then, I wrote Ruby for over 10 years, and Elixir for 3. I didn't have an opinion about JS or Typescript before this project.

Typescript does not solve the fundamental problems of JS. I'm not convinced it really solved the issues related to ingesting data from many different data sources. The data quality issues were still there.

If I were rewriting the whole thing, I'd rewrite it with Elixir (of course), if only to have a sane way of handling errors.

Re: Switching to Elixir

#69

Earlier quoted context omitted.

because of unification/pattern-matching you have a pretty good idea, just looking at function name + args what the shape of the data is going to be.

As someone who worked with Elixir for the past couple years, and maintains multiple libraries in Elixir - nah not really. Static typing is the thing I'm missing with Elixir. No matter how much pattern matching you do, and how many typespecs you add to get a better understanding of what's behind a variable, you'll still run into issues at runtime frequently that could have been avoided if it was statically typed. Dial…

The fact that you _can_ open a REPL in production and inspect the data at runtime is huge.

Although few people use hotloading in code before, shapes of data can change from deployment to deployment.

Re: Switching to Elixir

#70
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…

> looking at the magic of LiveView (and LiveBook) What's the magic? I think it's pretty easy to get a correct mental model of everything in livebook maybe excepting exact details of how the diff calculation/data compression works. Even so, you can spy on the websocket messages and get a reasonable picture of what's going on in a pinch. Liveview is incredibly straightforward.

> Liveview is incredibly straightforward.

I don't agree. One of the keynotes from the 2023 ElixirConf was Chris McCord (one of the principle developers of LiveView) describing how it is almost 1.0 [1]. One thing that made me laugh a bit was him emphasizing how much Javascript he's had to write (he was referencing the fact that there is an internal community meme that you can achieve such incredible behaviors without writing Javascript). His quip was "because I wrote it all". I wonder if you asked him "was it straightforward?" what do you think his answer would be?

There are a lot of videos of people talking about how they managed to write something in LiveView. Here is one from 2022 "How I built a block based editor in LiveView" [2]. That is a good one to see how non-trivial tasks can be difficult in LiveView, describing a few times how he had to fight with it to get it to kinda-sorta do what he wanted. Certainly this man will achieve his goal since he is smart and motivated, but his description of his journey does not lead me to a conclusion of "this is incredibly straightforward".

This is impressive tech no doubt, but it is far from clear it is currently reliable enough to stake a startup on. Another tangential issue I have with LiveView is the obvious requirement for a persistent socket connection ... which leads me to wonder how one would approach local-first type developments. Again, certainly possible but definitely not straightforward.

1. https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeS...

2. https://www.youtube.com/watch?v=7yZwxsG7tVs

Post reply on HN