Funny how all these dynamically typed languages are gradually becoming typed, but none of the statically typed languages are gradually becoming untyped.
Elixir v1.20: Now a gradually typed language
331–340 of 426 posts
Re: Elixir v1.20: Now a gradually typed language
#332Earlier quoted context omitted.
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 :)
I think most people that dismiss BEAM right off the bat either don’t understand the built-in beam process/supervisor/etc. model with its inherent fault tolerance, etc, or assume its not useful because it doesn’t address their use cases.
That or it’s a evangelist from the church of AI speaking based on faith rather than reason.
Or some combination of the two.
Re: Elixir v1.20: Now a gradually typed language
#333Theres is also gleam that did this "upfront", and actully has a decent type system, im not sure if this effort is that relevant. On the flipside this is a good effort nontheless. For go there is also lisette (https://github.com/ivov/lisette/) that has a very similar dev-exp to gleam. As a bonus you get all the goodies if go and a static binary.
Lots of stuff happening in the language space at the moment.
Re: Elixir v1.20: Now a gradually typed language
#334Funny how all these dynamically typed languages are gradually becoming typed, but none of the statically typed languages are gradually becoming untyped.
You either die a hero or live long enough to become the villain
But yes types are necessary for enterprise adoption. Even more important for agentic adoption.
Re: Elixir v1.20: Now a gradually typed language
#335Funny how all these dynamically typed languages are gradually becoming typed, but none of the statically typed languages are gradually becoming untyped.
That's the any type and the moving logic into json loaded at runtime features
Re: Elixir v1.20: Now a gradually typed language
#336Between professional Elixir, Go Rust and Node over decades now I am arriving actually at OCaml now. Using LLMs to actually teach it to me.
Andd boy, a REAL type system is just something i won't ever again compromise upon. I mean yeah I did many years of Ruby/Rails and loved it back then, and Elixir in that regards at least on surface felt strictly better (sweet pattern matching, pipes, ...) but just SO MUCH CODE is written either at runtime or in loads of tests that essentially make up for the lack of a compiler guarantee about type errors i cannot unsee it anymore. Rust is way better here for example for sure, Trait system and all, but here the compile time tax is very real even after fiddling with optimal crate splits. Plus _sometimes_ a bit of simple mutable code just hits home in a few lines instead of often slower pure FP equivalents.
Happy to see that Elixir finally after years in the making is arriving somewhere, but I essentially left the ecosystem now since I really do either TDD (Type driven Development) now or quick solutions with node/go when quality isn't the concern... and now I discover OCaml (with Effects based multicore now) and yes the syntax is _a bit_ alien but damn it checks all boxes of all techstacks I ever wanted. I can write nearly Elixir style code, pattern match pipes and all, I can write (nobody does but I could) failry powerful OOP stuff, compile instantly, in a statically linked binary, with true parallelism, and a type system that is amazing (don't get me started about module functors). Beam is a impressive feat of engineering, but its also moving like molasses and deployment is nontrivial and quite cumbersome to operate (at least people need quite a lot of learning curves until theyre comfortable with this powerful beast). And then there is OCaml. And the tradeoff here is on the human side, nearly no one knows it, learning curve is high, so statistically no team would pick it in most businesses or has experience with it, and that specific situation is personally for me irrelevant now as a solo builder in an LLM age.
Lets see how good this becomes at some point, I am watching and would have loved to have this at least gradual typing available years ago!
Re: Elixir v1.20: Now a gradually typed language
#337[flagged]
Re: Elixir v1.20: Now a gradually typed language
#338Earlier quoted context omitted.
> 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? Author here. Type systems restrict which programs can be expressed and increasing expressiveness often requires increasing type-system complexity (which, speaking from experience, both humans and agents will struggl…
> 2. Do we actually have any data or evaluations that show which typing discipline is better for agents? The only benchmark I am aware of [AutoCodeBenchmark] has Elixir come first (dynamic) and C# as second (static), so it doesn't answer the question. There are other benchmarks that show dynamic languages require fewer tokens to solve problems (but that's not a metric I particularly care about) I am actually writing…
That’s very exciting! Is there anywhere I could follow you for updates? If you don’t want to share it publicly, and is ok with sharing it privately, my email is my username on gmail. Thank you!!
Re: Elixir v1.20: Now a gradually typed language
#339Honest 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…
I don’t understand this question at all. Types are there to prevent human programmers from making a certain class of mistakes. But is the same true for AI. Because if not, static types are just needless cruft.
Types always have to be checked. Either at compile time or at runtime. And if you're weakly typed you still check them to see if you use normal or backup behaviour.
If you're statically typed you can remove the actual check from the binary. They are therefore also a performance thing.
Re: Elixir v1.20: Now a gradually typed language
#340Earlier 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…
> I've not even heard of compile times being significantly slowed by type checking.
Look at Swift. But yeah, Swift is the only language I've ever heard having compile time issues because of the type checking.