3 ms·

That's why Typescript is my hammer, unless I need a jack hammer, which is Rust. With Deno and Typescript I get an even more versatile toolbox than with Go. And

That's why Typescript is my hammer, unless I need a jack hammer, which is Rust. With Deno and Typescript I get an even more versatile toolbox than with Go. And what's even more important to me, Typescript is safer and more ergonomic than Go, but slightly slower. Rust is safer, more ergonomic and faster than Go, but much harder to learn. Especially strict (which is a must) Typescript is underrated. Compared to Go, we get: - null safety - widely supported generics - discriminated unions with either manually (some lines of code) or es-lint exhaustiveness checks - much safer concurrency, as all Typescript code runs single-threaded. You need web workers, which are not as safe as Rust for concurrency, but much safer than Go. - collection / iterator methods So far, I see only few downside. I'd be happy if people could provide more. Currently I'm scratching my head why I didn't fall in love with Typescript (for backend and CLI) earlier. Maybe I haven't seen the dark sides yet. So, some points where Go is stronger than Typescript: - Go is much more efficient in terms of size and memory usage - Go's GC is better than V8s - Go is faster on CPU bound tasks - Go has a greater std lib, however, Deno's std lib is pretty nice as well. - The ecosystem is smaller, but has not as much trash as NPM. The dependency trees with NPM are usually large. By the way, Rust has this problem as well, less than Typescript but more than Go. Still, many mainstream NPM packages are safe and rock solid. What else could we say against Typescript (and preferably Deno or Bun)? I'm really eager to hear people having ditched it an why.

scubbo 2y ago
Amen. I was unreasonably opposed to TypeScript at first after lots of bad experiences with messy JavaScript when I was first learning development - but after immersing myself in it for a year or so at $NEW_JOB, I absolutely love it. The only ways in which I can see that Go outperforms TypeScript is in performance, but frankly I don't care and most developers shouldn't - unless you're writing truly low-level high-performance utilities, you should (within reason) bias for being able to write (and iterate) fast over being able to execute fast. You can always re-write in Rust if you find that performance is a bottleneck.
- Escapado 2y ago
  I have been using typescript as my primary language for years and since I am used to it I actually enjoy it (much more than I enjoyed Java or Python in the past). And depending on what you built I agree, especially for one off scripts or if you plan on hosting just one or two things somewhere. On the other hand I recently saw a video by webdev Cody that got me thinking, where he was comparing a dead simple api server in go and in bun hosted on railway and their memory usage was different by an order of magnitude in favour of go plus you can compile your program down to a few megabytes instead of bundling a ~100megabyte runtime. So if you have a couple dozen of side projects where you host servers/apis that difference can end up in a noticeable operating cost differential. He made a few other points such as throughput, the more complete standard library and tooling such as go fmt and that writing the equivalent server in go wasn’t really all that different from the typescript code. You’re right that rewriting is always an option but for all over the place folks like me the next 3 projects are half done before I even think about optimising my hosting bill. But as I said, strongly depends on what you build. I guess there are no winners, just tradeoffs. I wonder if one use case for llms in the future could be feeding a sizeable typescript/python codebase into it and then have it spit out an equivalent in idiomatic rust/zig/c. I am aware that transpilers and assembly script and static Hermes exist but what I mean is more of a result that produces a maintainable rewritten version making use of the idiomatic libraries and coding conventions of the target language.
  - scubbo 2y ago
    Good points, thank you! I'm lucky enough that I don't really need to worry about operating cost because I self-host the few things I have built and am nowhere near maxing out my hardware, but your point is well made. Although... > writing the equivalent server in go wasn’t really all that different from the typescript code I think _that's_ true - one strength I'll absolutely concede to Go is that spinning up a basic server is very concise with the stdlib. The problem is that implementing its _logic_ is then super-verbose.
tgv 2y ago
- Typescript doesn't protect you at all against external data. - A Go program runs single-threaded, unless you explicitly tell it not too, so I don't quite see that as a plus for Typescript. - Go is quite a bit faster than Typescript. - I haven't had a versioning problem in Go, and I can still compile and run old code. Typescript still beats Python in that respect, but Go wins stability. And I say this as someone who really likes Typescript. It's a blessing for frontend browser work.
- sapiogram 2y ago
  > - A Go program runs single-threaded, unless you explicitly tell it not too, so I don't quite see that as a plus for Typescript. I don't think this is a fair comparison. Almost all software needs some kind of concurrency, and multi-threading is the only way to do concurrency in Go. For example, the http server in Go's stdlib runs each request in its own goroutine, which I guess you technically asked for, but also can't be avoided.
  - tgv 2y ago
    That means you think it's a good idea that a JS/TS server handles everything on a single thread, which doesn't sound like an advantage. BTW, you can also start multiple processes in go instead of go routines. There's probably a Worker-like library for it.
- GraduateDescent 2y ago
  If you want TS-supported deserialization, just use runtime schema validation. I don't see the issue. It's dead-simple and is the way everyone does it.
  - tgv 2y ago
    Sure that's good advice, but it was a comparison of language features.

scubbo 2y ago

Amen. I was unreasonably opposed to TypeScript at first after lots of bad experiences with messy JavaScript when I was first learning development - but after immersing myself in it for a year or so at $NEW_JOB, I absolutely love it. The only ways in which I can see that Go outperforms TypeScript is in performance, but frankly I don't care and most developers shouldn't - unless you're writing truly low-level high-performance utilities, you should (within reason) bias for being able to write (and iterate) fast over being able to execute fast. You can always re-write in Rust if you find that performance is a bottleneck.

Escapado 2y ago
I have been using typescript as my primary language for years and since I am used to it I actually enjoy it (much more than I enjoyed Java or Python in the past). And depending on what you built I agree, especially for one off scripts or if you plan on hosting just one or two things somewhere. On the other hand I recently saw a video by webdev Cody that got me thinking, where he was comparing a dead simple api server in go and in bun hosted on railway and their memory usage was different by an order of magnitude in favour of go plus you can compile your program down to a few megabytes instead of bundling a ~100megabyte runtime. So if you have a couple dozen of side projects where you host servers/apis that difference can end up in a noticeable operating cost differential. He made a few other points such as throughput, the more complete standard library and tooling such as go fmt and that writing the equivalent server in go wasn’t really all that different from the typescript code. You’re right that rewriting is always an option but for all over the place folks like me the next 3 projects are half done before I even think about optimising my hosting bill. But as I said, strongly depends on what you build. I guess there are no winners, just tradeoffs. I wonder if one use case for llms in the future could be feeding a sizeable typescript/python codebase into it and then have it spit out an equivalent in idiomatic rust/zig/c. I am aware that transpilers and assembly script and static Hermes exist but what I mean is more of a result that produces a maintainable rewritten version making use of the idiomatic libraries and coding conventions of the target language.
- scubbo 2y ago
  Good points, thank you! I'm lucky enough that I don't really need to worry about operating cost because I self-host the few things I have built and am nowhere near maxing out my hardware, but your point is well made. Although... > writing the equivalent server in go wasn’t really all that different from the typescript code I think _that's_ true - one strength I'll absolutely concede to Go is that spinning up a basic server is very concise with the stdlib. The problem is that implementing its _logic_ is then super-verbose.

tgv 2y ago

- Typescript doesn't protect you at all against external data. - A Go program runs single-threaded, unless you explicitly tell it not too, so I don't quite see that as a plus for Typescript. - Go is quite a bit faster than Typescript. - I haven't had a versioning problem in Go, and I can still compile and run old code. Typescript still beats Python in that respect, but Go wins stability. And I say this as someone who really likes Typescript. It's a blessing for frontend browser work.

sapiogram 2y ago
> - A Go program runs single-threaded, unless you explicitly tell it not too, so I don't quite see that as a plus for Typescript. I don't think this is a fair comparison. Almost all software needs some kind of concurrency, and multi-threading is the only way to do concurrency in Go. For example, the http server in Go's stdlib runs each request in its own goroutine, which I guess you technically asked for, but also can't be avoided.
- tgv 2y ago
  That means you think it's a good idea that a JS/TS server handles everything on a single thread, which doesn't sound like an advantage. BTW, you can also start multiple processes in go instead of go routines. There's probably a Worker-like library for it.
GraduateDescent 2y ago
If you want TS-supported deserialization, just use runtime schema validation. I don't see the issue. It's dead-simple and is the way everyone does it.
- tgv 2y ago
  Sure that's good advice, but it was a comparison of language features.