Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switching to Elixir

leemeichin.com

Post reply on HN
Print view View original

111–120 of 283 posts

Re: Switching to Elixir

#111

Post by knallfrosch »

mijamo wrote: post #85
byhemechi wrote: post #34

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 think it vastly depends what you're writing. Any kind of function that does not have a fixed input and output gets a lot more complex with static types. And by extension any code that depends on that also gets more complex. I tried at some point to use Rust for an API but then I depended on making calls to a very complex API. In JavaScript I would have just gotten back a complex object where I can then pick whateve…

> Any kind of function that does not have a fixed input and output gets a lot more complex with static types.

If you don't know what kind of data people give your function and you don't know what's supposed to happen, how can you write that function? I think many people use too strict of a type system. If your function works with any object that has a toString()->string function, then just write an in-line interface that defines it.

I actually love TypeScript here. It allows for `any` if you're prototyping, lazy or simply don't care. It allows mapped types, where the next dev can see how a type came into being - for example, Mutable, Readonly, Required, Partial. The names actually speak for themselves! And it eliminates the Java-style verbosity of creating classes and files all just for a type.

Re: Switching to Elixir

#112

Post by jddj »

byhemechi wrote: post #34

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…

Better type inference is faster than more ceremony, but more ceremony is faster than nothing at all, in moderately complex projects.

Re: Switching to Elixir

#113

Post by di4na »

Champagn3Papi wrote: post #108
thibaut_barrere wrote: post #79

Earlier quoted context omitted.

> There is a huge risk in niche languages and platforms. Hard to hire for, hard to find libraries for, hard to find blogs/tutorials/etc. There is a real need to push Elixir outside its initial circles and it's being done a bit at the moment (I feel). Both Chris & José are doing a lot of work for exposure outside the initial Elixir circles, and some people in the community are doing the same at their own levels. Hirin…

I switched jobs and working as an elixir dev now. I love elixir don't get me wrong, but some of the documentation especially some of the more advanced features in ecto are very confusing. It doesn't help you can define your ecto instructions in multiple flavors too (inline vs piping) You can't mix inline with pipe operators without creating an additiona variable too hold the original query. If we want to make it less…

Ecto documentation is definitely i think one of our weakest point.

Which is great on one hand, because it means we are quite above the average stack in term of onboarding and doc.

But also really makes ecto documentation and onboarding a visible sore point in the middle of the rest.

Sadly i do not have solutions rn but if people have ideas please come offer them.

Re: Switching to Elixir

#114

Post by mhitza »

knallfrosch wrote: post #111
mijamo wrote: post #85

Earlier quoted context omitted.

I think it vastly depends what you're writing. Any kind of function that does not have a fixed input and output gets a lot more complex with static types. And by extension any code that depends on that also gets more complex. I tried at some point to use Rust for an API but then I depended on making calls to a very complex API. In JavaScript I would have just gotten back a complex object where I can then pick whateve…

> Any kind of function that does not have a fixed input and output gets a lot more complex with static types. If you don't know what kind of data people give your function and you don't know what's supposed to happen, how can you write that function? I think many people use too strict of a type system. If your function works with any object that has a toString()->string function, then just write an in-line interface…

I prefer dynamic types when I prototype and hack on code.

I'd prefer if dynamic languages would converge to gradual typing support, and static languages to gradual dynamic support. TypeScript is an example of the later, and PHP of the former.

Re: Switching to Elixir

#115

Post by peoplefromibiza »

byhemechi wrote: post #34

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 really don't like not knowing what format data is in.

Which is orthogonal to what the type is

The shape of the data is much simpler to handle in Elixir than in, to name one, Java.

> a vast number of possible errors caught at compile time

if it's a vast number, usually it's because either:

- you're not familiar with the code base (and you'll make a vast number of other kinds of errors)

- you're making a huge refactory and you're used to rely on a compile-driven workflow, but there are so many alternative ways to handle them

> things go wrong in production

the usual wisdom applies here: static typing does not replace input validation, be it user provided data or function parameters

Re: Switching to Elixir

#116

Post by fastball »

danjac wrote: 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.

Re: Switching to Elixir

#117

Post by da39a3ee »

lawn wrote: post #103
da39a3ee wrote: post #83

> There are no classes, no instances, no inheritance I don't know anything about Elixir, but it bothers me when people claim that languages like Rust and Go are "not object oriented". If you create structs and have special syntax for defining functions that operate on instances of those structs, then those are called objects and you are doing OOP. Just because some Java people came up with a definition of OOP that sa…

And Erlang (and Elixir) is also closer to the original definition of OOP, with it's focus on message passing between processes ("objects").

Right exactly. The author implies that Elixir isn't an "OOP language" but I agree with you that (AIUI) it's almost the opposite -- it's descended from Erlang whose, AIUI, entire raison d'etre is programming in a style that is strongly oriented around objects (i.e. instances that usually represent entities in the application domain, and communicate by message passing). Immutability is orthogonal.

Re: Switching to Elixir

#118

Post by EMM_386 »

> you're not bogged down by a static type system

Maybe it's just me, and I'm not even specifically referring to this particular post ... but why is there so much "debate and discussion" (flamewars?) over static typing recently?

I am guessing this is due to a large influx of people into IT, many of whom got hired because they knew some JavaScript, "React a plus" a lot out of bootcamps and similar programs. As that sizable group ran headlong into static typing, usually via TypeScript, then the debates began.

All over Reddit, Twitter, even HN. People insisting that the verbose and confusing syntax was a "bridge-too-far" and one they would not cross, even if the reasons came down to "it looks weird" or "don't have to 'compile' JavaScript".

Maybe, spending too much heads-down time over the last ... whatever decades at this point ... I simply don't get it.

Don't get it similar to what I quoted here ... "bogged down by a static type system". "Bogged down", in what way?

I spend my days mixed between everything from C# to JavaScript, almost polar opposites. And the rest of it usually in TypeScript.

I do not get this feeling of being "bogged down" by static typing .... ever? I don't recall it being an issue, even though I spent hours in statically typed lanagues yesterday alone. Maybe if you are the author of a complex JS library that has to be shoe-horned into TypeScript ... yes, maybe.

What I did experience recently was being able to remove a parameter from a function, actually compile with the intent it will fail, see it fail, double click on some things and fix the 17 callers to that method I just changed the signature of, and then a minute or so later after fixing those call sites, I was back to work.

Yet, over on the social sites, the debate rages on. Open source projects removing TypeScript practically overnight for "reasons". Questions such as "how many type issues did you run into before switching to TypeScript", leaving me to wonder if that is even a rational question.

And then on the flipside, "TypeScript is the greatest language ever", heart emojis being sent to it, "If you are a JS dev you need to be using TS".

It's all strange to me, having used JavaScript for the first time back in 1996.

I'm convinced it was this wave of JavaScript devs crashing into new requirements to use TypeScript that started it.

It will sort itself out here at some point.

Re: Switching to Elixir

#119

Post by Dowwie »

byhemechi wrote: post #34

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.

Re: Switching to Elixir

#120

Post by josephg »

wofo wrote: post #107
byhemechi wrote: post #34

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…

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…

I’ve swapped back and forth between static and dynamic types a few times in my career. Java and C/C++ to JavaScript (and coffeescript) to typescript and rust. The entire time (30 years at this point) I’ve felt like whatever I was doing at the time was obviously the one true way to program. I feel that now - that what I’ve been doing lately (static typing) is clearly superior. Even for throwaway JavaScript based projects at the moment the first thing I do is install typescript.

I’m spitballing on the reason - I don’t know why it’s like this. But maybe it’s because static typing encourages you to write & plan your types first. When you know the data types, all the functions kind of flow around your types and everything feels like it obviously flows from that. With dynamic typing, it’s the reverse. I find myself writing my functions first (top down or bottom up) and then backfilling what arguments and data everything needs to pass around. I run my code a lot more as I develop it to stop bugs creeping in. And because I can run my code at any time. There’s no type checker stopping me from trying things out.

Post reply on HN