[Animats]

- Webcrap - use Go. The arguments for Go for that use case is that 1) Google provides the libraries for most web back-end things you'll need, and since Google uses those libraries internally, even the obscure cases have been exercised, and 2) Goroutines are both low-cost and can block, so you don't have to face Rust async/thread combo hell.

- Hard problems that have concurrency, performance issues, or have to be highly reliable such as a database - use Rust.

[wbl]

I've used Go and Rust for a number of highly scaled services that you've definitely interacted with if you do something online.

In my experience Go does fine with a lot of concurrency and the GC can make some dirty lockfree tricks a lot easier. It also has a much more mature contribution story: Go test, go bench etc. work the same and proff endpoints in production are a godsend. We never really had a time we couldn't have used Go.

Rust has a slight performance advantage with some sharp edges around designing for the borrow checker, as well as much less fleshed out core set of libraries. The C interop story is better and async does work but can get messy.

Overall I think the tradeoffs are in ease of understanding, experience of team and tooling vs. the extra bit of performance, and can go either way.

[Xeoncross]

> Webcrap

Highly recommend sqlc.dev, goa.design, gokit.io, gql-gen, bind, and all the other code-generation libraries in Go.

Don't write all that code by hand. Figure out your domain objects, queries, revolvers, etc.., generate the code, then deploy it.

[tejinderss]

Why Go for web and not Typescript with nodejs/deno. The ecosystem is also huge and widely used. The type system is miles ahead of Go and is closer to rust. The async await is single threaded too.

[jpgvm]

Why use an ecosystem that needs 2-3 layers of build tooling, none of which is designed to work together when you can use any of the sane stacks instead? Not to mention the hell that is Jest, Eslint and trying to make those play with aforementioned 2-3 layers of crap. Then you also have to put up all the downsides of purely single threaded concurrent programming instead of Go M:N model which is much less prone to problems like event loop exhaustion.

Go for all it's faults has one build system/tool and spits out machine code, hell it does that probably 10x faster than just tsc can typecheck.

Personally I don't like either but Go > Typescript seems like a no-brainer unless you are hell bent on the isomorphic code thing and all the extra work that entails. i.e. making sure someone doesn't reference window in an isomorphic lib or node APIs in the opposite scenario, etc.

[Xeoncross]

Go is significantly more performant and can natively use multiple CPU cores without needing work-arounds with things like service workers. I've had to convert a few node.js services to Go to overcome raw speed issues.

Rust is even better, but not everyone wants the added complexity on their projects.

(also, I haven't worked with bun yet)

[husarcik]

I question this myself as bun.js is approaching golang speeds.

[jpgvm]

I highly doubt it's doing type checking though so you aren't going to be eliminating tsc from the picture even if you are using bun.js unless you want to just cross your fingers and hope for the best.

[postalrat]

My ide does a pretty good job saying something is wrong without using tsc.