9 ms·

Learning Go as a Node.js Developer

82 points by skellertor 9y ago

Teeer 9y ago
Oh boy, another learning ___ as a ____ developer blog post.
- reificator 9y ago
  Counterpoint, I wish there were more resources for new languages that assume you already know how to program. Professional Javascript for Web Developers[1] is a favorite of mine, because it doesn't waste time teaching you to program and teaching you the language. Instead it points out things that will surprise you if you come from C-like languages, and things you need to watch out for. Now, since I effectively learned to program in C and later C#/Java, ___ for node developers isn't what I'm after, especially if it spends a bunch of time talking about static typing or fixed size arrays and such. But if you're going the opposite way as I did, learning the high level and transitioning to the low level, something like that could be very useful indeed. [1]: https://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691 https://www.amazon.com/Professional-JavaScript-Developers-Ni...
  - oei829ejenk3 9y ago
    I know it’s not a popular opinion with some, but all code looks like to me anymore is math with whatever symbols the language in question needs to work For example: (singleton) (tu,ple) def func1(singleton): def func2(tu,ple): ^ python function declarations So after 20 yrs of this, I try to keep in mind the math and just look up the bits to wrap it in. Also, I avoid custom frameworks and all this industry react/angular, or whatever is cool like the plague, by avoiding front end for a while now But I do consulting which affords me the luxury. Many may not have the flexibility. I’ve a set of macros in vim to scaffold boiler plate and go from there Boom, programming in any language
- dang 9y ago
  Could you please not post snarky dismissals to this site? We're trying for better than that here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html
  - Teeer 9y ago
    I'm sure you're also trying for better content. I'll continue to embrace my displeasure for posts like these, thank you very much.
    - deleted 9y ago
      [deleted]
ralusek 9y ago
Why would this author feel compelled to write an article about this if they're just learning? That asynchronous Go code which is meant to be analogous to the handful of Node lines looks super verbose. Because the author has claimed a lack of expertise, I have no idea if that is actually the correct way to write something like that out...but it certainly doesn't make Go look good.
- gouggoug 9y ago
  > Why would this author feel compelled to write an article about this if they're just learning? Why wouldn't they? They specifically claim lack of expertise, and that sets the expectations for the reader. The author is just telling their story about learning Go coming from javascript/nodejs. Whether or not you like the book doesn't mean it shouldn't have been written.
- tudelo 9y ago
  Well, what's a quicker way for them to learn? I guarantee if they did something incorrectly people like you will point it out :)
- donatj 9y ago
  I myself know I learn better when I write things I have learned down. I have written very similar blog posts myself, a couple of which actually ended up on HN. It’s a really weird experience writing something you figure no one will ever read, and suddenly one day months later having to field mass criticism.
marcus_holmes 9y ago
The biggest difference I see: the author immediately reached for a framework instead of checking out the standard library. In Node, the standard library is effectively non-existent, so Node devs get trained and acclimatised to dependencies. In Golang, dependencies are minimised. Everyone tries to stick to the standard library as much as possible. Because the standard library is so good, for most projects this is perfectly reasonable. I'd say the first thing every Node dev should know when learning Go is that they don't need a dependency manager. If you can't do it with the standard library then you're probably doing it wrong (at least until you've got some experience with the library).
- paulddraper 9y ago
  > they don't need a dependency manager. For not needing a dependency manager, Go sure has developed an amazing number of them! https://github.com/golang/go/wiki/PackageManagementTools https://github.com/golang/go/wiki/PackageManagementTools https://github.com/avelino/awesome-go/blob/master/README.md#package-management https://github.com/avelino/awesome-go/blob/master/README.md#... In fact, Go probably has the most package managers of any language I've ever seen.
  - gerred 9y ago
    Perhaps everyone coming from other languages who can't imagine a world with a good standard library!
    - seabrookmx 9y ago
      Good is _really_ subjective. While its definitely better than JS/Node it has some warts. For example, I find the "time" builtin package to be pretty terrible. Specifically how it does formatting[0]. This method makes the format look like a magic string rather than being an obvious template like other languages would use. I've found some legitimate bugs[1] in simple functions that don't give me a ton of confidence in it either. Personally I find the standard libraries in the likes of Python and .NET Core much more comprehensive, intuitive, and reliable. [0]: https://golang.org/pkg/time/#Time.Format https://golang.org/pkg/time/#Time.Format [1]: https://github.com/golang/go/issues/15852 https://github.com/golang/go/issues/15852
todd_wanna_code 9y ago
So I am trying to move away from NodeJs for my next project and I can't decide between Elixir and Go. Can't decide what to choose, any idea if there is any advantage for a noob to learn one or the other?
- mzzter 9y ago
  I’d say it depends on what you want to build (disclaimer: I have written a lot of Go but have only read Elixir source). If full stack monolith, use Elixir because of Phoenix; if microservice arch, use Go with gRPC protobufs for messaging. IMO, both languages seem to result in very readable source code; and many examples of how to do either exist on GitHub.
  - todd_wanna_code 9y ago
    Awesome, one thing, what is the advantage of microservices, to lets say, modular monolith?
    - mzzter 9y ago
      Scaling parts of the application independently from each other. If traffic spikes in one part of the application (e.x.: your image categorization web app was posted in a cat forum) more nodes can be added to that one resource to handle the load. Another reason could be worker processes that ran intermittently at midnight every day (e.x.: to email users top pics they missed that day).
      - briankelly 9y ago
        Isn't that the whole point of the Erlang/Elixir/OTP actor model and BEAM VM? It seems like many systems with microservice architecture are reinventing that wheel only worse - except in the cases where the system needs to use legacy or polyglot services.
    - yur83838 9y ago
      The difference is in the network boundaries. I write most of my code as microservices, but it would be incredibly easy to wrap it all up into a single binary. It's not uncommon for go code to have one binary for separate microservice functions (see OKLog). This way you can change between a microservice, or a monolith (ish) with a CLI flag.
sghiassy 9y ago
Super helpful to learn about Go using my existing understanding of NodeJS. Keep it up! Thx
ingas 9y ago
It's only natural that coming from such terrible mess as javascript ecosystem author is trying to solve problems he encountered in past. I wrote comment to him: It's only natural that you're trying to find solutions for problems you encountered in past. But exploring new technology this way leads to absolutely natural mistakes. You're are worring about wrong things. Dependency management This problem is not (and never was) in such terrible scale as in javascript. You can forget about this problem while you learn go. I suppose that dep will be released offically when you will really need this. Asynchronicity I did the same mistake as you: I thought that channels and messages are similar to Actor pattern in Erlang, Akka. Don't try to think about promises, futures and other abstraction when you programming in go. In fact, you need learn synchronicity now, golang already asynchronous in its nature.
illuminati1911 9y ago
Is there really anything else in Go than "pretty good standard library". Looking at this and many other Go discussion it seems there isn't. I've been using Go for a while now and while standard library is ok and definitely better than the one in Node.js and I really like strong typing, I still have to say Go is probably one of the worst programming languages I have ever seen in my life. Error handling is from the stone age, no support for generics, no support for functional programming, no real enum but instead "a hack" you have build by yourself, dependency management without versions etc. Also the hyped features such as channels are nice, but nothing a simple Rx-library couldn't do. Due to the language limitations it's also nearly impossible to write elegant code with Go. If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same: Tons of "if err != nil" and for loops.
- marcus_holmes 9y ago
  Yes. Go is all about writing simple, boring, code that works (to paraphrase another comment here). And works really fast.
  - flavio81 9y ago
    >boring Not boring. Just "full of boilerplate" which also means that it will be a nightmare to maintain at a certain point of the lifecycle.
- strkek 9y ago
  > Is there really anything else in Go than "pretty good standard library". An easy to understand language spec, a compiler that can spit executables that don't depend on glibc, no dependencies on Python 2, and most (if not all) packages under /x/ are BSD licensed. > Error handling is from the stone age I actually prefer this approach to explicit error handling, as opposed to the trendy "uncontrolled non-local gotos" approach (a.k.a. "exceptions". I'm borrowing that term from someone else). The only sane-ish approach to exceptions I'm aware of is that of Java, where you explicitly have to tell which exceptions can happen, and force you to either handle them right there, or modify your function signature accordingly. Still, with a big `try/catch`, if two calls throw the same exception, both exceptions would go to the exact same `catch` block. Yeah, thanks, but I appreciate how Go makes ignoring errors very eye-catching. Makes code review easier. > no support for generics Devs are actually very open to generics. The thing is, nobody has, as of yet, proposed any implementation that would play nice with the rest of the language. > no support for functional programming I don't see the problem. It's not like every new programming language should support every possible feature known to humanity. They would end up like C++, where you don't know if the next version will add the Unreal Engine to the stdlib. If anything what we need is more minimalist programming languages, not the next bloat of the century. > no real enum but instead "a hack" you have build by yourself I can see the point here. > dependency management without versions This is actually one of the things I like the most about Go. "Fix your thing to work with the latest version, or bundle your working version", sounds very reasonable to me. No concept of versions, no centralized source for anything. Just repositories and an ad-hoc way to setup your "registry" just by including an HTML tag in a web server you own. The only assumptions made about "packaging" is that (1) they're somewhere on internet, and (2) you have the command necessary to fetch them. If anything, what I don't like about `go get` is that adding a new "handler" requires recompiling the `go` executable. > Also the hyped features such as channels are nice, but nothing a simple Rx-library couldn't do. Sure. Go brings nothing new to the table. > Due to the language limitations it's also nearly impossible to write elegant code with Go. Most Go code looks elegant to me. Same formatting everywhere (except when someone does not use `gofmt`). It also means that whenever I see `a + 1`, and the code compiles fine, I know it's a numeric addition, and not an HTTP request, for example. Go is like a language with some linting in the spec. Compiler error for unused variables? Yes thanks! Makes reviewing code easier. > If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same Looks like a plus to me. > Tons of "if err != nil" I don't know, I always considered a good practice to handle errors as soon and as explicitly as possible. > and for loops. WHAT!? No more `for (;;) {}` vs `while (1) {}` discussions!!!11!1!!ONEONE. Making people think twice before introducing the Go equivalent of `Array.prototype.forEach` vs `_.each` vs `$.each`, looks like a plus to me as well. Working as close as possible to the primitives unless strictly necessary.

82 points by skellertor 9y ago

Teeer 9y ago

Oh boy, another learning ___ as a ____ developer blog post.

reificator 9y ago
Counterpoint, I wish there were more resources for new languages that assume you already know how to program. Professional Javascript for Web Developers[1] is a favorite of mine, because it doesn't waste time teaching you to program and teaching you the language. Instead it points out things that will surprise you if you come from C-like languages, and things you need to watch out for. Now, since I effectively learned to program in C and later C#/Java, ___ for node developers isn't what I'm after, especially if it spends a bunch of time talking about static typing or fixed size arrays and such. But if you're going the opposite way as I did, learning the high level and transitioning to the low level, something like that could be very useful indeed. [1]: https://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691 https://www.amazon.com/Professional-JavaScript-Developers-Ni...
- oei829ejenk3 9y ago
  I know it’s not a popular opinion with some, but all code looks like to me anymore is math with whatever symbols the language in question needs to work For example: (singleton) (tu,ple) def func1(singleton): def func2(tu,ple): ^ python function declarations So after 20 yrs of this, I try to keep in mind the math and just look up the bits to wrap it in. Also, I avoid custom frameworks and all this industry react/angular, or whatever is cool like the plague, by avoiding front end for a while now But I do consulting which affords me the luxury. Many may not have the flexibility. I’ve a set of macros in vim to scaffold boiler plate and go from there Boom, programming in any language
dang 9y ago
Could you please not post snarky dismissals to this site? We're trying for better than that here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html
- Teeer 9y ago
  I'm sure you're also trying for better content. I'll continue to embrace my displeasure for posts like these, thank you very much.
  - deleted 9y ago
    [deleted]

ralusek 9y ago

Why would this author feel compelled to write an article about this if they're just learning? That asynchronous Go code which is meant to be analogous to the handful of Node lines looks super verbose. Because the author has claimed a lack of expertise, I have no idea if that is actually the correct way to write something like that out...but it certainly doesn't make Go look good.

gouggoug 9y ago
> Why would this author feel compelled to write an article about this if they're just learning? Why wouldn't they? They specifically claim lack of expertise, and that sets the expectations for the reader. The author is just telling their story about learning Go coming from javascript/nodejs. Whether or not you like the book doesn't mean it shouldn't have been written.
tudelo 9y ago
Well, what's a quicker way for them to learn? I guarantee if they did something incorrectly people like you will point it out :)
donatj 9y ago
I myself know I learn better when I write things I have learned down. I have written very similar blog posts myself, a couple of which actually ended up on HN. It’s a really weird experience writing something you figure no one will ever read, and suddenly one day months later having to field mass criticism.

marcus_holmes 9y ago

The biggest difference I see: the author immediately reached for a framework instead of checking out the standard library. In Node, the standard library is effectively non-existent, so Node devs get trained and acclimatised to dependencies. In Golang, dependencies are minimised. Everyone tries to stick to the standard library as much as possible. Because the standard library is so good, for most projects this is perfectly reasonable. I'd say the first thing every Node dev should know when learning Go is that they don't need a dependency manager. If you can't do it with the standard library then you're probably doing it wrong (at least until you've got some experience with the library).

paulddraper 9y ago
> they don't need a dependency manager. For not needing a dependency manager, Go sure has developed an amazing number of them! https://github.com/golang/go/wiki/PackageManagementTools https://github.com/golang/go/wiki/PackageManagementTools https://github.com/avelino/awesome-go/blob/master/README.md#package-management https://github.com/avelino/awesome-go/blob/master/README.md#... In fact, Go probably has the most package managers of any language I've ever seen.
- gerred 9y ago
  Perhaps everyone coming from other languages who can't imagine a world with a good standard library!
  - seabrookmx 9y ago
    Good is _really_ subjective. While its definitely better than JS/Node it has some warts. For example, I find the "time" builtin package to be pretty terrible. Specifically how it does formatting[0]. This method makes the format look like a magic string rather than being an obvious template like other languages would use. I've found some legitimate bugs[1] in simple functions that don't give me a ton of confidence in it either. Personally I find the standard libraries in the likes of Python and .NET Core much more comprehensive, intuitive, and reliable. [0]: https://golang.org/pkg/time/#Time.Format https://golang.org/pkg/time/#Time.Format [1]: https://github.com/golang/go/issues/15852 https://github.com/golang/go/issues/15852

todd_wanna_code 9y ago

So I am trying to move away from NodeJs for my next project and I can't decide between Elixir and Go. Can't decide what to choose, any idea if there is any advantage for a noob to learn one or the other?

mzzter 9y ago
I’d say it depends on what you want to build (disclaimer: I have written a lot of Go but have only read Elixir source). If full stack monolith, use Elixir because of Phoenix; if microservice arch, use Go with gRPC protobufs for messaging. IMO, both languages seem to result in very readable source code; and many examples of how to do either exist on GitHub.
- todd_wanna_code 9y ago
  Awesome, one thing, what is the advantage of microservices, to lets say, modular monolith?
  - mzzter 9y ago
    Scaling parts of the application independently from each other. If traffic spikes in one part of the application (e.x.: your image categorization web app was posted in a cat forum) more nodes can be added to that one resource to handle the load. Another reason could be worker processes that ran intermittently at midnight every day (e.x.: to email users top pics they missed that day).
    - briankelly 9y ago
      Isn't that the whole point of the Erlang/Elixir/OTP actor model and BEAM VM? It seems like many systems with microservice architecture are reinventing that wheel only worse - except in the cases where the system needs to use legacy or polyglot services.
  - yur83838 9y ago
    The difference is in the network boundaries. I write most of my code as microservices, but it would be incredibly easy to wrap it all up into a single binary. It's not uncommon for go code to have one binary for separate microservice functions (see OKLog). This way you can change between a microservice, or a monolith (ish) with a CLI flag.

sghiassy 9y ago

Super helpful to learn about Go using my existing understanding of NodeJS. Keep it up! Thx

ingas 9y ago

It's only natural that coming from such terrible mess as javascript ecosystem author is trying to solve problems he encountered in past. I wrote comment to him: It's only natural that you're trying to find solutions for problems you encountered in past. But exploring new technology this way leads to absolutely natural mistakes. You're are worring about wrong things. Dependency management This problem is not (and never was) in such terrible scale as in javascript. You can forget about this problem while you learn go. I suppose that dep will be released offically when you will really need this. Asynchronicity I did the same mistake as you: I thought that channels and messages are similar to Actor pattern in Erlang, Akka. Don't try to think about promises, futures and other abstraction when you programming in go. In fact, you need learn synchronicity now, golang already asynchronous in its nature.

illuminati1911 9y ago

Is there really anything else in Go than "pretty good standard library". Looking at this and many other Go discussion it seems there isn't. I've been using Go for a while now and while standard library is ok and definitely better than the one in Node.js and I really like strong typing, I still have to say Go is probably one of the worst programming languages I have ever seen in my life. Error handling is from the stone age, no support for generics, no support for functional programming, no real enum but instead "a hack" you have build by yourself, dependency management without versions etc. Also the hyped features such as channels are nice, but nothing a simple Rx-library couldn't do. Due to the language limitations it's also nearly impossible to write elegant code with Go. If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same: Tons of "if err != nil" and for loops.

marcus_holmes 9y ago
Yes. Go is all about writing simple, boring, code that works (to paraphrase another comment here). And works really fast.
- flavio81 9y ago
  >boring Not boring. Just "full of boilerplate" which also means that it will be a nightmare to maintain at a certain point of the lifecycle.
strkek 9y ago
> Is there really anything else in Go than "pretty good standard library". An easy to understand language spec, a compiler that can spit executables that don't depend on glibc, no dependencies on Python 2, and most (if not all) packages under /x/ are BSD licensed. > Error handling is from the stone age I actually prefer this approach to explicit error handling, as opposed to the trendy "uncontrolled non-local gotos" approach (a.k.a. "exceptions". I'm borrowing that term from someone else). The only sane-ish approach to exceptions I'm aware of is that of Java, where you explicitly have to tell which exceptions can happen, and force you to either handle them right there, or modify your function signature accordingly. Still, with a big `try/catch`, if two calls throw the same exception, both exceptions would go to the exact same `catch` block. Yeah, thanks, but I appreciate how Go makes ignoring errors very eye-catching. Makes code review easier. > no support for generics Devs are actually very open to generics. The thing is, nobody has, as of yet, proposed any implementation that would play nice with the rest of the language. > no support for functional programming I don't see the problem. It's not like every new programming language should support every possible feature known to humanity. They would end up like C++, where you don't know if the next version will add the Unreal Engine to the stdlib. If anything what we need is more minimalist programming languages, not the next bloat of the century. > no real enum but instead "a hack" you have build by yourself I can see the point here. > dependency management without versions This is actually one of the things I like the most about Go. "Fix your thing to work with the latest version, or bundle your working version", sounds very reasonable to me. No concept of versions, no centralized source for anything. Just repositories and an ad-hoc way to setup your "registry" just by including an HTML tag in a web server you own. The only assumptions made about "packaging" is that (1) they're somewhere on internet, and (2) you have the command necessary to fetch them. If anything, what I don't like about `go get` is that adding a new "handler" requires recompiling the `go` executable. > Also the hyped features such as channels are nice, but nothing a simple Rx-library couldn't do. Sure. Go brings nothing new to the table. > Due to the language limitations it's also nearly impossible to write elegant code with Go. Most Go code looks elegant to me. Same formatting everywhere (except when someone does not use `gofmt`). It also means that whenever I see `a + 1`, and the code compiles fine, I know it's a numeric addition, and not an HTTP request, for example. Go is like a language with some linting in the spec. Compiler error for unused variables? Yes thanks! Makes reviewing code easier. > If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same Looks like a plus to me. > Tons of "if err != nil" I don't know, I always considered a good practice to handle errors as soon and as explicitly as possible. > and for loops. WHAT!? No more `for (;;) {}` vs `while (1) {}` discussions!!!11!1!!ONEONE. Making people think twice before introducing the Go equivalent of `Array.prototype.forEach` vs `_.each` vs `$.each`, looks like a plus to me as well. Working as close as possible to the primitives unless strictly necessary.