19 ms·

Golang also has some of the worst tooling because everything is based off of what comes builtin, and because they're not specialized projects, they're very limi

Golang also has some of the worst tooling because everything is based off of what comes builtin, and because they're not specialized projects, they're very limited in capability and configuration. Coming from ts, tooling like tsconfig has a lot of options, but sensible defaults can be set with a single flag like strict mode. If some org has some specialized needs, they can dive into the configuration and get what they need. With golang, not only would it be a lot for any single team to offer all those features at a decent level of polish, the golang culture in particular is very, very resistant to small bits of comfort because of dogma like "worse is better". It's kind of similar to Haskell's "avoid success at all cost".

Cthulhu_ 3y ago
TSConfig having a lot of options isn't a selling point though; you shouldn't need any of those. That said, the flags and strict mode are intended for when you have an existing "sloppy" JS codebase or mindset. You shouldn't need anything (except strict mode) in a new TS project. That said, TS is quickly becoming the antithesis of what Go tries; every release for the past few years I've seen now are all features where I'm like, "I will never need or use this". Some conveniences have been improved on - like better type inference - but that will mainly allow for cleaning up workarounds. "some orgs with specialised needs" are going to be legacy projects, either older TS versions that didn't have the features that it does now, or JS codebases. This isn't generally an issue with Go projects, most of which are greenfield. That said, there's some X to Go conversion projects that produce less than ideal code though, like usage of the `interface{}` type that at this point is a code smell.
Thaxll 3y ago
Which tools are you talking about?
dilyevsky 3y ago
I can’t believe we’re seriously comparing go polished tooling with bloatware and half baked crap in the js/ts land especially when it comes to package management and such. Also there’s a lot of go tooling that doesn’t come from go team itself because go standard library exposes first class code introspection utilities. go vet is an example of this
- icholy 3y ago
  Why spend your time coding when you could be fiddling with configuration files all day? I love re-learning how to make package.json, tsconfig, esbuild, eslint, prettier, mocha and webpack play nice every time I start a new project.
  - klabb3 3y ago
    Missing peer dependency. Have you tried nuking your node_modules?
    - mickael-kerjean 3y ago
      No I'm busy upgrading webpack and rewriting all my tests from jest to vitest
badrequest 3y ago
I've been involved in the Go community for almost 10 years, and I've never once heard anybody say "worse is better". Comparing Go's tooling to Typescript feels like a farce, especially since you've neglected to mention the horror that is npm.
cdelsolar 3y ago
No?
BillyTheKing 3y ago
This is a classic example of a 'contrarian' take for what feels like the sake of it. TS/JS tooling is a total and utter disaster at this point. The commonJS/module transition is a nightmare. The fact that something like 'prisma' exists - a c-written 'query engine' that turns prisma js into sql.. wut? This ecosystem is on a highway to hell literally.. I really hope Bun works out, because I do like Typescript, I do like programming in it - but I'm absolutely done with spending hours upon hours figuring out configs in tsconfig, jest, package.json eslintrc, prettier, vstest and whatever the next 'new' abstraction is. In Go I can just focus on the code and forget about the rest
random_mutex 3y ago
TS tooling excels at preventing you from getting work done

Cthulhu_ 3y ago

TSConfig having a lot of options isn't a selling point though; you shouldn't need any of those. That said, the flags and strict mode are intended for when you have an existing "sloppy" JS codebase or mindset. You shouldn't need anything (except strict mode) in a new TS project. That said, TS is quickly becoming the antithesis of what Go tries; every release for the past few years I've seen now are all features where I'm like, "I will never need or use this". Some conveniences have been improved on - like better type inference - but that will mainly allow for cleaning up workarounds. "some orgs with specialised needs" are going to be legacy projects, either older TS versions that didn't have the features that it does now, or JS codebases. This isn't generally an issue with Go projects, most of which are greenfield. That said, there's some X to Go conversion projects that produce less than ideal code though, like usage of the `interface{}` type that at this point is a code smell.

Thaxll 3y ago

Which tools are you talking about?

dilyevsky 3y ago

I can’t believe we’re seriously comparing go polished tooling with bloatware and half baked crap in the js/ts land especially when it comes to package management and such. Also there’s a lot of go tooling that doesn’t come from go team itself because go standard library exposes first class code introspection utilities. go vet is an example of this

icholy 3y ago
Why spend your time coding when you could be fiddling with configuration files all day? I love re-learning how to make package.json, tsconfig, esbuild, eslint, prettier, mocha and webpack play nice every time I start a new project.
- klabb3 3y ago
  Missing peer dependency. Have you tried nuking your node_modules?
  - mickael-kerjean 3y ago
    No I'm busy upgrading webpack and rewriting all my tests from jest to vitest

badrequest 3y ago

I've been involved in the Go community for almost 10 years, and I've never once heard anybody say "worse is better". Comparing Go's tooling to Typescript feels like a farce, especially since you've neglected to mention the horror that is npm.

cdelsolar 3y ago

No?

BillyTheKing 3y ago

This is a classic example of a 'contrarian' take for what feels like the sake of it. TS/JS tooling is a total and utter disaster at this point. The commonJS/module transition is a nightmare. The fact that something like 'prisma' exists - a c-written 'query engine' that turns prisma js into sql.. wut? This ecosystem is on a highway to hell literally.. I really hope Bun works out, because I do like Typescript, I do like programming in it - but I'm absolutely done with spending hours upon hours figuring out configs in tsconfig, jest, package.json eslintrc, prettier, vstest and whatever the next 'new' abstraction is. In Go I can just focus on the code and forget about the rest

random_mutex 3y ago

TS tooling excels at preventing you from getting work done