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