Live data from Hacker News

Switching to Elixir

leemeichin.com

181–190 of 283 posts

Re: Switching to Elixir

#181
post #165

Earlier quoted context omitted.

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

I am not an Elixir user but I too am watching the type story develop with a lot of interest. Even something half-decent in the vein of Python types would do it for me.

Re: Switching to Elixir

#183
Self promotion moment:

If you enjoy the Result/Either type and API in Rust, I made this project just for this: https://github.com/linkdd/rustic_result

I also made https://github.com/linkdd/rustic_maybe/tree/main for an Option/Maybe type.

NB: Those are not types, but I'm waiting for set theoretic types to update those libs :)

Re: Switching to Elixir

#184

Elixir may not be statically typed, but at least it isn’t object-oriented.

IMHO, structural typing and pattern matching get a lot of the value of static types without all of the extra effort. But your mileage may vary.

Re: Switching to Elixir

#185
post #161

Earlier quoted context omitted.

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.

Yes, that is my point. In order to demonstrate experience you really need to show work on something that justified Erlang, not just that you understand the syntax of Elixir and the basics of working with the Erlang VM. And usually a "weekend project" does not qualify (though that really depends on the project).

But I do think most companies that are looking for Elixir experience would be happy with your weekend project if was actually used by people in a way where Elixir could shine.

Re: Switching to Elixir

#186

>A few months ago I started a new job at a company that uses Elixir as its main language >I've never written a line of Elixir or Erlang before in my life How is this possible?

My company hires non-Elixir developers for Elixir roles too. The candidates with experience are just far too hard to find.

Re: Switching to Elixir

#188

>A few months ago I started a new job at a company that uses Elixir as its main language >I've never written a line of Elixir or Erlang before in my life How is this possible?

I've hired a number of people to write Elixr who were skilled and eager but hadn't used it before.

Re: Switching to Elixir

#189

elixir is awful, mid-long term. you write mix new something. it generates tons of code which will NEVER be update when the template gets update for new people running mix new something. then all the liveview magic happens with JavaScript code writen by someone who will not be there when major browser security model changes happen (and google make sure these happens every 3mo). then who will keep updating the magic js…

LiveView just uses websockets to push diffs to Morphdom. It's not really much more complicated than that.

Re: Switching to Elixir

#190

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 does slow some of us down. It's not really about terseness. I can write code that works on all primitives that might be sent down pretty easily. That code, sometimes is longer than limiting the inputs by types would be. I can also write code such that it only runs if the structure of the data is as required for that code to run, allowing for nulls or missing nested objects.

These two patterns allow you to write most code, type free, that gracefully handles anything you throw at it while always doing the right thing.

Making changes to such a system is easy and friction free.

Not many type advocates speak of the downsides of type systems, always pitching the net win and ignoring the actual cons.

When you refactor, make a change, or try to add new functionality, and end up fighting the type checker. That's friction to change you are experiencing and that experience is optional.

I get that having discipline in code patterns and the required robustness is a difficult ask at some organizations and some devs. In that circumstance it's better to have a minder in a type system that enforces base the conventions for everyone.

Post reply on HN