Live data from Hacker News

Switching to Elixir

leemeichin.com

231–240 of 283 posts

Re: Switching to Elixir

#231

Earlier quoted context omitted.

You're creating a really difficult distributed systems problem then. What happens if the async request gets swallowed? Are you coordinating telemetry and tracing across these compute units? Not all of us can afford elaborate ops teams

Its really not that difficult to trace this stuff with modern APM tools. Datadog and Elastic APM support this out of the box for most languages/frameworks. And id be suprised if other big players in space didnt also.

Yeah that's fine but expensive for the tracing problem. You've completely ignored the harder bit which if you have any experience you know is a motherfucker of a problem: what happens if your async request fails, and notifies you, or, fails and forgets to notify you, or succeeds but takes way too long.

What sort of state management schemes do you have to put into place yo make sure your database isn't full of corrupted data that is going to crash you later (or, worse, silently violate an assumed invariant - and maybe black hole your money or your customers money)

The nice thing is that elixir gives you this either automatically or with a line or two of code.

Re: Switching to Elixir

#232

Earlier quoted context omitted.

If elixir had types, I'd use them. Right now I'm using it for functional programming aspects, coherent design across libraries, liveview, and the amazing OTP library. Those to me are much more important. With proper discipline you can get a lot of type-like behavior if you use structs to represent your data and ensure they're being passed in function args through pattern matching.

it's waiting for you {:type_check, "~> 0.13.3"}

Feels like it's still in flux/research phase

Re: Switching to Elixir

#233

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

Some companies have sanity in hiring?

I've been hired to work in Erlang without experience (although I got typecast into php stuff because I did have experience) and although the company was dependent on Erlang, we almost never hired anyone with Erlang experience. Hire smart people that are comfortable learning new things, have a project where the strength of BEAM is compelling, buy a bunch of Erlang books.

My current job is mostly Rust and I didn't know that before I started either. And seems like the team is similar. Smaller team, so I don't know have confidence in my likely to know Rust estimate.

The pool of people who are looking for a new job, and are experienced in Erlang/Elixir, and have exposure to the business specialization, and want to work for a company is very small and hard to find. Hiring companies can ask for it, but they'll have to compromise. It almost certainly doesn't hurt to apply to a job where you don't meet the stated requirements; there's likely no real penalty for having your resume tossed out, and that happens with qualified resumes too. At worst, maybe they blacklist you and won't look at your resume again ever; that's probably ok.

Same thing goes the other way, I'd have preferred an opportunity to use more Erlang, but I didn't find one that met my other needs, so I compromised and write Rust in a cloudy environment and dream about using BEAM and dist and hotloading and all that. Maybe one day.

Re: Switching to Elixir

#234

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…

[deleted]

Re: Switching to Elixir

#235

Earlier quoted context omitted.

I think loose typing helps to prototype faster, while static typing helps you write the correct/safe version faster. But part of doing the correct version is clarifying spec, and prototyping can help with that - so it is a weakly held opinion.

I could not disagree with this more. You are aided in prototyping by forming an early opinion on your data models. I would argue there's nothing more important in conceiving of something new than understanding the shape and relationships in your data. Typing does that. And nothing slows a developer down more than accruing technical debt as they build. It's like having tar stuck to your shoes. You will work the fastes…

Maybe it depends on what you're prototyping. In web dev I see what you mean.

But in game dev I'm often prototyping something to see if it works at all, or to check its performance. Ignoring types is faster when spending 1-2 hours/days quickly hammering out something that just barely works. On version 2 or 3, add typings.

Maybe it also depends on the timeframe of the prototyping project. After a few days it can become tech debt. (Though I still suspect there are some long term advantages to untyped.)

Re: Switching to Elixir

#236
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 shouldn’t be writing that in dynamic languages anyway.

Re: Switching to Elixir

#237
post #124
post #119

Earlier quoted context omitted.

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.

> This aside, I want typed elixir. It’s happening: https://elixir-lang.org/blog/2023/06/22/type-system-updates-...

They're taking baby steps with the roll-out. It's not going mainstream any time soon.

Re: Switching to Elixir

#239

Earlier quoted context omitted.

Its really not that difficult to trace this stuff with modern APM tools. Datadog and Elastic APM support this out of the box for most languages/frameworks. And id be suprised if other big players in space didnt also.

Yeah that's fine but expensive for the tracing problem. You've completely ignored the harder bit which if you have any experience you know is a motherfucker of a problem: what happens if your async request fails, and notifies you, or, fails and forgets to notify you, or succeeds but takes way too long. What sort of state management schemes do you have to put into place yo make sure your database isn't full of corrupt…

Not sure what the condescending tone is for...

I do have quite extensive experience with it. And it is a difficult problem.

Lots of frameworks/languages deal with them differently (dlqs, auto-retry, etc.), and each has its pros and cons. In addition, one should have to weigh how important each task is and determine if a 1 in million loss justifies having an extensive resiliency built in.

If Elixir has done that out of the box with a few lines of code like you say, great to hear. And Id love to try it out on day.

Re: Switching to Elixir

#240
post #160

Earlier quoted context omitted.

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.

> As if writing in Typescript would produce less buggy, more stable or more maintainable applications than using Elixir. I have news for you. A lot of people, including me, do know that catching an entire class of bugs at compile time makes your code less buggy. The trade-off as usually stated is that more things are possible with more dynamic code, and statically typed code is slower to develop with. Elixir has much…

> Elixir has much more interesting features that have nothing to do with the types/no types discussion

My point exactly. Sidetracking every Elixir discussion with complaints about type (especially when they are actually working on it!) gets tiring quick, when Elixir is much more than "just" a dynamic typed language. It's literally missing the forest for the trees.

Post reply on HN