Live data from Hacker News

Switching to Elixir

leemeichin.com

161–170 of 283 posts

Re: Switching to Elixir

#161
post #58

It would be nice to work with Elixir, having played around with it. However every Elixir job I've seen requires Elixir experience, so I don't really see much opportunity for working with it professionally.

Yeah, I'm in the same boat. Have tried to find a side project that would justify Elixir/Erlang and nothing has jumped out at me that would cut it. I still generally want to pick the best tool for the job (even on side projects), and Erlang frequently feels like overkill for the use cases I have in mind.

Sure but for these companies "did some Elixir in a weekend project" doesn't count as experience.

Re: Switching to Elixir

#162
post #39

Earlier quoted context omitted.

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…

there's nothing stopping you from doing this but its a real game changer for an early stage startup to need a new service and the steps to getting that out is one file and an extra line in your config.

Don't choose Elixir if you just love setting up autoscaled k8s on AWS with redis, RabbitMQ and half a dozen shenanigans for a webapp that serves 10 users a day.

Re: Switching to Elixir

#163
post #160

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

It's just a hype phase. Types are cool, but in the past few years they seem to be the panacea for all problems, by inexperienced engineers that have got their first taste of Rust and Typescript. As if writing in Typescript would produce less buggy, more stable or more maintainable applications than using Elixir. I'll say types are cool again before I get routed by angry static typing zealots.

Frankly, we really need to instill the "types are cool" concept into inexperienced engineers. That insanely long phase in software engineering where people said dynamic types are cool was a huge mistake and ruined a lot of newbie minds.

Re: Switching to Elixir

#164
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.

Re: Switching to Elixir

#165
post #68

Earlier quoted context omitted.

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 diff…

> I'm not convinced it really solved the issues related to ingesting data from many different data sources That sounds like external data validation and I don't think a type system can really solve that. Even if you're using C#, Java, Scala, or what-have-you, you're going to have that issue. If that's what you expected from TypeScript, then yea, I can see how you'd be sorely disappointed... Like many others, the adva…

It is not as if I expected Typescript to be promising for external data validation. I was watching what people say about Typescript, and how people actually use Typescript.

I wrote Ruby with duck-typing for 10 years and it never seemed to be a cognitive load for me. My working memory has been degrading as I age. My Ruby code became increasingly written in a functional style. Maybe it's in how I write? Small functions, minimal (or no) side effects, composed together with names that describe how data is transformed.

Explicating types hinder me. Where it had really started becoming more useful was explicit types in functional programming, such as defining monoids or lattices, or whatever, on those data types. My experience with Typescript and even Crystal is that the static typing only yields a fragment of the benefits without being able to define operators that go with those data types. Even the Just/Maybe monad would have helped with messy external data, since that would explicitly define ambiguous data that can be progressively refined into clean data types.

I'm excited to see the new static typing effort in Elixir. It's theoretical base is a set, which, I think, will work better with how people use Elixir in production. It'll be interesting if the Witchcraft (ML ideas in Elixir) will work with those.

Re: Switching to Elixir

#166

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…

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.

Re: Switching to Elixir

#167
post #138

Earlier quoted context omitted.

I'm firmly in the camp that it's all perception. The studies I've seen aren't what I would consider conclusive, but they certainly suggest there is very little difference in the output and bugs of dynamic vs static languages. In my experience, static typing seemed to lend itself to poor testing, maybe some sort of belief that static types were good enough to not need tests that can prevent regressions. So from my poi…

I literally struggle to read and work with dynamic code. My head explodes when trying to hold return types or the shape of semi-complex data structures in my head, versus having it spelled out. I wouldn't call it an issue of "perception", I really think in my case it's "capability", pure and simple. I've programmed for thousands of hours in both styles, so we're well past the possibility of this being an adaptation p…

I’m a proponent of dynamic typing. I’d say the same thing. I don’t have enough working memory in my head to store the compile-time type information about every relevant variable, in addition to the actually important information about what the runtime data could be.

The way that I write static-typed code is by imagining how I would write dynamic code to solve the problem, and then additionally imagining what types and type constraints I need to add.

I honestly think it’s a kind of an instance of Paul Graham’s Blub Paradox. I know JavaScript and I spent years writing JavaScript. So if you ask me to write TypeScript, well, I write the JavaScript that I want to write and then go back and add types to make the typescript compiler happy.

There are a bunch of other things I could talk about. I should write a post.

Re: Switching to Elixir

#168
post #119

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…

The lack of types is hard to defend. Yet, the failed pattern match triggered at runtime becomes immediately obvious from the stack trace. You fix the pattern and move on. The cost of this mild inconvenience is still far less than the cost of satisfying types. This aside, I want typed elixir.

I love elixir, but I would also love it more with a sort of laissez-faire type system akin to TS. Glad to see they're working in that direction.

One of the best features of type systems is they make editor completions and navigation work better. Elixir's LS is pretty good, but editor support just isn't nearly as good as what you can have in a good (read: Jetbrains) IDE with a strongly typed lang like C# or Java.

Re: Switching to Elixir

#169
post #6

Sasa Juric's The Soul of Erlang and Elixir talk[1] showcases how powerful the language can be. [1] https://www.youtube.com/watch?v=JvBT4XBdoUE&t=4

As someone curious about Elixir, I watched this talk earlier this week. I highly recommend it to anyone who has heard all of the "let it fail" and "BEAM does concurrency right" talk, but still doesn't grasp it. It is an incredible talk.

Re: Switching to Elixir

#170
I used Elixir briefly, what sticks out to me was how easy it was to learn. Really like the pattern matching and immutable data. What it excelled at most and I still haven’t found the full equivalent in any other language is building a full CQRS system. The Commanded library combined with graphql was so powerful and well thought out. With the BEAM if a developer writes some bad code, instead of screwing up all your events, the GenServer will just error out on the same event until new code it pushes to fix it. Events will starting queueing, but the whole system is unaffected. It was brilliant
Post reply on HN