5 ms·

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 la

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 infrastructure (infostructure) to more reliable typed languages happened to most of the Ruby on Rails (RoR) software unicorn stacks for examples Twitter, Airbnb and Shopify to name a few [1],[2],[3]. The main reason provided for these migration is transitioning away from monolith architecture, but almost all of the new programming languages being used are typed thus make it obvious that the untyped languages are not performant and difficult to scale even by changing the architecture. [1] Why did Twitter move away from Ruby on Rails? https://www.quora.com/Why-did-Twitter-move-away-from-Ruby-on-Rails https://www.quora.com/Why-did-Twitter-move-away-from-Ruby-on... [2] How Airbnb Scaled by Moving Away From a Rails Monolith: https://www.reddit.com/r/programming/comments/1756q7z/how_airbnb_scaled_by_moving_away_from_a_rails/ https://www.reddit.com/r/programming/comments/1756q7z/how_ai... [3] Is Shopify shifting away from Rails? https://news.ycombinator.com/item?id=33409597 https://news.ycombinator.com/item?id=33409597

lijok 4mo ago
People no can Rust so people no use Rust. Simple as.
- mountainriver 4mo ago
  I’m so happy with switching all my dev over to rust since AI coding. Everyone is lighting fast and super reliable
replwoacause 4mo ago
I've used untyped languages extensively, and even built my own, and the errors I get at runtime are almost never type-based, and that's even more true now that LLMs can pump out code. For all the additional ceremony types add, I can't say I've personally realized their benefit.
- kensai 4mo ago
  This reminds me of the analogy of the smoking grandpa. I had a grandpa that was chainsmoking his whole life and managed to reach 90 and died of other causes. This does not mean smoking is "relatively safe".
  - waffletower 4mo ago
    This analogy is absolutely absurd and inappropriate on multiple levels. It reflects a parochial mindset that can't fathom contexts where dynamic type systems can be advantageous, such as a breadth of data processing applications. My favorite irony is how dynamic languages excel at concise translation between opposing type systems -- a very common data processing scenario.
    - kensai 4mo ago
      You expand my comment to uses I had not envisioned. It was simply an analogy to correct the analogy of the OP comment.
- aeonfox 4mo ago
  I've definitely found LLM code to be syntactically/semantically correct in one-shot pretty much all the time. It's usually the functional specification/behaviour that's found wanting. Typing probably makes sense where memory-correctness needs to be enforced (e.g. Rust), and inferring those semantics require a much wider context. But memory-correctness isn't really something that afflicts BEAM languages.
- rspeele 4mo ago
  > the errors I get at runtime are almost never type-based That surprises me, but everyone's experiences are different. I've been in the statically typed language space for so long and enjoyed it so much, I find it pretty irritating to go back to Python (my long-ago favorite) but many people are in the exact opposite frame of mind. I'm curious: what kinds of errors do you classify as a type-based error? I think that varies from person to person. For example, null references. A C programmer would say dereferencing a null is not a type-based error, because it's not feasible to encode non-nullable pointers in the C type system. A Haskell programmer would say it is a type-based error because Haskell makes it difficult not to encode this in the type system, you really have to go out of your way to create a runtime null dereference error. A C# or TypeScript programmer could answer differently depending on who you ask, because both of those languages make it possible to leverage the typechecker to prevent null-deref at compile time, but neither one makes it required (you can turn those checks off or make them warnings if you like), so it depends on the programmer's build settings and how much typechecking they personally have chosen to use.
meghprkh 4mo ago
Not necessarily. Since the word "typed" language is not well-defined. For example, typescript is a fantastic language for marshalling data and UI state since it uses substructural typing instead of nominal typing. Libraries like kysely / other ORM libraries are great examples too and easy to use, whereas in fully typed languages like Rust you would end up having to use a macro library like sqlx or having to define structs for each of your types (which would increase compile time & size)
- galaxyLogic 4mo ago
  As I understand it TypeScript does not enforce types at runtime. Am I correct? If so that would signify to me it is not a "typed language", like say Java for instance. Types in TypeScript are more like "annotations" for docujmenting the program. Am I correct?
  - dnautics 4mo ago
    its statically typed, but not runtime typed!
  - abustamam 4mo ago
    I have never worked in Java. But you can certainly ship TypeScript code that does not pass typecheck and it'll run fine in the browser because the browser runs Javascript, not typescript. Obviously a decent build process will prevent code that fails typecheck from shipping, but that's not a language feature. For runtime types I've leaned on Zod or Effect schema,which can also generate static types for you.
  - bluepnume 4mo ago
    [dead]
  - tancop 4mo ago
    its more than annotations, your code fails to compile when you get a type error at least with strict settings. if it type checks and fails at runtime that means youre missing input validation or using bad declarations for third party/legacy untyped code. or using some escape hatch like `myValue as unknown as MyType` in the wrong way.
epolanski 4mo ago
I tried to get into elixir and ruby, but my mind just refuses statically untyped languages apparently. I'm even less prone to use them with AI.
dnautics 4mo ago
> is there any advantages of using untyped programming language without any evidence, i claim the corpus might have higher quality variable names and conventions that are "human crutches" around not having types. LLM knowledge in your non public codebase must be strictly local, and so checking on details and identities of types incurs a cost for the LLM to go fetch that info. if the LLM can "just know" (guess with very high confidence) then thats better for the LLM. > non-typed languages has more traning data as per anthropic "poisoning llms with 250 examples" finding, i suspect that corpus size does not really matter that much for any language that is reasonably well used.
- mikepurvis 4mo ago
  Rather than having the LLM and human devs all guessing from verbose variable names, can't they both use a language server that observes the code and can surface that kind of structure info cheaply? Part of the point of types is enforcing more of the contract at various code boundaries (function, module, etc), and that enforcement is specifically so that you don't have to keep the whole codebase in your head / context window in order to be able to work on it.
mountainriver 4mo ago
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.
- dnautics 4mo ago
  theres nothing in common between humans and llms or llm training sets!
- FeteCommuniste 4mo ago
  So the future of programming is asking an LLM to spit out the appropriate assembly?
  - tclancy 4mo ago
    No, install my punch-card.md skill to get real performance.
  - mountainriver 4mo ago
    Pretty close to it, at least Rust for now. I can't tell the difference between asking it to output Rust vs anything else at this point
- DrewADesign 4mo ago
  Yeah we’ll see how that goes when the VC subsidies run dry and everybody gets corralled into token-based pricing.
- jimbokun 4mo ago
  What will you use as training data for these new languages? LLMs are good at current programming languages because they had lots of data to train on.
- bullfightonmars 4mo ago
  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).
asa400 4mo ago
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. Ruby's runtime in the early 2000's compared poorly against the JVM or the BEAM. People used Ruby then and now because it worked well to get products to market quickly. Even after a ton of investment in Ruby's implementation, the JVM and the BEAM are still better able to handle the types of high-traffic, high-concurrency workloads those companies serve, which makes them relevant to mature, high-scale companies. Tellingly, there are dynamic language implementations that are performance-competitive with static language implementations, like Javascript's V8/Bun/Deno, Lua's LuaJIT, and Common Lisp's SBCL (among others, this is not an exclusive list).
- mixolydianagain 4mo ago
  > 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.
  - DoesntMatter22 4mo ago
    They don’t really need to be though. They take far fewer tokens and are still faster to develop with
  - asa400 4mo ago
    They absolutely are. Maybe not if the only thing you’re benchmarking is something completely CPU bound like signal processing/math, but they’re definitely competitive for tons of real use cases.
  - shakna 4mo ago
    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 https://madnight.github.io/benchmarksgame/lisp.html
elitehacker1337 4mo ago
I’ve been using Ruby and Elixir for over a decade. Pre-AI I used them for aesthetic reasons. The code was beautiful, and I disliked dealing with types. People without experience in dynamic languages tend to overestimate the number of bugs their type system is saving them from. It’s pretty rare that I run into a bug in production that a type system would have caught. They also overstate how much types help their AI agents write code. I haven’t seen AI write a type related bug in years at this point. I work with typescript on the front end, and my experience is totally different there. AI is constantly introducing type errors, but only because the original type wasn’t declared properly. Agents waste a ton of time and tokens appeasing typescript. Ruby and Elixir are very token efficient in comparison. That said, now that I am not writing code by hand anymore, I am considering switching to something like Go. Mainly so I can run my side projects on smaller machines
- DoesntMatter22 4mo ago
  I tried doing my side projects in Go and one thing I miss is the rails console which is so helpful. I guess I could have it write a go console or something but it’s not quite the same
- solumunus 4mo ago
  > It’s pretty rare that I run into a bug in production that a type system would have caught. Well yes, surely because you’re not designing your system around the type system. You need to architect your project to lean heavily on types, pattern matching, etc to actually gain the benefits. If you move a JS project to TS and just rename the files, yeah there’s going to be no difference, you must reengineer the entire codebase to leverage the type system. Personally, after moving to TS I’ve been completely sold on types and am currently planning to migrate my app to F# so I can gain even more benefit.
- epolanski 4mo ago
  C is among the most token efficient languages out there and is statically typed. Typescript is very verbose thus it cannot compete with much denser languages on token efficiency. By the way, the biggest reason many love statically typed languages, especially those that are quite expressive like TypeScript is for the domain and data modelling. Makes it easier to reason about the program and to refactor.
Gimpei 4mo ago
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.
- truncate 4mo ago
  Types are useful for squeezing more performance.
- 3836293648 4mo ago
  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.
abrookewood 4mo ago
Honestly, I think you're framing this incorrectly. Twitter, Airbnd and Shopify all managed to get massive using Ruby on Rails. Maybe that was part of the reason why? I.e. they were able to move fast and developers were happy. I don't use Rails, so don't have any skin in the game. But who cares if you have to do a re-write once you get to that size?
- sethammons 4mo ago
  Having been at a several places that have gone from framework-makes-us-fast to too-massive-for-the-framework, engineering velocity works as a function of how much mental context is needed and how many people/teams have to collaborate. As orgs grow, the only way to maintain velocity is to reduce mental context. Humans have to reason about their systems. In the half a dozen engineering orgs I have worked, each and every one became a quagmire of slow eng velocity and saw increased velocity and less bugs as they reduced context needed by teams. Separation of concerns, allowing individual services that run independently, more and better tests and observability, and, yes, better typing. Lots buy into the view "the old system got us here and now we can afford to rewrite and do things 'right'." The real cost is, literally, moths to years of dev efforts to unwind tangled concerns. Million to tens of millions in developer salaries that are going towards keeping the ship afloat as the hull is changed out. The opportunity cost is truly mind blowing. To avoid that cost: keep concerns separate, define data domains, and use a language that allows you to keep logic localized. If you have to jump files to understand your incoming parameters, you're gonna have a bad time when things no longer fit in your head, and esp. when new to the code as a new hire. Elixir, I still had to know my whole call chain to know what I could do with my incoming parameters. The more call sites, the more mental context. I choose static types because I can KNOW what my function is receiving locally: it is the type signature. I would like to validate my experience against other static typed languages like c#; so far, I have seen wins at every org that switched from dynamic languages to Go. Go seems to get a lot right for helping eng orgs move faster.
  - ken-kost 4mo ago
    > Elixir, I still had to know my whole call chain to know what I could do with my incoming parameters. The more call sites, the more mental context. but the call chain doesn't have to be long, i.e. it could be just 2 or 3 places; that fits inside my head. less is more
recroad 4mo ago
I use Elixir not because of typed/untyped, but because of BEAM and OTP.
infamia 4mo ago
> 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. The dynamic stuff is part of what slows down languages like Python and makes them tricky to optimize.
- Paracompact 4mo ago
  > 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 claim. In untyped languages, in principle every object has to be treated as dynamic.
  - infamia 4mo ago
    > 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%20language%20and%20also%20a%20strongly%20typed%20language https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...
  - 3836293648 4mo ago
    > 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.
DoesntMatter22 4mo ago
Rails is still fantastic and handles massive load. 15 percent of all US commerce uses Ruby on Rails
xlii 4mo ago
Example: https://xlii.space/eng/from-rust-to-ruby/ 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<dyn> world. Many apps don't have to live in Box<dyn> 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.
josevalim 4mo ago
> 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 struggle with). Plus they are not the only mechanism to assert correctness (they only validate a subset of your program correctness and do not replace tests) and you are still on your own when it comes to actually recovering from unexpected errors (something Erlang/Elixir were designed for). I'd say there are two flip sides to your question: 1. Given types do not replace tests, if you can use AI to automate full test coverage, are there actual benefits in static typing for coding agents? The downside of tests for humans is that we suck at writing them (but guided agents can do better) and they can take time to run (which agents do not care) 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) My gut feeling is that local structure, documentation, quality and quantity in the training data, etc are likely to play a more important role than typing for coding agents. I'd also love to measure how agents perform on specific domains. If you are writing concurrent software, how does Elixir/Java/Rust/Go compare? But without data, it's hard to say. [AutoCodeBenchmark]: https://github.com/Tencent-Hunyuan/AutoCodeBenchmark https://github.com/Tencent-Hunyuan/AutoCodeBenchmark
- osener 4mo ago
  In my experience restricting programs that can be expressed is a good thing, even more so with agentic engineering. The more guardrails there are, strong typing/TDD/computer use/..., the solution space shrinks and chance of a robust solution increases. Sure maybe this burns more tokens going in circles but it feels less like a slot machine more like a robot searching for a solution for a well-defined problem. Devs have very strong opinions about dynamically typed programming languages. But reasons such as "exploratory programming", "expressiveness", "taste" that makes them feel good to program in for humans does not matter for agents. Agents don't care that the language "limits them" and prevents them from expressing the code in a succint way because it would not type check.

lijok 4mo ago

People no can Rust so people no use Rust. Simple as.

mountainriver 4mo ago
I’m so happy with switching all my dev over to rust since AI coding. Everyone is lighting fast and super reliable

replwoacause 4mo ago

I've used untyped languages extensively, and even built my own, and the errors I get at runtime are almost never type-based, and that's even more true now that LLMs can pump out code. For all the additional ceremony types add, I can't say I've personally realized their benefit.

kensai 4mo ago
This reminds me of the analogy of the smoking grandpa. I had a grandpa that was chainsmoking his whole life and managed to reach 90 and died of other causes. This does not mean smoking is "relatively safe".
- waffletower 4mo ago
  This analogy is absolutely absurd and inappropriate on multiple levels. It reflects a parochial mindset that can't fathom contexts where dynamic type systems can be advantageous, such as a breadth of data processing applications. My favorite irony is how dynamic languages excel at concise translation between opposing type systems -- a very common data processing scenario.
  - kensai 4mo ago
    You expand my comment to uses I had not envisioned. It was simply an analogy to correct the analogy of the OP comment.
aeonfox 4mo ago
I've definitely found LLM code to be syntactically/semantically correct in one-shot pretty much all the time. It's usually the functional specification/behaviour that's found wanting. Typing probably makes sense where memory-correctness needs to be enforced (e.g. Rust), and inferring those semantics require a much wider context. But memory-correctness isn't really something that afflicts BEAM languages.
rspeele 4mo ago
> the errors I get at runtime are almost never type-based That surprises me, but everyone's experiences are different. I've been in the statically typed language space for so long and enjoyed it so much, I find it pretty irritating to go back to Python (my long-ago favorite) but many people are in the exact opposite frame of mind. I'm curious: what kinds of errors do you classify as a type-based error? I think that varies from person to person. For example, null references. A C programmer would say dereferencing a null is not a type-based error, because it's not feasible to encode non-nullable pointers in the C type system. A Haskell programmer would say it is a type-based error because Haskell makes it difficult not to encode this in the type system, you really have to go out of your way to create a runtime null dereference error. A C# or TypeScript programmer could answer differently depending on who you ask, because both of those languages make it possible to leverage the typechecker to prevent null-deref at compile time, but neither one makes it required (you can turn those checks off or make them warnings if you like), so it depends on the programmer's build settings and how much typechecking they personally have chosen to use.

meghprkh 4mo ago

Not necessarily. Since the word "typed" language is not well-defined. For example, typescript is a fantastic language for marshalling data and UI state since it uses substructural typing instead of nominal typing. Libraries like kysely / other ORM libraries are great examples too and easy to use, whereas in fully typed languages like Rust you would end up having to use a macro library like sqlx or having to define structs for each of your types (which would increase compile time & size)

galaxyLogic 4mo ago
As I understand it TypeScript does not enforce types at runtime. Am I correct? If so that would signify to me it is not a "typed language", like say Java for instance. Types in TypeScript are more like "annotations" for docujmenting the program. Am I correct?
- dnautics 4mo ago
  its statically typed, but not runtime typed!
- abustamam 4mo ago
  I have never worked in Java. But you can certainly ship TypeScript code that does not pass typecheck and it'll run fine in the browser because the browser runs Javascript, not typescript. Obviously a decent build process will prevent code that fails typecheck from shipping, but that's not a language feature. For runtime types I've leaned on Zod or Effect schema,which can also generate static types for you.
- bluepnume 4mo ago
  [dead]
- tancop 4mo ago
  its more than annotations, your code fails to compile when you get a type error at least with strict settings. if it type checks and fails at runtime that means youre missing input validation or using bad declarations for third party/legacy untyped code. or using some escape hatch like `myValue as unknown as MyType` in the wrong way.

epolanski 4mo ago

I tried to get into elixir and ruby, but my mind just refuses statically untyped languages apparently. I'm even less prone to use them with AI.

dnautics 4mo ago

> is there any advantages of using untyped programming language without any evidence, i claim the corpus might have higher quality variable names and conventions that are "human crutches" around not having types. LLM knowledge in your non public codebase must be strictly local, and so checking on details and identities of types incurs a cost for the LLM to go fetch that info. if the LLM can "just know" (guess with very high confidence) then thats better for the LLM. > non-typed languages has more traning data as per anthropic "poisoning llms with 250 examples" finding, i suspect that corpus size does not really matter that much for any language that is reasonably well used.

mikepurvis 4mo ago
Rather than having the LLM and human devs all guessing from verbose variable names, can't they both use a language server that observes the code and can surface that kind of structure info cheaply? Part of the point of types is enforcing more of the contract at various code boundaries (function, module, etc), and that enforcement is specifically so that you don't have to keep the whole codebase in your head / context window in order to be able to work on it.

mountainriver 4mo ago

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.

dnautics 4mo ago
theres nothing in common between humans and llms or llm training sets!
FeteCommuniste 4mo ago
So the future of programming is asking an LLM to spit out the appropriate assembly?
- tclancy 4mo ago
  No, install my punch-card.md skill to get real performance.
- mountainriver 4mo ago
  Pretty close to it, at least Rust for now. I can't tell the difference between asking it to output Rust vs anything else at this point
DrewADesign 4mo ago
Yeah we’ll see how that goes when the VC subsidies run dry and everybody gets corralled into token-based pricing.
jimbokun 4mo ago
What will you use as training data for these new languages? LLMs are good at current programming languages because they had lots of data to train on.
bullfightonmars 4mo ago
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).

asa400 4mo ago

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. Ruby's runtime in the early 2000's compared poorly against the JVM or the BEAM. People used Ruby then and now because it worked well to get products to market quickly. Even after a ton of investment in Ruby's implementation, the JVM and the BEAM are still better able to handle the types of high-traffic, high-concurrency workloads those companies serve, which makes them relevant to mature, high-scale companies. Tellingly, there are dynamic language implementations that are performance-competitive with static language implementations, like Javascript's V8/Bun/Deno, Lua's LuaJIT, and Common Lisp's SBCL (among others, this is not an exclusive list).

mixolydianagain 4mo ago
> 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.
- DoesntMatter22 4mo ago
  They don’t really need to be though. They take far fewer tokens and are still faster to develop with
- asa400 4mo ago
  They absolutely are. Maybe not if the only thing you’re benchmarking is something completely CPU bound like signal processing/math, but they’re definitely competitive for tons of real use cases.
- shakna 4mo ago
  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 https://madnight.github.io/benchmarksgame/lisp.html

elitehacker1337 4mo ago

I’ve been using Ruby and Elixir for over a decade. Pre-AI I used them for aesthetic reasons. The code was beautiful, and I disliked dealing with types. People without experience in dynamic languages tend to overestimate the number of bugs their type system is saving them from. It’s pretty rare that I run into a bug in production that a type system would have caught. They also overstate how much types help their AI agents write code. I haven’t seen AI write a type related bug in years at this point. I work with typescript on the front end, and my experience is totally different there. AI is constantly introducing type errors, but only because the original type wasn’t declared properly. Agents waste a ton of time and tokens appeasing typescript. Ruby and Elixir are very token efficient in comparison. That said, now that I am not writing code by hand anymore, I am considering switching to something like Go. Mainly so I can run my side projects on smaller machines

DoesntMatter22 4mo ago
I tried doing my side projects in Go and one thing I miss is the rails console which is so helpful. I guess I could have it write a go console or something but it’s not quite the same
solumunus 4mo ago
> It’s pretty rare that I run into a bug in production that a type system would have caught. Well yes, surely because you’re not designing your system around the type system. You need to architect your project to lean heavily on types, pattern matching, etc to actually gain the benefits. If you move a JS project to TS and just rename the files, yeah there’s going to be no difference, you must reengineer the entire codebase to leverage the type system. Personally, after moving to TS I’ve been completely sold on types and am currently planning to migrate my app to F# so I can gain even more benefit.
epolanski 4mo ago
C is among the most token efficient languages out there and is statically typed. Typescript is very verbose thus it cannot compete with much denser languages on token efficiency. By the way, the biggest reason many love statically typed languages, especially those that are quite expressive like TypeScript is for the domain and data modelling. Makes it easier to reason about the program and to refactor.

Gimpei 4mo ago

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.

truncate 4mo ago
Types are useful for squeezing more performance.
3836293648 4mo ago
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.

abrookewood 4mo ago

Honestly, I think you're framing this incorrectly. Twitter, Airbnd and Shopify all managed to get massive using Ruby on Rails. Maybe that was part of the reason why? I.e. they were able to move fast and developers were happy. I don't use Rails, so don't have any skin in the game. But who cares if you have to do a re-write once you get to that size?

sethammons 4mo ago
Having been at a several places that have gone from framework-makes-us-fast to too-massive-for-the-framework, engineering velocity works as a function of how much mental context is needed and how many people/teams have to collaborate. As orgs grow, the only way to maintain velocity is to reduce mental context. Humans have to reason about their systems. In the half a dozen engineering orgs I have worked, each and every one became a quagmire of slow eng velocity and saw increased velocity and less bugs as they reduced context needed by teams. Separation of concerns, allowing individual services that run independently, more and better tests and observability, and, yes, better typing. Lots buy into the view "the old system got us here and now we can afford to rewrite and do things 'right'." The real cost is, literally, moths to years of dev efforts to unwind tangled concerns. Million to tens of millions in developer salaries that are going towards keeping the ship afloat as the hull is changed out. The opportunity cost is truly mind blowing. To avoid that cost: keep concerns separate, define data domains, and use a language that allows you to keep logic localized. If you have to jump files to understand your incoming parameters, you're gonna have a bad time when things no longer fit in your head, and esp. when new to the code as a new hire. Elixir, I still had to know my whole call chain to know what I could do with my incoming parameters. The more call sites, the more mental context. I choose static types because I can KNOW what my function is receiving locally: it is the type signature. I would like to validate my experience against other static typed languages like c#; so far, I have seen wins at every org that switched from dynamic languages to Go. Go seems to get a lot right for helping eng orgs move faster.
- ken-kost 4mo ago
  > Elixir, I still had to know my whole call chain to know what I could do with my incoming parameters. The more call sites, the more mental context. but the call chain doesn't have to be long, i.e. it could be just 2 or 3 places; that fits inside my head. less is more

recroad 4mo ago

I use Elixir not because of typed/untyped, but because of BEAM and OTP.

infamia 4mo ago

> 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. The dynamic stuff is part of what slows down languages like Python and makes them tricky to optimize.

Paracompact 4mo ago
> 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 claim. In untyped languages, in principle every object has to be treated as dynamic.
- infamia 4mo ago
  > 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%20language%20and%20also%20a%20strongly%20typed%20language https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...
- 3836293648 4mo ago
  > 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.

DoesntMatter22 4mo ago

Rails is still fantastic and handles massive load. 15 percent of all US commerce uses Ruby on Rails

xlii 4mo ago

Example: https://xlii.space/eng/from-rust-to-ruby/ 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<dyn> world. Many apps don't have to live in Box<dyn> 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.

josevalim 4mo ago

> 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 struggle with). Plus they are not the only mechanism to assert correctness (they only validate a subset of your program correctness and do not replace tests) and you are still on your own when it comes to actually recovering from unexpected errors (something Erlang/Elixir were designed for). I'd say there are two flip sides to your question: 1. Given types do not replace tests, if you can use AI to automate full test coverage, are there actual benefits in static typing for coding agents? The downside of tests for humans is that we suck at writing them (but guided agents can do better) and they can take time to run (which agents do not care) 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) My gut feeling is that local structure, documentation, quality and quantity in the training data, etc are likely to play a more important role than typing for coding agents. I'd also love to measure how agents perform on specific domains. If you are writing concurrent software, how does Elixir/Java/Rust/Go compare? But without data, it's hard to say. [AutoCodeBenchmark]: https://github.com/Tencent-Hunyuan/AutoCodeBenchmark https://github.com/Tencent-Hunyuan/AutoCodeBenchmark

osener 4mo ago
In my experience restricting programs that can be expressed is a good thing, even more so with agentic engineering. The more guardrails there are, strong typing/TDD/computer use/..., the solution space shrinks and chance of a robust solution increases. Sure maybe this burns more tokens going in circles but it feels less like a slot machine more like a robot searching for a solution for a well-defined problem. Devs have very strong opinions about dynamically typed programming languages. But reasons such as "exploratory programming", "expressiveness", "taste" that makes them feel good to program in for humans does not matter for agents. Agents don't care that the language "limits them" and prevents them from expressing the code in a succint way because it would not type check.