Live data from Hacker News

From Node.js to Go

bowery.io

41–50 of 192 posts

Re: From Node.js to Go

#41

I'e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations: - The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python/Ruby background, that was nice to see. - I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see…

> I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I've found it to be practical and easy to use.

Go doesn't have generics. To someone coming from a language like Rust, saying that your type system doesn't have generics is like saying your car doesn't have wheels. It's just considered non-negotiable.

Re: From Node.js to Go

#43

I'e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations: - The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python/Ruby background, that was nice to see. - I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see…

> - Go is a minimal language and has been called boring. [2] I don't claim to be an expert yet, but I don't think I've reached this level of productivity with a language this quickly before.

I was drawn to Go initially because of its promises around concurrency, but this is why I stayed. Within less than a month, I was as productive in Go as I was in Python, despite the fact that I had been programming in Python for several years at that point.

> - I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see a canonical dep management tool for go.

For what it's worth, Docker has more or less replaced this need for me. I know it doesn't actually do "dependency management" in the traditional sense, but by the time that ad-hoc vendoring no longer works, I've found it's already time to start using Docker for deployment for other reasons anyway. At this point, it's just as easy to use Docker to manage the dependencies at the application level while developing as well.

Re: From Node.js to Go

#44

I'e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations: - The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python/Ruby background, that was nice to see. - I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see…

> I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I've found it to be practical and easy to use. Go doesn't have generics. To someone coming from a language like Rust, saying that your type system doesn't have generics is like saying your car doesn't have wheels. It's just considered non-negotiable.

> saying that your type system doesn't have generics is like saying your car doesn't have wheels.

To overburden an analogy, it'd be more like complaining that your tank doesn't have wheels[0], or your hovercraft. Go takes a different approach to the same problem (in this analogy, getting from point A to point B).

But really, this is a rather tired flamewar that gets beaten to death literally every time a post about Go makes the front page, and there's really nothing more that can be said about it. Either program in idiomatic Go, which means using the language as it's designed (ie, without generics, at least in its current form), or don't, but it's very tiresome to see this argument rehashed again and again.

[0] https://en.wikipedia.org/wiki/Continuous_track#mediaviewer/F...

Re: From Node.js to Go

#45
post #9

For me the single biggest disadvantage of Go against Node.JS is the lack of a decent dependency management solution. NPM is awesome and Go doesn't even have a "meh" answer to that.

NPM is only awesome until you need to do something with it on Windows.

What kind of problems are you having with it? I'm using npm on Windows and it's working out great! I'm actually using it as my build/task runner rather than using bloated grunt or gulp. It's easy to configure and read. I run my linter, unit test, jscs, and bundler all configured in package.json.

I also install git bash and conemu to have bash on Windows which makes things much better. I don't use windows console.

Re: From Node.js to Go

#46

Go does lack quite a bit of the web pizzazz you'd find in rails, but I learned a lot more by writing web things in go than I did in rails because so much less of the magic is hidden away from you.

Would you have had the same experience by coding directly in Ruby? The magic of Rails would similarly be hidden from you, forcing you to learn what's going on under the hood.

Re: From Node.js to Go

#47
post #38

Earlier quoted context omitted.

NPM is only awesome until you need to do something with it on Windows.

Never had any problem with it when we did a Cordova based application for a customer of ours.

There are quite a few packages in npm that require native compilation of some part of their system during install. These usually fail horribly on windows without spending a lot of time tweaking your system in ways you probably don't want to. This is in sad contrast to how well many of the other libraries just work.

I would have thought it'd be possible to emscripten compile something like tinyC, and make a C compiler you could naturally fit into the node ecosystem to build native libraries.

Re: From Node.js to Go

#48
This is just another generic Go vs Node post. Do we really need another post telling us about Go's concurrency/built-in features/compile benefits.

This post sadly doesn't really go into much details that bowery.io is trying to solve, how Go fits that and why Node was so bad.

A basic crud webapp would probably be better suited towards node and it's larger list of libraries supporting that kind of stuff.

On the other hand, building you own messaging queue or doing heavy mathematical processing might be better suited for Go.

Re: From Node.js to Go

#49

Earlier quoted context omitted.

> I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I've found it to be practical and easy to use. Go doesn't have generics. To someone coming from a language like Rust, saying that your type system doesn't have generics is like saying your car doesn't have wheels. It's just considered non-negotiable.

> saying that your type system doesn't have generics is like saying your car doesn't have wheels. To overburden an analogy, it'd be more like complaining that your tank doesn't have wheels[0], or your hovercraft. Go takes a different approach to the same problem (in this analogy, getting from point A to point B). But really, this is a rather tired flamewar that gets beaten to death literally every time a post about G…

This happens because almost every time there's someone who more or less asks what in the world generics are for since they can do everything they want to with Go's type system. Sure, it's possible, but it's missing the point.

Re: From Node.js to Go

#50
post #40

I'm having a hard time enjoying Go. It just reminds me a little too much of Java, and I programmed in that language for way too long. After I finished my test program, I uninstalled the toolkit from my system. Right now, I feel that there's no perfect language for me. I do love JavaScript, but there are some things I wish they'd fix. And it takes browser makers way too long to support the latest features. Been messin…

Maybe you don't like programming? Or you did once, but you've grown bored with it now that it's not as challenging?

In my opinion, a programming language is good if it enables the programmer to move from a concept to correct and maintainable implementation with minimal friction. I don't expect a programming language to entertain me.

The burden is then on me to find projects that I believe in and will enjoy implementing. This is, of course, easier said then done.

Post reply on HN