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

Elixir v1.20: Now a gradually typed language

elixir-lang.org

Post reply on HN
Print view View original

251–260 of 426 posts

Re: Elixir v1.20: Now a gradually typed language

#251

Post by bullfightonmars »

mountainriver wrote: post #185
teleforce wrote: post #163

Honest question, in the era of vibe and AI assisted coding is there any advantages of using untyped programming languages, apart from the fact that non-typed languages has more traning data for the LLM? This probably controversial, but personally I consider untyped languages as technical debts that need to be fixed sooner or later, and the OP article is partly addressing this very issue. Rewriting critical software i…

IMO all of these higher level languages that were designed for humans have a very short lifespan at this point. The only thing propping them up seems to be loyalty for the most part.

I use rails because it makes thousands of good choices that I never have to make. If build apps the rails way I don't have to deal with a mountain of tech debt (in the form bad or ever changing choices).

Re: Elixir v1.20: Now a gradually typed language

#252

Post by goosejuice »

mountainriver wrote: post #185
teleforce wrote: post #163

Honest question, in the era of vibe and AI assisted coding is there any advantages of using untyped programming languages, apart from the fact that non-typed languages has more traning data for the LLM? This probably controversial, but personally I consider untyped languages as technical debts that need to be fixed sooner or later, and the OP article is partly addressing this very issue. Rewriting critical software i…

IMO all of these higher level languages that were designed for humans have a very short lifespan at this point. The only thing propping them up seems to be loyalty for the most part.

What lower level lang would offer the benefits the beam/otp provide? I suspect you're generalizing a bit too much and haven't thought this through :)

Re: Elixir v1.20: Now a gradually typed language

#253

Post by shakna »

mixolydianagain wrote: post #210
asa400 wrote: post #186

Earlier quoted context omitted.

This framing is misleading. I'm not sure what AI has to do with any of the examples you cited. All of the examples you cited are moves - and in some cases, not even moves, as Shopify is not ditching Ruby - to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language, and no link to AI that I can see, as these companies all significantly predate LLMs…

> to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language The runtime performance and the language are deeply linked. None of the dynamically typed runtimes you mention are actually performance competitive with JVM languages.

Luajit and SBCL are very much performance competitive with the JVM? Why do you say that they're not?

Random example benchmark: https://madnight.github.io/benchmarksgame/lisp.html

Re: Elixir v1.20: Now a gradually typed language

#254

Post by xlii »

teleforce wrote: post #163

Honest question, in the era of vibe and AI assisted coding is there any advantages of using untyped programming languages, apart from the fact that non-typed languages has more traning data for the LLM? This probably controversial, but personally I consider untyped languages as technical debts that need to be fixed sooner or later, and the OP article is partly addressing this very issue. Rewriting critical software i…

Example:

https://xlii.space/eng/from-rust-to-ruby/

The thesis that you're making is biased. Huge tech corps can move away from Rails, but it's similar to argument of "why the most successful people in the world don't drive Toyotas". Which is true, but it doesn't mean people should stop using Toyotas and buy Koenigsegg instead.

Typed languages have consequences. Some designs are either non-ergonomic or impossible. Rust: if you want to have a swappable adapter you're in Box world. Many apps don't have to live in Box at all but they need to test which is the sole reason to change architecture and wrap in boilerplate.

None of these reasons matter if you're multimillion tech corporation with unlimited resources.

But these are very important reasons to consider when you have small-medium sized team and cannot afford to fight language.

Re: Elixir v1.20: Now a gradually typed language

#255

Post by infamia »

Paracompact wrote: post #225
infamia wrote: post #209

Earlier quoted context omitted.

> Rewriting critical software infrastructure (infostructure) to more reliable typed languages Instagram (and Threads) is still using Django, which is even slower than Rails. Once you get to unicorn scale, your app is going to bespoke, with some microservices, and super custom stuff. If you can go faster in a gradually typed language, that can be a very good reason to choose one. > untyped languages are not performant…

> Typing generally slows down languages, not speed them up because of all the additional checks that must be done. Source? You seem to be talking about compile-time versus runtime, and I've not even heard of compile times being significantly slowed by type checking. > The dynamic stuff is part of what slows down languages like Python and makes them tricky to optimize. That seems to harm rather than help your previous…

> You seem to be talking about compile-time versus runtime

Yes 100%! I was talking runtime in reference to Ruby and later Python.

> That seems to harm rather than help your previous claim. In untyped languages, in principle every object has to be treated as dynamic.

It is rather confusing and even counterintuitive, but being dynamic does not mean a language must also be untyped. For example, Python is both strongly typed and dynamically typed at once. [1] It's objects have a definitive type, but you can swap out objects of any type out at any time (a=1 ... a="foo") using the same variable. That makes optimization rather tricky as you can imagine.

1 - https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...

Re: Elixir v1.20: Now a gradually typed language

#256

Post by igsomething »

isityettime wrote: post #131
keithnz wrote: post #74

seems ironic that critics were saying, it needs typing, and all the elixir fans were saying you don't need typing, you don't get bugs related to typing because elixir is somehow magic, now they get typing and it finds bugs for them.... but you said you didn't need that to prevent bugs? But good to see! I spent a bunch of time trying out Elixir a while back, I enjoyed it, but just didn't agree with the lack of types.

How did Elixir manage to attach static type checking to a language after the fact without drastically revising the type system or incurring runtime validation costs? I don't know Elixir, but I have some impression that the BEAM's famous qualities played a role: immutability, "let it crash" philosophy, no inheritance malarkey, etc. Elixir itself had to have a type system that was already relatively orderly for it to b…

One important thing that is often not mentioned is the lack of operator overloading. In Elixir if you have "a + b" it means "a" and "b" must be numbers for the code to succeed, which narrows down the possibilities significantly. Compare that to Python, where "a + b" applies to numbers, string concatenation, and any object that implements the __add__ or __radd__ magic methods, it becomes a nightmare to type.

Re: Elixir v1.20: Now a gradually typed language

#257

Post by lkuty »

7bit wrote: post #20

Found elixir intriguing and so Phoenix. Two reasons I put it aside again are: You need Beam and the Elixir. I find that really weird, because I'm used to just the language like in Python, Java, C, Rust. Not something underneath it, too. There is no debugger. The way to debug Elixir is to print stuff to the console, like 40 years ago. No thanks.

But then you have all the Erlang libraries for free which is huge. And you add to them the Elixir libraries and that gives you a lot of stuff, just like you get with languages with rich libraries e.g. Java, Ruby, ... I find it reassuring.

Re: Elixir v1.20: Now a gradually typed language

#258

Post by dns_snek »

LudwigNagasena wrote: post #138
rezonant wrote: post #128

Earlier quoted context omitted.

Once you are squarely in a Typescript program and not a "Javascript program gradually adopting Typescript", it would be a good idea to enable Strict mode which forbids implicit-any, effectively meaning the only places you can omit type declarations is where the language will infer the type. Typescript for instance does not infer types of function arguments via their usages (like Flow does), which means in strict mode…

There is @typescript-eslint/no-explicit-any.

More generally you can use "no-restricted-syntax" rule to forbid almost any type of syntax by matching AST against CSS-like selectors.

https://eslint.org/docs/latest/rules/no-restricted-syntax

https://typescript-eslint.io/play/

Re: Elixir v1.20: Now a gradually typed language

#259

Post by asa400 »

steve_adams_86 wrote: post #245
neya wrote: post #241

Earlier quoted context omitted.

If you use Phoenix, using types at the data model level using changesets and then trickling them down all the way to the UI is a very good compromise. As changesets provide type validations out of the box too.

Do changesets incur a runtime cost?

Ecto Changesets[0] are runtime constructs, yes. They're similar to libaries like Pydantic, if you're familiar with Python.

[0] - https://ecto.hexdocs.pm/Ecto.Changeset.html

Re: Elixir v1.20: Now a gradually typed language

#260

Post by dns_snek »

frollogaston wrote: post #152
jamwise wrote: post #122

Earlier quoted context omitted.

I've experienced this, but it's mostly because languages like Python and TypeScript give you way too many escape hatches. I get the intent: allow devs to convert their code base slowly. But in practice it just lets developers opt out of the benefits of typing to "save time" in the short run.

Well now Claude will add the types for me, so I don't need to use escape hatches

As long as you're fine with the types being semantic gibberish because all agents I've used take the lowest effort approach to make the error go away.

You probably have the same logical type duplicated in 3+ different places (at least partially), including inline casts using type literals like "maybeCat as { meow(): void }"

Post reply on HN