3 ms·

Serious question: Why is everyone still using JavaScript to AI-code projects? You can vibe-code apps with real languages now. There's no reason to use an inter

Serious question: Why is everyone still using JavaScript to AI-code projects? You can vibe-code apps with real languages now. There's no reason to use an interpreted, bloated, weird language anymore. The only reason interpreted languages were a thing was so you could edit a file and re-run it immediately without a compile step. Compiling is now cheap, and you don't have to build expertise in a new language anymore. Ask AI to write your app in Go, it'll happily comply. Run it and it's faster with less memory use and disk space. The code is simpler and smaller making reviewing easier. Distribution is as easy as "copy the file". I'll grant you, interpreted languages skip the "portability" compiling/distributing step, and let you avoid the stupid MacOS code signing. But Go is stupid easy to cross-compile, and (afaik?) the user can un-quarantine a self-signed app pretty easily.

nikcub 7mo ago
a) llms are good at writing typescript b) typescript fixed a lot about javascript and is somewhat decent c) multiple fast and performant runtime engines d) deployment story is php levels of easy that's it.
- Yokohiii 7mo ago
  > d) deployment story is php levels of easy Yeah just invalidate the SSR cluster for your tiny footer update and let it prewarm until coffee break. Easy.
boredtofears 7mo ago
Do LLM's not benefit from the abstractions higher level languages like Javascript/node offer? Perhaps I'm speaking out of depth because I haven't done a lot of Golang, but I've always thought of it as a systems language first, which means by necessity you have you to handle lower level problems yourself. I'm sure there's plenty of libraries that paper over this - but the philosophy of the languages themselves is different. Javascript was designed to solve CRUD like interfaces/problems quite well. Maybe this is just an outdated argument though that isn't really relevant with modern golang/rust though.
- 0xbadcafebee 7mo ago
  You can implement apps in any popular language you want with modern LLMs (they still need to be trained on that language). Tell it what to write and it'll do it. But the downside is, if the language is a memory hog or takes up tons of disk space, you're not gaining anything. If you don't have to manually write the code yourself, you might as well pick a language that has the fewest problems when executed. Go has a really solid standard library which removes a lot of what you'd typically implement separately. You don't solve lower level problems because the language already solved it. Nodejs has the opposite issue, where there's virtually nothing standard, so people made libraries to implement 5 lines of code. Rust also has a minimal standard library, and is more complex than Go. If you want a dead-simple, batteries-included compiled programming language, Go is pretty much it. Since you write less code with Go, there's less context use, so actually, the LLM has an easier time with Go apps. It started as a 'systems language' but it has many projects that extend its usefulness. There are two separate frameworks that let you write one Go app and compile it as an Android app, iOS app, Mac app, Windows app, Linux app, both GUI and console. It has multiple web frameworks, and one is even an Electron replacement. The thing it doesn't have is a REPL.
dbbk 7mo ago
Like it or not, it's the only language that'll cross over web backend, web frontend, iOS, Android, TV, Windows, Mac, et al. And with something like tRPC your data being fully end-to-end typesafe too.
theLiminator 7mo ago
Yeah, my theory is that Rust is going to be a somewhat "local optima" for a while for LLMs. LLMs have a couple major problem, they hallucinate and make mistakes. So the ideal way to use them is to constrain them as much as possible with formal methods. Rust's type system is a formal proof of some forms of correctness, this will let "vibe-coding" work to a much higher degree than with other languages. In the very long run, I suspect that all vibe-coding will actually occur in a language with dependent types and we'll push as much as possible into being proven correct at compile-time. Since the cost of generating code is plummeting, and thus the sheer volume of code will be exponentially rising, this is the only way to prevent an unsurmountable mountain of errors. Formal methods and LLMs are a match made in heaven.
znort_ 7mo ago
> with real languages now. how is javascript not a real language? > There's no reason to use an interpreted there are loads and loads of reasons to use "interpreted" languages. that you can't think of even a single one while still pretending to be knowledgeable in the field is really intriguing. > bloated, weird language oh, i see, this is all just a religious rant. carry on!
- 0xbadcafebee 7mo ago
  Typescript is legitimately weird. You start off with Javascript, a language made to validate HTML forms. Then you implement a bytecode compiler so it's not unusably slow and buggy. Then you implement "frameworks" to try to make it create real applications across the insane platform that is the web browser. After twisting yourself into a pretzel just to avoid learning or making a new language, you finally invent another language on top of the first one just so you can have types. To top it all off, it takes up tons of memory and disk space. (I don't mention the slowness because I take it for granted, but 5x-10x slower than Go code is still worth considering)
  - znort_ 7mo ago
    i'm not a fan of ts either, but can see the appeal for business. of course it is bolted on ... like almost everything on the web, which is a complete frankenstein. but it works, and truth is there is no other alternative yet. otoh it is performant and efficient enough for almost anything these days. coding in go (or whatever) and transpiling is just an extra step on top of that. not without benefits, mind! there are surely many situations where that is appropriate. but that still doesn't mean it is universally the "right thing". which brings me to: > just to avoid learning or making a new language there simply is no "one language to rule them all" nor there ought to be one. my entire career has been about learning different languages, techniques, tools, systems, environments and workflows. lots of them, nearly non stop. javascript has its nice place, and i like it vanilla, in all its weirdness and unapologetic untypedness. :)
dgb23 7mo ago
The problem with Go specifically is that it's not great for processing arbitrary JSON and especially not your typical frontend code. One issue is that you don't write Go code, you write Go plus some templating language (like html/template or go templ). Not being able to seamlessly move from regular code and template code adds friction and is limiting while developing, figuring stuff out and iterating. Another problem is that the type system is often not expressive enough for frontend code. So you either have to generate types or end up with something like map[string]any, which is awkward and gives you less guarantees and support than what dynamic languages typically offer (in other words, dynamic languages are better at being dynamic languages than Go). Now these problems don't emerge in every web UI based project, but when they do, it's really painful and limiting compared to what one is used to.
- Yokohiii 7mo ago
  > One issue is that you don't write Go code, you write Go plus some templating language (like html/template or go templ). Not being able to seamlessly move from regular code and template code adds friction and is limiting while developing, figuring stuff out and iterating. Wow that is the cheapest excuse I've heard recently. Templating languages can certainly be dogshit, but demanding it to be the native language is pretty weird. Also it's not like the JS ecosystem spawned their own weird abominations to do simple string concatenation. Sorry for being harsh, I understand that as a general inconvenience but attributing JS as superior is just bold.
  - dgb23 7mo ago
    I‘m not even a fan of JSX, but it’s simply way more productive than having a separate, idiosynchratic language for templating. The issue is not an aside or secondary. Web development is a highly competitive profession. I literally cannot afford too much development friction. There are very strong alternatives to JSX that I prefer btw. Lit-html builds on JS native template literals, the performance and bundle size is astronomically better. PHP I wouldn’t recommend anyone, because of the insane footguns, and in recent years it has become increasingly unstable, but if you already know it well, then it has a lot of properties that are missed in other ecosystems. Clojure does it best from a productivity standpoint if you own the whole stack. The REPL workflow is far ahead of anything else I tried and expressing UI as regular, compact data literals is a unique advantage. Now I like Go, and I tried it for web development, because I consider it a very high trust language and ecosystem. It just has a few disadvantages in that department when used in the trenches.
Yokohiii 7mo ago
Most coders are familiar with javascript. Javascript has the largest community. If you want to be popular, then JS or rather TS it is. But it's correct that it is odd. As long the lang is mainstream enough, it hardly matters. My assumption is that JS/TS coders have the highest resistance to switch platforms, the ecosystem is huge, it's cross BE/FE, performance isn't complete trash, everyone they know knows the platform as well. Why switch? It's a screwdriver, if your passion is to screw things, you will.
sakesun 7mo ago
Because of the runtimes (v8), I believe.
k3vinw 7mo ago
If you think that's wild just wait until you find out what programming language their AI tool was written in.

nikcub 7mo ago

a) llms are good at writing typescript b) typescript fixed a lot about javascript and is somewhat decent c) multiple fast and performant runtime engines d) deployment story is php levels of easy that's it.

Yokohiii 7mo ago
> d) deployment story is php levels of easy Yeah just invalidate the SSR cluster for your tiny footer update and let it prewarm until coffee break. Easy.

boredtofears 7mo ago

Do LLM's not benefit from the abstractions higher level languages like Javascript/node offer? Perhaps I'm speaking out of depth because I haven't done a lot of Golang, but I've always thought of it as a systems language first, which means by necessity you have you to handle lower level problems yourself. I'm sure there's plenty of libraries that paper over this - but the philosophy of the languages themselves is different. Javascript was designed to solve CRUD like interfaces/problems quite well. Maybe this is just an outdated argument though that isn't really relevant with modern golang/rust though.

0xbadcafebee 7mo ago
You can implement apps in any popular language you want with modern LLMs (they still need to be trained on that language). Tell it what to write and it'll do it. But the downside is, if the language is a memory hog or takes up tons of disk space, you're not gaining anything. If you don't have to manually write the code yourself, you might as well pick a language that has the fewest problems when executed. Go has a really solid standard library which removes a lot of what you'd typically implement separately. You don't solve lower level problems because the language already solved it. Nodejs has the opposite issue, where there's virtually nothing standard, so people made libraries to implement 5 lines of code. Rust also has a minimal standard library, and is more complex than Go. If you want a dead-simple, batteries-included compiled programming language, Go is pretty much it. Since you write less code with Go, there's less context use, so actually, the LLM has an easier time with Go apps. It started as a 'systems language' but it has many projects that extend its usefulness. There are two separate frameworks that let you write one Go app and compile it as an Android app, iOS app, Mac app, Windows app, Linux app, both GUI and console. It has multiple web frameworks, and one is even an Electron replacement. The thing it doesn't have is a REPL.

dbbk 7mo ago

Like it or not, it's the only language that'll cross over web backend, web frontend, iOS, Android, TV, Windows, Mac, et al. And with something like tRPC your data being fully end-to-end typesafe too.

theLiminator 7mo ago

Yeah, my theory is that Rust is going to be a somewhat "local optima" for a while for LLMs. LLMs have a couple major problem, they hallucinate and make mistakes. So the ideal way to use them is to constrain them as much as possible with formal methods. Rust's type system is a formal proof of some forms of correctness, this will let "vibe-coding" work to a much higher degree than with other languages. In the very long run, I suspect that all vibe-coding will actually occur in a language with dependent types and we'll push as much as possible into being proven correct at compile-time. Since the cost of generating code is plummeting, and thus the sheer volume of code will be exponentially rising, this is the only way to prevent an unsurmountable mountain of errors. Formal methods and LLMs are a match made in heaven.

znort_ 7mo ago

> with real languages now. how is javascript not a real language? > There's no reason to use an interpreted there are loads and loads of reasons to use "interpreted" languages. that you can't think of even a single one while still pretending to be knowledgeable in the field is really intriguing. > bloated, weird language oh, i see, this is all just a religious rant. carry on!

0xbadcafebee 7mo ago
Typescript is legitimately weird. You start off with Javascript, a language made to validate HTML forms. Then you implement a bytecode compiler so it's not unusably slow and buggy. Then you implement "frameworks" to try to make it create real applications across the insane platform that is the web browser. After twisting yourself into a pretzel just to avoid learning or making a new language, you finally invent another language on top of the first one just so you can have types. To top it all off, it takes up tons of memory and disk space. (I don't mention the slowness because I take it for granted, but 5x-10x slower than Go code is still worth considering)
- znort_ 7mo ago
  i'm not a fan of ts either, but can see the appeal for business. of course it is bolted on ... like almost everything on the web, which is a complete frankenstein. but it works, and truth is there is no other alternative yet. otoh it is performant and efficient enough for almost anything these days. coding in go (or whatever) and transpiling is just an extra step on top of that. not without benefits, mind! there are surely many situations where that is appropriate. but that still doesn't mean it is universally the "right thing". which brings me to: > just to avoid learning or making a new language there simply is no "one language to rule them all" nor there ought to be one. my entire career has been about learning different languages, techniques, tools, systems, environments and workflows. lots of them, nearly non stop. javascript has its nice place, and i like it vanilla, in all its weirdness and unapologetic untypedness. :)

dgb23 7mo ago

The problem with Go specifically is that it's not great for processing arbitrary JSON and especially not your typical frontend code. One issue is that you don't write Go code, you write Go plus some templating language (like html/template or go templ). Not being able to seamlessly move from regular code and template code adds friction and is limiting while developing, figuring stuff out and iterating. Another problem is that the type system is often not expressive enough for frontend code. So you either have to generate types or end up with something like map[string]any, which is awkward and gives you less guarantees and support than what dynamic languages typically offer (in other words, dynamic languages are better at being dynamic languages than Go). Now these problems don't emerge in every web UI based project, but when they do, it's really painful and limiting compared to what one is used to.

Yokohiii 7mo ago
> One issue is that you don't write Go code, you write Go plus some templating language (like html/template or go templ). Not being able to seamlessly move from regular code and template code adds friction and is limiting while developing, figuring stuff out and iterating. Wow that is the cheapest excuse I've heard recently. Templating languages can certainly be dogshit, but demanding it to be the native language is pretty weird. Also it's not like the JS ecosystem spawned their own weird abominations to do simple string concatenation. Sorry for being harsh, I understand that as a general inconvenience but attributing JS as superior is just bold.
- dgb23 7mo ago
  I‘m not even a fan of JSX, but it’s simply way more productive than having a separate, idiosynchratic language for templating. The issue is not an aside or secondary. Web development is a highly competitive profession. I literally cannot afford too much development friction. There are very strong alternatives to JSX that I prefer btw. Lit-html builds on JS native template literals, the performance and bundle size is astronomically better. PHP I wouldn’t recommend anyone, because of the insane footguns, and in recent years it has become increasingly unstable, but if you already know it well, then it has a lot of properties that are missed in other ecosystems. Clojure does it best from a productivity standpoint if you own the whole stack. The REPL workflow is far ahead of anything else I tried and expressing UI as regular, compact data literals is a unique advantage. Now I like Go, and I tried it for web development, because I consider it a very high trust language and ecosystem. It just has a few disadvantages in that department when used in the trenches.

Yokohiii 7mo ago

Most coders are familiar with javascript. Javascript has the largest community. If you want to be popular, then JS or rather TS it is. But it's correct that it is odd. As long the lang is mainstream enough, it hardly matters. My assumption is that JS/TS coders have the highest resistance to switch platforms, the ecosystem is huge, it's cross BE/FE, performance isn't complete trash, everyone they know knows the platform as well. Why switch? It's a screwdriver, if your passion is to screw things, you will.

sakesun 7mo ago

Because of the runtimes (v8), I believe.

k3vinw 7mo ago

If you think that's wild just wait until you find out what programming language their AI tool was written in.