The main problem of golang compared to nodejs is that the ecology is too small, many functions need to be implemented by themselves or the existing modules are not easy to use, such as the currently known missing package: glob/fs-extra/lodash.array, at the same time, it is more focused on In terms of cli, some required packages may also be missing, such as colors/inquirejs/ora. In addition, from the language level, golang lacks generics, which is quite unfriendly to people coming from TypeScript.
Go doesn't need glob/fx-extra as the standard library already has those capabilities, it also has support for generics and there are multiple packages to do console coloring, like github.com/gookit/color
In my impression, the glob/fs api of the standard library is difficult to use, the former does not support deep matching, such as matching packages/**/package.json while ignoring node_modules, fs lacks a more convenient api, For example pathExists/readJson/writeJson etc. Also, generics are just out now, and I'm also waiting to see if someone creates a collection-related toolkit. At the moment, I can only use for of and it's hard to use. It makes me feel like I'm writing c language...
Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
The ecology of Golang is small by design. You don't want any of your app relying on 128912 dependencies. To understand what I mean, google "problem left pad javascript" ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The main problem of golang compared to nodejs is that the ecology is too small, many functions need to be implemented by themselves or the existing modules are not easy to use, such as the currently known missing package: glob/fs-extra/lodash.array, at the same time, it is more focused on In terms of cli, some required packages may also be missing, such as colors/inquirejs/ora. In addition, from the language level, golang lacks generics, which is quite unfriendly to people coming from TypeScript.
Go doesn't need glob/fx-extra as the standard library already has those capabilities, it also has support for generics and there are multiple packages to do console coloring, like github.com/gookit/color
In my impression, the glob/fs api of the standard library is difficult to use, the former does not support deep matching, such as matching
packages/**/package.json
while ignoringnode_modules
, fs lacks a more convenient api, For examplepathExists/readJson/writeJson
etc. Also, generics are just out now, and I'm also waiting to see if someone creates a collection-related toolkit. At the moment, I can only usefor of
and it's hard to use. It makes me feel like I'm writing c language...Go 1.18 is available and have generics.
The ecology of Golang is small by design. You don't want any of your app relying on 128912 dependencies. To understand what I mean, google "problem left pad javascript" ;)