Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Node.js to Go

bowery.io

Post reply on HN
Print view View original

81–90 of 192 posts

Re: From Node.js to Go

#81

Post by engendered »

TheCoelacanth wrote: post #41
wiremine wrote: post #33

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.

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.

Analogies are almost always useless diversions, but this one is particularly ridiculous.

People are building real, working, successful solutions in Go with rather surprisingly regularity (which, if the comparison needs to be made, they don't seem to be doing with Rust). It is obviously working pretty well, and that "non-negotiable" point turned out to not be a showstopper.

A car without wheels? If we have to abuse analogies, more like a car with a manual transmission. People can have hysterics about how will they ever eat their burger while they drive, but somehow some people manage.

Re: From Node.js to Go

#82

Post by yellowapple »

kxo wrote: post #75
mrcwinn wrote: post #57

Earlier quoted context omitted.

Go, unlike Rails, is not a web/MVC framework. It's a systems language, which is even still separate and unique from Ruby, a dynamic language. I agree you'll certainly learn more from Go than you would from Rails, but it's helpful to be aware they're very different. Apart from my own opinion of Rails (I'll pass, thanks), it's also worth considering that Go, again a systems language, may not always be appropriate for t…

> systems Here we go.

rimshot

Re: From Node.js to Go

#83

Post by pcwalton »

engendered wrote: post #81
TheCoelacanth wrote: post #41

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.

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. Analogies are almost always useless diversions, but this one is particularly ridiculous. People are building real, working, successful solutions in Go with rather surprisingly regularity (which, if the comparison needs to be made, they don't…

> People are building real, working, successful solutions in Go with rather surprisingly regularity (which, if the comparison needs to be made, they don't seem to be doing with Rust)

I have written hundreds of thousands of lines of Rust code for Servo, the Rust compiler, and other projects. Of course it's a less mature language, but people are building plenty of solutions, including production solutions, in Rust.

Re: From Node.js to Go

#84

Post by shurcooL »

TheCoelacanth wrote: post #41
wiremine wrote: post #33

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.

There are two types of people.

Re: From Node.js to Go

#85

Post by wwweston »

engendered wrote: post #81
TheCoelacanth wrote: post #41

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.

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. Analogies are almost always useless diversions, but this one is particularly ridiculous. People are building real, working, successful solutions in Go with rather surprisingly regularity (which, if the comparison needs to be made, they don't…

If being able to get things out the door anyway is the standard for "well, guess this language is nice enough!", there goes any argument against JavaScript, or for that matter Go over Java.

I'm one of the people who is currently making a working solution in Go. Are generics the equivalent of missing wheels? Probably not, but I am absolutely finding it a present and persistent pain point that I don't have something like that or even just overloaded function/method signatures, and instead have to frequently repeat a lot of rewritten code scattered full of lots and lots of if/else cases.

Life could be worse. But the fact that people are shipping doesn't mean it's a language in which people aren't finding a specific missing features to be a problem.

Re: From Node.js to Go

#86

Post by acdha »

threeseed wrote: post #71
wiremine wrote: post #33

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…

Most languages have an equivalent of go fmt. They are just third party tools that aren't integrated into the language. Which for me is perfectly acceptable. There are sometimes legitimate reasons for formatting code different to what the language creators believe.

I used to agree with you more strongly but I think it's easy to forget just how much time and confusion is saved by having a single standard format which anyone can trivially check and apply. It's not just about avoiding unnecessary bike-shed arguments but also things like the cognitive cost of having to dealing with each project / developer's style quirks.

I'm now inclined to believe that a basically free way to avoid bugs and make things like code review easier and more productive is worth the minor cost of people having to break out of old ruts.

Re: From Node.js to Go

#87

Post by curun1r »

nawitus wrote: post #73
billsimpson wrote: post #66

Earlier quoted context omitted.

> I never, ever want to write any OS-specific code With Go, you never, ever have to write any OS-specific code. From a single source , you can build executables compiled for different operating systems. In any case, you're right that it can be nice to simply "run" a JavaScript application directly from its source code without worrying about compilation. > You need to compile to code for every single platform, making…

>With Go, you never, ever have to write any OS-specific code. Okay. The article claimed otherwise: "In Go, you can define different files for different operating systems that implement functionality depending on the operating system." >Yes, you may generate a few versions (Windows, OS X, etc.) depending on the needs of your clients, but the cost is a few seconds of compile time, and a few seconds posting links to the…

> > With Go, you never, ever have to write any OS-specific code.

> Okay. The article claimed otherwise: "In Go, you can define different files for different operating systems that implement functionality depending on the operating system."

Both the article and the poster you're replying to are correct. You almost never have to write OS-specific code, but you can write it if you feel there's a benefit to it. Much like Node doesn't make you write C++ code but allows you to do it when you feel it's necessary. The article's main point was, I'm assuming, alluding to Go's build tags which are much more elegant than the traditional pre-processor directives used in the C/++ world. They give you a powerful expression language for targeting specific runtime environments that lets you separate out your OS-specific code in a very clean way.

When it comes to distributing an application, there's another advantage that Go has over Node. One of the common ways that people are distributing server applications these days is as Docker images. It solves the problem of users needing to understand npm quite nicely for a Node application, but makes the distributable artifact significantly larger since it includes the bulk of an OS alongside the application code. With Go's ability to create a statically-linked binaries, you can build your Docker images "FROM scratch" and images can be as small as 2.5m.

Re: From Node.js to Go

#88

Post by ufo »

pekk wrote: post #76
mitchty wrote: post #69

Earlier quoted context omitted.

I always saw it as the classical: why do you want a screwdriver to put the screw in place? The hammer should be good enough! Well, sure, I guess you can pound a screw into things with a hammer but you're missing the point.

Or just build your furniture without using screws, like in Japanese carpentry. When people are already having a decent time building things using the tool, it looks pretty stupid to tell them they've done it all wrong for years in all the decent products they made.

Parametric polymorphism gives safety guarantees that you can't easily obtain without language support. For example if you have a function typed "forall a . a -> a" you know it has to be the identity function (or something that bypasses the typesystem, like infinite loops or a runtime exception).

Re: From Node.js to Go

#89

Post by cakoose »

engendered wrote: post #81
TheCoelacanth wrote: post #41

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.

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. Analogies are almost always useless diversions, but this one is particularly ridiculous. People are building real, working, successful solutions in Go with rather surprisingly regularity (which, if the comparison needs to be made, they don't…

Two things. First, I think it's more about the initial reaction to Go, from someone coming from Rust (or Java, C#, C++, etc).

But even so, I agree the wheels analogy is too extreme. I'd maybe say that it's like hearing that a car uses two motors instead of a differential -- "weird, I thought we solved that problem a while ago..."

Re: From Node.js to Go

#90

Post by Rapzid »

nawitus wrote: post #73
billsimpson wrote: post #66

Earlier quoted context omitted.

> I never, ever want to write any OS-specific code With Go, you never, ever have to write any OS-specific code. From a single source , you can build executables compiled for different operating systems. In any case, you're right that it can be nice to simply "run" a JavaScript application directly from its source code without worrying about compilation. > You need to compile to code for every single platform, making…

>With Go, you never, ever have to write any OS-specific code. Okay. The article claimed otherwise: "In Go, you can define different files for different operating systems that implement functionality depending on the operating system." >Yes, you may generate a few versions (Windows, OS X, etc.) depending on the needs of your clients, but the cost is a few seconds of compile time, and a few seconds posting links to the…

Further to what curun1r said, most(all?) of the Go stdlib is written in Go and that has much platform specific code. Hence, it supports it. However, unless you're writing system code you will most likely never need to touch this.

http://golang.org/src/net/

Post reply on HN