8 ms·

> Boring is good. Boring is stable. Boring means being able to focus on your work, not on what’s different about Go. This really resonates with me. I work with

> Boring is good. Boring is stable. Boring means being able to focus on your work, not on what’s different about Go. This really resonates with me. I work with NodeJS and the JS ecosystem in general on my day job and I have to tell you, the struggle is real. The ecosystem is fragmented, everyone is doing their own thing, which is hard to make things stable. Don’t get me wrong, I still enjoy this work, but I really wish the JS ecosystem could have a stable modern foundation we could rely on.

hermanradtke 3y ago
The JS eco-system (npm, React, etc)? Sure. Let us also acknowledge that JavaScript, the language, has been prioritizing backwards compatibility before golang even existed.
- ilyt 3y ago
  Well, it is a bit easier if you have no stdlib to speak of
  - trhhowaway232 3y ago
    JS has a stdlib, there's just nothing in it.
devjab 3y ago
JavaScript is famously backwards compatible. That’s exactly why it’s the mess you describe.
afavour 3y ago
> I really wish the JS ecosystem could have a stable modern foundation we could rely on. I actually think we do now. ES modules, ES2020 code. Both supported by Node and major browsers. Node even has a built in test runner now! The problem is getting everyone up to this bar. Once we’re there I think things are going to feel a lot better. I think part of the problem is that the JS ecosystem also encompasses frontend UI work and there are so many different applications for it that multiple implementations is inevitable. Desirable, even.
deleted 3y ago
[deleted]
KronisLV 3y ago
I wonder why Go isn't the new Java/.NET (yet?). Clearly a lot of tools and APIs have been written in it, many would describe not needing a separate runtime on the target system as a big plus and the language seems simple enough to learn and utilize (with VSC support and GoLand both being good), even the typical complaints like the error handling don't seem like dealbreakers. I wonder what's missing for Go to become a mainstay of development for the decades to come, or at least take up a huge chunk of the job market instead of being considered a niche language in some places.
- deleted 3y ago
  [deleted]
- gen220 3y ago
  I think Go is on that Java/.NET adoption curve, but it's climbing it slowly because backend programming, as a whole, is a lot bigger, mature and diverse today, than it was when Java/.NET emerged. I think there's a decent chance that, `[java.age - go.age = 15 years]` from today, Go is high up on the totem pole. From my perspective, its ecosystem is vibrant but still young – we still need to decide on the Go equivalent of Flask, Django, Spring, etc.
  - guggle 3y ago
    There are plenty of Flask equivalent in Go IMO. Django... not so much.
    - gen220 3y ago
      Yep! I think, at this stage, `plenty` is the point of my comment. While there are many competing and quality options (vibrant), none of them are the de facto leader (young). I think, given where we are in 2023, it'd be difficult for a Django (i.e. ORM + templates + web framework all-in-one) to emerge in Go – it's possible we never end up with one, and that's OK. [I don't think there's much stomach for good people to work on sprawling projects like that anymore – we're in an season of backend development that favors separation (vs bundling) of concerns, from my perspective]. I'm not sure if it's a unique feature of the Go ecosystem that there isn't one clear winner in the "minimalist + pluggable web framework" or "ORM" categories, or if we just need to wait for the winner to emerge. Ironically, I think the quality of `net/http` and `database/sql` might have been an anti-catalyst for the development of leading libraries in those verticals.

hermanradtke 3y ago

The JS eco-system (npm, React, etc)? Sure. Let us also acknowledge that JavaScript, the language, has been prioritizing backwards compatibility before golang even existed.

ilyt 3y ago
Well, it is a bit easier if you have no stdlib to speak of
- trhhowaway232 3y ago
  JS has a stdlib, there's just nothing in it.

devjab 3y ago

JavaScript is famously backwards compatible. That’s exactly why it’s the mess you describe.

afavour 3y ago

> I really wish the JS ecosystem could have a stable modern foundation we could rely on. I actually think we do now. ES modules, ES2020 code. Both supported by Node and major browsers. Node even has a built in test runner now! The problem is getting everyone up to this bar. Once we’re there I think things are going to feel a lot better. I think part of the problem is that the JS ecosystem also encompasses frontend UI work and there are so many different applications for it that multiple implementations is inevitable. Desirable, even.

deleted 3y ago

[deleted]

KronisLV 3y ago

I wonder why Go isn't the new Java/.NET (yet?). Clearly a lot of tools and APIs have been written in it, many would describe not needing a separate runtime on the target system as a big plus and the language seems simple enough to learn and utilize (with VSC support and GoLand both being good), even the typical complaints like the error handling don't seem like dealbreakers. I wonder what's missing for Go to become a mainstay of development for the decades to come, or at least take up a huge chunk of the job market instead of being considered a niche language in some places.

deleted 3y ago
[deleted]
gen220 3y ago
I think Go is on that Java/.NET adoption curve, but it's climbing it slowly because backend programming, as a whole, is a lot bigger, mature and diverse today, than it was when Java/.NET emerged. I think there's a decent chance that, `[java.age - go.age = 15 years]` from today, Go is high up on the totem pole. From my perspective, its ecosystem is vibrant but still young – we still need to decide on the Go equivalent of Flask, Django, Spring, etc.
- guggle 3y ago
  There are plenty of Flask equivalent in Go IMO. Django... not so much.
  - gen220 3y ago
    Yep! I think, at this stage, `plenty` is the point of my comment. While there are many competing and quality options (vibrant), none of them are the de facto leader (young). I think, given where we are in 2023, it'd be difficult for a Django (i.e. ORM + templates + web framework all-in-one) to emerge in Go – it's possible we never end up with one, and that's OK. [I don't think there's much stomach for good people to work on sprawling projects like that anymore – we're in an season of backend development that favors separation (vs bundling) of concerns, from my perspective]. I'm not sure if it's a unique feature of the Go ecosystem that there isn't one clear winner in the "minimalist + pluggable web framework" or "ORM" categories, or if we just need to wait for the winner to emerge. Ironically, I think the quality of `net/http` and `database/sql` might have been an anti-catalyst for the development of leading libraries in those verticals.