4 ms·

I think X in Go preceded Y in Rust by several years. In short Go is a simple language with minimal syntax and explicit design patterns that make it very easy t

by tmpz22 7y ago

I think X in Go preceded Y in Rust by several years. In short Go is a simple language with minimal syntax and explicit design patterns that make it very easy to read and understand once you’ve learned the ropes. It’s a typed and compiled language with all the benefits that entails, with great concurrency support. It’s standard library is fantastic, compile times are great (one of the original goals for Go was to reduce c++ compile times at Google), with out of the box support for networked/web applications on the standard library. Finally the community for Go is very strong with things like the gophers slack channel which is insanely popular and friendly.

wadkar 7y ago
Haha, yes. Thanks, I’ll certainly check out the gophers community. As the sibling points out babel/webpack are like compilers of JavaScript world so reducing compile times have a huge impact on developer experience. I am just wondering where does the complexity of juggling various ES* standards go? Also, the webpack plugins and loads of config examples might require this project to support additional complexity. Will the compiled/typed nature of Golang make it difficult to correctly maintain parity with babel/webpack? I am really looking forward to learning golang this year. I am almost done ~~suffering~~ learning JavaScript/React + CSS3/media-queries this winter.
- tmpz22 7y ago
  Browsers lag so hard behind the ES standard that most developers are using shims provided within Babel or Typescript to use the features early. Normally you specify whatever ESNext features your using in your tsconfig, webpackconfig, babelrc, etc. I'm not sure if the implementations are always formalized such as the shim you use is identical to whatever implementation that major browsers end up going with. Ultimately you just end up bloating your bundle because you need added code in your shims for backwards compatibility of these advanced features.

by tmpz22 7y ago

wadkar 7y ago

Haha, yes. Thanks, I’ll certainly check out the gophers community. As the sibling points out babel/webpack are like compilers of JavaScript world so reducing compile times have a huge impact on developer experience. I am just wondering where does the complexity of juggling various ES* standards go? Also, the webpack plugins and loads of config examples might require this project to support additional complexity. Will the compiled/typed nature of Golang make it difficult to correctly maintain parity with babel/webpack? I am really looking forward to learning golang this year. I am almost done ~~suffering~~ learning JavaScript/React + CSS3/media-queries this winter.

tmpz22 7y ago
Browsers lag so hard behind the ES standard that most developers are using shims provided within Babel or Typescript to use the features early. Normally you specify whatever ESNext features your using in your tsconfig, webpackconfig, babelrc, etc. I'm not sure if the implementations are always formalized such as the shim you use is identical to whatever implementation that major browsers end up going with. Ultimately you just end up bloating your bundle because you need added code in your shims for backwards compatibility of these advanced features.