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

191–200 of 283 posts

Re: Switching to Elixir

#191

Post by pjerem »

sph wrote: post #160
mstipetic wrote: post #156

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.

I’ve worked in a lot of languages, from PHP 3 to Rust, F# and Typescript and a lot of others. So I’m relatively educated about their differences and pretty open minded about languages but I still don’t understand why there is still a debate about this.

I mean, I can understand that some language don’t implement types and that they have other advantages (Elixir is a nice example) but I still don’t understand why no typing is still seen by some people as an advantage.

What sort of code can you write in a non-typed langage that you couldn’t write with a typed one ? Newest type systems are mostly invisible and working by inference.

The greatest example is TypeScript : you can throw any untyped Javascript at the compiler and it will still infer the types allowing you to get great auto completion and to avoid logical bugs. Why would you prefer to not have this feature ?

For me, compile time checks aren’t even the real feature, I’d even say that they are useless because they come after the real features of typed languages which is your IDE proposing auto completion that is guaranteed to work. It’s an incredible way to discover the APIs when you know that something must exist but you don’t know how it’s named.

But I’m open to be proven wrong if someone can give me practical examples in which types are counterproductive.

Re: Switching to Elixir

#192

Post by IggleSniggle »

d3ckard wrote: post #134
wofo wrote: post #107

Earlier quoted context omitted.

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

I do think types and tests have a lot of overlap. In an ideal system, you would have tests that result in progressively more narrow types as each test case is added, providing the benefit of both.

This is basically the entire reason I am so excited about Zig.

Edit: it's also the reason I have a love/hate relationship with typescript. Typescript almost lets you do this if you try really hard, but at the end of the day it's not designed to truly test your code and requires you to "cheat" in order to make the types properly describe the situation; every time you "cheat" in order to get a more expressive type (whether that's looser or narrower), you would have been better off writing a test instead.

Re: Switching to Elixir

#193

Post by IggleSniggle »

mejutoco wrote: post #146
d3ckard wrote: post #134

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…

I mostly agree with you. Just wanted to add that in some languages, for example in Typescript, there are ways to say that you do not care about the type for prototyping. For example using :unknown or :any.

:unknown is great, but the problems come in the middle area; when you have lots of very tight types and are prototyping something that makes use of those things, :unknown doesn't work, and :any can be too expressive, even for your prototype.

Re: Switching to Elixir

#194

Post by IggleSniggle »

josephg wrote: post #120
wofo wrote: post #107

Earlier quoted context omitted.

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

I've recently found a great middle ground for this, using esbuild to drive code as I'm writing it, while my IDE may meanwhile be complaining that all my types are broken. Getting comfortable having "broken" types while something is still in development is a nice middle ground, helping you come back to the hot spots whenever you're ready, and acting as a forcing function prior to commit or push.

Re: Switching to Elixir

#195

Post by swader999 »

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…

The only way I've seen it work (rarely) long term is with extensive unit tests and that takes incredible discipline.

Re: Switching to Elixir

#196

Post by mstipetic »

pjerem wrote: post #191
sph wrote: 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.

I’ve worked in a lot of languages, from PHP 3 to Rust, F# and Typescript and a lot of others. So I’m relatively educated about their differences and pretty open minded about languages but I still don’t understand why there is still a debate about this. I mean, I can understand that some language don’t implement types and that they have other advantages (Elixir is a nice example) but I still don’t understand why no ty…

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.

Re: Switching to Elixir

#197

Post by macintux »

riffraff wrote: post #82
jb3689 wrote: post #76

Earlier quoted context omitted.

You are overthinking some of it at least when it comes to concurrency. Look at what a process is and how send works. GenServer is a natural generalization of a pattern you’d write a thousand times. Knowledge of actors is transferable. Go has libraries which implement actor abstractions for example. Process mailboxes are just message queues like Go’s channels are. There are differences with respect to how the interpre…

Why do you think riak was well ahead of its time? (actual question, I'm not arguing) IIRC it was a few years after the dynamo paper came out, and at a time when a bunch of other nosql+high scalability solutions did (e.g. Cassandra)

I suspect the parent comment is primarily referring to Riak Core, which was another layer of abstraction above Erlang’s OTP for distributed processing.

Riak the database used Riak Core, but it could be used independently of the database.

I hadn’t thought about Core in a long time, I should take another look.

Looks like someone is carrying the idea forward: https://riak-core-lite.github.io/

Re: Switching to Elixir

#198

Post by leoedin »

MatthiasPortzel wrote: post #167
aerhardt wrote: post #157

Earlier quoted context omitted.

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

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

Is that not how everyone writes static typed code? You have a need for a variable holding some data, you think about the bounds of that data, you pick a type. What other way would you do it?

The problem with dynamic typing isn't in the first-write. It's all in your head then. It's in the 2 year later bugfix, when you're looking at a function and wondering what kind of data is being passed into it. And then you find all the places that call that function and still can't work out what fields that object will have, or whether they're numbers or strings.

Re: Switching to Elixir

#199

Post by keep_reading »

prophesi wrote: post #178
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…

Does José need to write up an elixir-lang.org blog post every other week on the status of their type system project for HN's collective memory to know it's in the works?

While you're waiting for official support in the language, just properly document functions with @spec and change them to @spec! after adding TypeCheck to your project and viola, you get powerful type checking at runtime with almost no performance impact. The error messages it produces are so beautiful.

https://github.com/Qqwy/elixir-type_check

Re: Switching to Elixir

#200

Post by Munksgaard »

pleoxy wrote: post #190
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…

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

> 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'm not sure exactly what you're saying. If your language is strongly typed, you'll get type errors no matter what. The only difference is whether the type errors happen at compile time or run time. Let's take a hypothetical example:

Let's say I have a programming language called Foo. There are two ways to run programs written in Foo, using the interpreters A and B. A and B are identical, except for that fact that on startup, A will check that the given program is well-typed (static type checking), while B defers such checks to runtime (dynamic type checking).

Given a well-typed program X, I can run X with A or B without ever encountering a type error. Now, I make some changes, like you suggest, and I attempt to run it again. If the resulting code is not well-typed, I will immediately know when trying to run it with A, but with B I have to be lucky enough to hit the specific case that isn't well-typed.

If I understand you correctly, you're saying that you can easily make changes in a dynamic language without _ever_ causing run-time type errors. If that's the case, you would have _exactly_ the same experience whether you ran your code using A or B.

Post reply on HN