6 ms·

I've been mostly writing Typescript the past 3 years - and recently started writing code in Go. Initially I was a little apprehensive, lack of array functions,

I've been mostly writing Typescript the past 3 years - and recently started writing code in Go. Initially I was a little apprehensive, lack of array functions, slightly less flexible type-system, etc. But after spending some time writing Go I now had to re-initialise a typescript project for a small-ish team (4-5 devs). The amount of time spent on things such as linting, selecting the correct library for server routing, the correct server, coding standards, basic error-handling and enforcing it with a custom error or Result type to get out of this nested try/catch hell which still loses the majority of errors. Setting up testing and mocking. Setting up Prisma and what not - and finally the PRs are still a hit and miss, some ok, some make use of weird JS functions.. Don't get me wrong, I really do like Typescript. But I gotta say after all of that it's just great using a language with a fantastic standard library, proper type-safety, with some coding standards built-in. It's obviously not without quirks, but it's pretty decent - and great to see that routing has now also moved into the standard library, another bit that you don't have to worry about - can't wait for some map/filter/find slice functions though!

ryloric 3y ago
Yeah, it's quite productive in a counter intuitive way, not having a ton of features just removes a lot of tiny decisions you have to make in a richer language.
KingOfCoders 3y ago
In my CTO newsletter I recently wrote about TS vs Go releases, with Go 1.22 as an example. TS gets more and more complicated with each release, catering to the power users. Go adds things that makes it simpler to use, like the (missing) range over integers. It's like game sequels, they add more and more canon and game mechanics, then game sequels (or comics) need to reset to make them more accessible to newcomers again. Programming languages can't do this, so I'm happy that Go keeps this in mind.
- pjmlp 3y ago
  The thing with Typescript is that it is only a fancy JavaScript linter, so the only way to justify newer releases is to keep adding up the type system, there is nothing else when language features that aren't type system related are supposed to come from JavaScript evolution. So they either say they are done, or keep adding type theory stuff until it implodes, I fear. Actually I am looking forward to type annotations in JavaScript now in the roadmap, being good enough for general use cases.
  - norman784 3y ago
    Do you know if the Javascript type annotations is progressing? I didn't hear anything after the initial proposal.
    - miningape 3y ago
      I don't have the source at hand but I remember seeing that they wouldn't support it until it had progressed as a JavaScript proposal. Their reasoning was that the decorations API is really weak, and it will likely be changed meaning a complete rewrite of the TypeScript decorator implementations.
    - frankjr 3y ago
      They held a meeting a few months ago so it's alive but probably still years away. https://github.com/tc39/proposal-type-annotations/issues/184 https://github.com/tc39/proposal-type-annotations/issues/184
  - WA 3y ago
    Is there a more simple JS linter that does 90% of what basic TypeScript does? I mostly use simple types (basic times, Promises, arrays, and a bunch of interfaces) and I find TypeScript valuable for that. It saved me a few times from accidentally treating a Promise<Whatever> as Whatever for example – and other things. But I heard an interesting argument: It's not TypeScript vs. vanilla JS; it is TypeScript vs. whatever else full-blown linting/IDE comfort you can get by still writing vanilla JS with no transpile step.
- ken47 3y ago
  Yes, but TS users can stay on the "type-newbie" path, which is still a huge improvement over vanilla JS and doesn't take much effort. What I've had issues with is devs who came from the vanilla JS world and love it, so they go out of their way to avoid utilizing more complex types when they would add no-cost safety (aside from the initial minutes or hour spent learning the feature).
  - Cthulhu_ 3y ago
    And that's dangerous; give people a lot of advanced options and they will inadvertedly use them, and nobody will dare to touch it, and it'll cause a lot of headaches, etc etc etc. Scala made this mistake as well. Go is the antithesis to TS and Scala, and I hope they keep it up. I also hope but doubt that they will do something few other languages dare: remove features.
    - ken47 3y ago
      Go certainly has a very different philosophy, but I don't think it's necessarily superior. Typescript is not as academic as Scala, but it gives power to developers who are willing to put in the effort to learn. With that power comes greater efficiencies and type safety.
- falsandtru 3y ago
  They just keep adding new features for fear of losing their position because they can't decorate the release notes. MS doesn't give high marks for bug fixes. Thus the bugs keep growing.
- simiones 3y ago
  All languages that keep evolving get more complex over time. The changes are always intended to make programs written in the language simpler. Go moves at a pretty slow pace, adding only minor new features (and thus minor complications) in most releases. Even in 1.22, they are previewing a new feature, range-over-functions, which seem to be basically C#/Python's iterator functions - a feature which will, of course, complicate the language - but make certain programs simpler. As a general rule, the more features a language has, the shorter program that implements a particular algorithm can be, but the harder it is to learn, and the bigger the chance that it will be misunderstood. There are exceptions where certain features make languages more verbose (e.g. access modifiers), but typically only in minor ways.
  - KingOfCoders 3y ago
    "range-over-functions" Yes, something people coming to Go would have assumed worked before looking at all range cases, but didn't.
    - simiones 3y ago
      range-over-functions is the experimental new feature where a function can generate a sequence by executing a bit at a time, i.e. s := []string{"hello", "world"} for i, x := range slices.Backward(s) { fmt.Println(i, x) } func Backward[E any](s []E) func(func(int, E) bool) { return func(yield func(int, E) bool) { for i := len(s)-1; i >= 0; i-- { if !yield(i, s[i]) { return } } } } I don't think anyone expects this to work in Go as it is today, it's just a new feature that will make the language more complex, but it will make certain kinds of programs simpler to write. I should also note that the official name is "range-over-function iterators", I called it by a wrong name earlier.
      - KingOfCoders 3y ago
        Yes might depend on where you come from. As someone with decades of Java experience - not a fancy language over most of its lifecycle - I was mystified why there is no Iterator support as in Java for loops.
- jhanschoo 3y ago
  > TS gets more and more complicated with each release, catering to the power users. My understanding about the use of advanced/more expressive TR features is that it's OK if you don't use them, and don't bother wasting time for most products. Bot if you are writing a library of framework in TS, go ahead especially since they are meant to improve the experience of consumers.
  - crowdyriver 3y ago
    every feature that makes a language more complicated will eventually hit you. It might make the typescript compiler slower, harder to refactor, your lsp might also get slower, etc...
  - KingOfCoders 3y ago
    One person on the team will use them, if you don't put up a linter that prevents usage.
cookiengineer 3y ago
I feel very similar to your experience. What made me stay in go is its amazingly unified build toolchain. The things you can do with go:embed and go:generate blow my mind in every other project. The golang.org/x package is also another thing, where there is pretty much every internet RFC related implementation available, ready to use.
- avtolik 3y ago
  Can you give some examples how are you using go:embed and go:generate?
  - bheadmaster 3y ago
    One example that comes to mind is building a single-binary full-stack application. You can use whatever frontend framework you want, and just embed the html/css/js/asset files inside the binary with go:embed. In case of dynamic set of files, you can also write a Go utility to generate the embeddings with go:generate. In addition to the ease of distribution (no more assets/ directory - just a single binary executable!), it also increases speed of the application, as it no longer has to perform file system reads in order to serve a webpage.
    - jadayesnaamsi 3y ago
      A good example of a Go project using embed to pack its html/css/js assets in a single binary is PocketBase: https://github.com/pocketbase/pocketbase/blob/master/ui/embed.go https://github.com/pocketbase/pocketbase/blob/master/ui/embe...
      - heywire 3y ago
        Last I checked, AdGuard Home also did this. https://github.com/AdguardTeam/AdGuardHome https://github.com/AdguardTeam/AdGuardHome
  - gotbeans 3y ago
    Not OP, used embedded to add ebpf code compiled for a project, helps to only ship the binary. Same thing for shipping swagger static html stuff to host an OpenAPI server.
baby 3y ago
The problem of typescript is the lack of convention and the emphasis on configuration, the reverse made Golang a great language.
lnxg33k1 3y ago
I’ve worked for a while at a client using typescript, after a while I started calling it “Tricks Driven Development”, every time I had to do something I’d read the docs, but then someone would communicate some trick not on the docs that was possible to use
hambos22 3y ago
> can't wait for some map/filter/find slice functions though Till that day comes, you could use the "lo" library (inspired from lodash). It's my goto Swiss army knife for golang projects. https://github.com/samber/lo https://github.com/samber/lo
- puika 3y ago
  On the other hand, I advise you NOT to use this kind of library and write simple, fast go code most of the time, with the occasional generics helper. Why the hell would I clutter my code with, for example: https://github.com/samber/lo?tab=readme-ov-file#fromentries-alias-frompairs https://github.com/samber/lo?tab=readme-ov-file#fromentries-...
  - c2xlZXB5Cg1 3y ago
    Klingonization of go code. I don't like it.
  - gwd 3y ago
    You wouldn't write that exact function. You'd have some complicated pipeline that ended up in a map; and it might be easier to follow the logic using map / filter / fromentries.
  - Zach_the_Lizard 3y ago
    I strongly agree. Map / filter isn't included, but a fair number of the various utilities are included in the standard library in the `slices` and `maps` packages. `context` also helps solve a bunch of the channel related use cases in a more elegant (IMO) way. There are only a handful of things in that package I wish were included, such as "Keys()" on a map.
    - mohamedattahri 3y ago
      FYI - “Keys()”, “Values()” and others have been pulled because they’re likely to be implemented using the new range-over-function paradigm. They were included in the experimental packages on google.com/x.
endtime 3y ago
I got to spend a couple years writing Dart (not Flutter) and found it to be the best of both worlds. Such an underappreciated language.
- tonis2 3y ago
  Yeah, Dart is way better / easier to debug, than Typescript in my opinion
- WuxiFingerHold 3y ago
  Interesting, Dart for backend? Do you build APIs? How is the ecosystem? I heard good thing of Swift as well, but I have concerns that it's to niche for backend stuff.
  - endtime 3y ago
    I was working on Google Assistant at the time; the dialogue manager was written in Dart. I was mostly writing libraries and platform code...so APIs in a sense. The ecosystem isn't huge outside of Flutter, of course.
__loam 3y ago
I love go. It's just so simple.
leonheld 3y ago
Go is beautiful, productive, readable. I love Go. It's my "C with niceties".
stokedmind 3y ago
Other replies miss the point - the problem doesn't lie with Typescript itself exactly. Setting up a nodejs/js project with all of the fixings (linting, Typescript, spell checks, builds if needed, etc) is quite tedious. Sure you can accept some template project or CLI tool to kickstart things if just starting out, but at some point you will need to tweak the configuration and there is an enormous realm of options. I'm surprised no one mentioned this already, but a runtime like Deno goes to great lengths to solve alot of these pain points. You get testing, linting, bundling, and Typescript out-of-the-box with sane settings. If Deno worked better with GRPC I'd probably be using it right now in my work projects!
shepherdjerred 3y ago
Deno fixes most of the issues you're describing.
Touche 3y ago
Go is the language for getting sh*t done.
- WuxiFingerHold 3y ago
  Best summary of Go. That should be the headline of the Go website.
deergomoo 3y ago
I feel the same way. I was recently evaluating TypeScript and Go for a small project at work, having little experience with either. I went with Go almost entirely because I’d made decent progress in solving the problem by the end of my timeboxed investigation period. After a similar time with TypeScript, all I’d really done was get bogged down trying to work out what tooling I should be using. Compilation, testing, and automatically formatting TypeScript all have multitudes of options with their own pros and cons. All that stuff is just built into the Go toolchain. Yeah it’s not always perfect but it’s more than good enough and, importantly, it’s ubiquitous. There’s nothing to think about or argue over. That said, I’ve been wanting to try Deno. My understanding is that it takes a much more Go-like approach to running TypeScript.
38 3y ago
> can't wait for some map/filter/find slice functions though! just use a for loop. 90% of the time the code will actually be clearer, and faster. the hoops people just through to avoid 2 extra lines of code is mind boggling.
WuxiFingerHold 3y ago
Interesting ... >> The amount of time spent on things such as linting, selecting the correct library for server routing, the correct server, coding standards, I don't fully agree here. Those points are pretty straight forward and coding standards (not formatting, for TS prettier is pretty standard, btw.) need to be defined even in Go projects. Also, Deno has much of the setting up solved. >> basic error-handling and enforcing it with a custom error or Result type to get out of this nested try/catch hell which still loses the majority of errors. Fully agreed. Maybe I have a big lack of understanding of error handling in NodeJS, but how on earth do I find out what functions can throw errors and what are the errors thrown? If someone could enlighten me I'd be really grateful. To be on the safe side I would need to run my whole code in a try..catch block. How to decide how to handle different errors if I don't know which errors can occur? On the other hand, just yesterday I had to debug a Rust panic in a smallish code base. Even with stacktraces turned on it took half an hour to find out where there error occurred. Still, Go and Rusts error handling is much better. IIRC, in Java you see all types of exceptions that can occur in the docs of a function? >> Setting up testing and mocking. Setting up Prisma Again, not a big thing IMO. If you like an ORM, Prisma is one of the best. >> Don't get me wrong, I really do like Typescript. Yeah, that's the thing. Typescript is such a fantastic language. Writing Go feels like using a hand-axe. Typescript's null handling alone makes it 10 times better (I hope everyone is using it, but that underlines your point regarding the conventions needed ...). I recently found a lib that gives us compile time checked pattern matching like in Rust.
fennecbutt 3y ago
Yeah someone I know has been banging on about go, too. I have a personal project I want to do so maybe I'll pick go for it. The main pro and con to the JS ecosystem is the fact that it's so flexible; you can mostly do things how you want and there are so many libraries in each space all competing. But because you can do anything how you like it becomes hard to decide which library you want to use (or a diff one every project) and every dev has a different way of accomplishing the same thing. I used to write internal libraries and frameworks a lot in my career and one of my mantras was to use TS to try to lock devs into doing things a certain way but there only so far you can go. My main worry with Go is like, is everything built in? Are there multiple say, Web server libs like with nodejs or only a single option? How are deficiencies addressed if there are fewer options and fewer ways og doing things?

ryloric 3y ago

Yeah, it's quite productive in a counter intuitive way, not having a ton of features just removes a lot of tiny decisions you have to make in a richer language.

KingOfCoders 3y ago

In my CTO newsletter I recently wrote about TS vs Go releases, with Go 1.22 as an example. TS gets more and more complicated with each release, catering to the power users. Go adds things that makes it simpler to use, like the (missing) range over integers. It's like game sequels, they add more and more canon and game mechanics, then game sequels (or comics) need to reset to make them more accessible to newcomers again. Programming languages can't do this, so I'm happy that Go keeps this in mind.

pjmlp 3y ago
The thing with Typescript is that it is only a fancy JavaScript linter, so the only way to justify newer releases is to keep adding up the type system, there is nothing else when language features that aren't type system related are supposed to come from JavaScript evolution. So they either say they are done, or keep adding type theory stuff until it implodes, I fear. Actually I am looking forward to type annotations in JavaScript now in the roadmap, being good enough for general use cases.
- norman784 3y ago
  Do you know if the Javascript type annotations is progressing? I didn't hear anything after the initial proposal.
  - miningape 3y ago
    I don't have the source at hand but I remember seeing that they wouldn't support it until it had progressed as a JavaScript proposal. Their reasoning was that the decorations API is really weak, and it will likely be changed meaning a complete rewrite of the TypeScript decorator implementations.
  - frankjr 3y ago
    They held a meeting a few months ago so it's alive but probably still years away. https://github.com/tc39/proposal-type-annotations/issues/184 https://github.com/tc39/proposal-type-annotations/issues/184
- WA 3y ago
  Is there a more simple JS linter that does 90% of what basic TypeScript does? I mostly use simple types (basic times, Promises, arrays, and a bunch of interfaces) and I find TypeScript valuable for that. It saved me a few times from accidentally treating a Promise<Whatever> as Whatever for example – and other things. But I heard an interesting argument: It's not TypeScript vs. vanilla JS; it is TypeScript vs. whatever else full-blown linting/IDE comfort you can get by still writing vanilla JS with no transpile step.
ken47 3y ago
Yes, but TS users can stay on the "type-newbie" path, which is still a huge improvement over vanilla JS and doesn't take much effort. What I've had issues with is devs who came from the vanilla JS world and love it, so they go out of their way to avoid utilizing more complex types when they would add no-cost safety (aside from the initial minutes or hour spent learning the feature).
- Cthulhu_ 3y ago
  And that's dangerous; give people a lot of advanced options and they will inadvertedly use them, and nobody will dare to touch it, and it'll cause a lot of headaches, etc etc etc. Scala made this mistake as well. Go is the antithesis to TS and Scala, and I hope they keep it up. I also hope but doubt that they will do something few other languages dare: remove features.
  - ken47 3y ago
    Go certainly has a very different philosophy, but I don't think it's necessarily superior. Typescript is not as academic as Scala, but it gives power to developers who are willing to put in the effort to learn. With that power comes greater efficiencies and type safety.
falsandtru 3y ago
They just keep adding new features for fear of losing their position because they can't decorate the release notes. MS doesn't give high marks for bug fixes. Thus the bugs keep growing.
simiones 3y ago
All languages that keep evolving get more complex over time. The changes are always intended to make programs written in the language simpler. Go moves at a pretty slow pace, adding only minor new features (and thus minor complications) in most releases. Even in 1.22, they are previewing a new feature, range-over-functions, which seem to be basically C#/Python's iterator functions - a feature which will, of course, complicate the language - but make certain programs simpler. As a general rule, the more features a language has, the shorter program that implements a particular algorithm can be, but the harder it is to learn, and the bigger the chance that it will be misunderstood. There are exceptions where certain features make languages more verbose (e.g. access modifiers), but typically only in minor ways.
- KingOfCoders 3y ago
  "range-over-functions" Yes, something people coming to Go would have assumed worked before looking at all range cases, but didn't.
  - simiones 3y ago
    range-over-functions is the experimental new feature where a function can generate a sequence by executing a bit at a time, i.e. s := []string{"hello", "world"} for i, x := range slices.Backward(s) { fmt.Println(i, x) } func Backward[E any](s []E) func(func(int, E) bool) { return func(yield func(int, E) bool) { for i := len(s)-1; i >= 0; i-- { if !yield(i, s[i]) { return } } } } I don't think anyone expects this to work in Go as it is today, it's just a new feature that will make the language more complex, but it will make certain kinds of programs simpler to write. I should also note that the official name is "range-over-function iterators", I called it by a wrong name earlier.
    - KingOfCoders 3y ago
      Yes might depend on where you come from. As someone with decades of Java experience - not a fancy language over most of its lifecycle - I was mystified why there is no Iterator support as in Java for loops.
jhanschoo 3y ago
> TS gets more and more complicated with each release, catering to the power users. My understanding about the use of advanced/more expressive TR features is that it's OK if you don't use them, and don't bother wasting time for most products. Bot if you are writing a library of framework in TS, go ahead especially since they are meant to improve the experience of consumers.
- crowdyriver 3y ago
  every feature that makes a language more complicated will eventually hit you. It might make the typescript compiler slower, harder to refactor, your lsp might also get slower, etc...
- KingOfCoders 3y ago
  One person on the team will use them, if you don't put up a linter that prevents usage.

cookiengineer 3y ago

I feel very similar to your experience. What made me stay in go is its amazingly unified build toolchain. The things you can do with go:embed and go:generate blow my mind in every other project. The golang.org/x package is also another thing, where there is pretty much every internet RFC related implementation available, ready to use.

avtolik 3y ago
Can you give some examples how are you using go:embed and go:generate?
- bheadmaster 3y ago
  One example that comes to mind is building a single-binary full-stack application. You can use whatever frontend framework you want, and just embed the html/css/js/asset files inside the binary with go:embed. In case of dynamic set of files, you can also write a Go utility to generate the embeddings with go:generate. In addition to the ease of distribution (no more assets/ directory - just a single binary executable!), it also increases speed of the application, as it no longer has to perform file system reads in order to serve a webpage.
  - jadayesnaamsi 3y ago
    A good example of a Go project using embed to pack its html/css/js assets in a single binary is PocketBase: https://github.com/pocketbase/pocketbase/blob/master/ui/embed.go https://github.com/pocketbase/pocketbase/blob/master/ui/embe...
    - heywire 3y ago
      Last I checked, AdGuard Home also did this. https://github.com/AdguardTeam/AdGuardHome https://github.com/AdguardTeam/AdGuardHome
- gotbeans 3y ago
  Not OP, used embedded to add ebpf code compiled for a project, helps to only ship the binary. Same thing for shipping swagger static html stuff to host an OpenAPI server.

baby 3y ago

The problem of typescript is the lack of convention and the emphasis on configuration, the reverse made Golang a great language.

lnxg33k1 3y ago

I’ve worked for a while at a client using typescript, after a while I started calling it “Tricks Driven Development”, every time I had to do something I’d read the docs, but then someone would communicate some trick not on the docs that was possible to use

hambos22 3y ago

> can't wait for some map/filter/find slice functions though Till that day comes, you could use the "lo" library (inspired from lodash). It's my goto Swiss army knife for golang projects. https://github.com/samber/lo https://github.com/samber/lo

puika 3y ago
On the other hand, I advise you NOT to use this kind of library and write simple, fast go code most of the time, with the occasional generics helper. Why the hell would I clutter my code with, for example: https://github.com/samber/lo?tab=readme-ov-file#fromentries-alias-frompairs https://github.com/samber/lo?tab=readme-ov-file#fromentries-...
- c2xlZXB5Cg1 3y ago
  Klingonization of go code. I don't like it.
- gwd 3y ago
  You wouldn't write that exact function. You'd have some complicated pipeline that ended up in a map; and it might be easier to follow the logic using map / filter / fromentries.
- Zach_the_Lizard 3y ago
  I strongly agree. Map / filter isn't included, but a fair number of the various utilities are included in the standard library in the `slices` and `maps` packages. `context` also helps solve a bunch of the channel related use cases in a more elegant (IMO) way. There are only a handful of things in that package I wish were included, such as "Keys()" on a map.
  - mohamedattahri 3y ago
    FYI - “Keys()”, “Values()” and others have been pulled because they’re likely to be implemented using the new range-over-function paradigm. They were included in the experimental packages on google.com/x.

endtime 3y ago

I got to spend a couple years writing Dart (not Flutter) and found it to be the best of both worlds. Such an underappreciated language.

tonis2 3y ago
Yeah, Dart is way better / easier to debug, than Typescript in my opinion
WuxiFingerHold 3y ago
Interesting, Dart for backend? Do you build APIs? How is the ecosystem? I heard good thing of Swift as well, but I have concerns that it's to niche for backend stuff.
- endtime 3y ago
  I was working on Google Assistant at the time; the dialogue manager was written in Dart. I was mostly writing libraries and platform code...so APIs in a sense. The ecosystem isn't huge outside of Flutter, of course.

__loam 3y ago

I love go. It's just so simple.

leonheld 3y ago

Go is beautiful, productive, readable. I love Go. It's my "C with niceties".

stokedmind 3y ago

Other replies miss the point - the problem doesn't lie with Typescript itself exactly. Setting up a nodejs/js project with all of the fixings (linting, Typescript, spell checks, builds if needed, etc) is quite tedious. Sure you can accept some template project or CLI tool to kickstart things if just starting out, but at some point you will need to tweak the configuration and there is an enormous realm of options. I'm surprised no one mentioned this already, but a runtime like Deno goes to great lengths to solve alot of these pain points. You get testing, linting, bundling, and Typescript out-of-the-box with sane settings. If Deno worked better with GRPC I'd probably be using it right now in my work projects!

shepherdjerred 3y ago

Deno fixes most of the issues you're describing.

Touche 3y ago

Go is the language for getting sh*t done.

WuxiFingerHold 3y ago
Best summary of Go. That should be the headline of the Go website.

deergomoo 3y ago

I feel the same way. I was recently evaluating TypeScript and Go for a small project at work, having little experience with either. I went with Go almost entirely because I’d made decent progress in solving the problem by the end of my timeboxed investigation period. After a similar time with TypeScript, all I’d really done was get bogged down trying to work out what tooling I should be using. Compilation, testing, and automatically formatting TypeScript all have multitudes of options with their own pros and cons. All that stuff is just built into the Go toolchain. Yeah it’s not always perfect but it’s more than good enough and, importantly, it’s ubiquitous. There’s nothing to think about or argue over. That said, I’ve been wanting to try Deno. My understanding is that it takes a much more Go-like approach to running TypeScript.

38 3y ago

> can't wait for some map/filter/find slice functions though! just use a for loop. 90% of the time the code will actually be clearer, and faster. the hoops people just through to avoid 2 extra lines of code is mind boggling.

WuxiFingerHold 3y ago

Interesting ... >> The amount of time spent on things such as linting, selecting the correct library for server routing, the correct server, coding standards, I don't fully agree here. Those points are pretty straight forward and coding standards (not formatting, for TS prettier is pretty standard, btw.) need to be defined even in Go projects. Also, Deno has much of the setting up solved. >> basic error-handling and enforcing it with a custom error or Result type to get out of this nested try/catch hell which still loses the majority of errors. Fully agreed. Maybe I have a big lack of understanding of error handling in NodeJS, but how on earth do I find out what functions can throw errors and what are the errors thrown? If someone could enlighten me I'd be really grateful. To be on the safe side I would need to run my whole code in a try..catch block. How to decide how to handle different errors if I don't know which errors can occur? On the other hand, just yesterday I had to debug a Rust panic in a smallish code base. Even with stacktraces turned on it took half an hour to find out where there error occurred. Still, Go and Rusts error handling is much better. IIRC, in Java you see all types of exceptions that can occur in the docs of a function? >> Setting up testing and mocking. Setting up Prisma Again, not a big thing IMO. If you like an ORM, Prisma is one of the best. >> Don't get me wrong, I really do like Typescript. Yeah, that's the thing. Typescript is such a fantastic language. Writing Go feels like using a hand-axe. Typescript's null handling alone makes it 10 times better (I hope everyone is using it, but that underlines your point regarding the conventions needed ...). I recently found a lib that gives us compile time checked pattern matching like in Rust.

fennecbutt 3y ago

Yeah someone I know has been banging on about go, too. I have a personal project I want to do so maybe I'll pick go for it. The main pro and con to the JS ecosystem is the fact that it's so flexible; you can mostly do things how you want and there are so many libraries in each space all competing. But because you can do anything how you like it becomes hard to decide which library you want to use (or a diff one every project) and every dev has a different way of accomplishing the same thing. I used to write internal libraries and frameworks a lot in my career and one of my mantras was to use TS to try to lock devs into doing things a certain way but there only so far you can go. My main worry with Go is like, is everything built in? Are there multiple say, Web server libs like with nodejs or only a single option? How are deficiencies addressed if there are fewer options and fewer ways og doing things?