Ask HN: Could Go become a first class web citizen?

I haven't touched Go in about 10 or 15 years, but with the recent announcement from the TypeScript team, I started to look into it more again, and it seems most of the issues I had with it have since been fixed. And one of the key takeaways from that announcement for me was that status quo Go is about 10x faster than the most optimizable JS you could write.

This got me thinking, Anders and the TS team are probably going to offer upstream some significant contributions to the Go toolchain and language (for their own sake of course, but it benefits everyone) and Go will get even faster and evolve a better type system. And the gap between clean JavaScript and vanilla Go is likely to get smaller and smaller, in terms of semantics. (I just learned a week ago that there's a struct proposal for JS.)

How do you see this going over the next 15 years? I wondered about 10 years ago if TypeScript would ever become part of JS, and that's starting to come true with the type-annotations proposal. Is it possible that the bridge between JS and Go will just shrink? That JS will evolve into Go? That WASM's ergonomics will evolve to make third party languages more "naturalized" citizens, with almost nothing getting between an e.g. Go module and a JS module or differentiating them except the file extension?

What do you all think?

2 points | by 90s_dev 8 hours ago

4 comments

  • thesuperbigfrog 8 hours ago
    I am in favor of making WASM a first class citizen, that is, WASM APIs to interact with the browser so that JavaScript is not needed.

    Once that happens, any language that compiles to WASM can be "first class": Go, Rust, whatever you want, even C.

  • jasonthorsness 8 hours ago
    Go is great for handling raw buffers and thus non-text protocols, and it has some great benchmarking, testing, and profiling tools. I think it definitely gets a little more awkward at the "handling JSON" layer compared to Node or even C#.

    But taking a step back, I don't think the TypeScript team's usage of Go for their compiler provides much support for using Go in any general web scenario: their decision was carefully made for their somewhat unique situation and the code style of their existing TypeScript code.

  • benoau 8 hours ago
    I have always wished TypeScript would just be built-in because it would eliminate build steps and processes and a massive chain of fluff that makes building and rebuilding and starting and restarting so much slower. It's hard to believe it didn't happen and very disappointing for both browser and NodeJS.

    I certainly don't think Go is in a better position to achieve this.

    [-]
    • 90s_dev 8 hours ago
      If you notice from the last tc39 conversation about the types proposal, there's a bit of tension where people are reasonably asking, should we really be stuffing more and more compilation into the browser? At what point do they push back and say, let the developer compile as much as they can ahead of time? I think wasm really has that advantage, that it forces us to do so, and saves time and resources in the user's browser. I'm not sure what the right balance is, though. I've wanted TypeScript in the browser for ages. But I see their point.
      [-]
      • benoau 6 hours ago
        I think the right balance is offering choice. Code compiling might take a moment just like shit code takes a moment, bloated code takes a moment, bad developers take a moment, bad software takes a moment, seems arbitrary to decide TS is one moment too many.

        But more importantly, seems impossible that anything could join the web stack because every other language is certainly a much more complicated proposal.