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

171–180 of 192 posts

Re: From Node.js to Go

#171

Post by izolate »

tjholowaychuk wrote: post #164
u84six wrote: post #74

Earlier quoted context omitted.

From what I've heard, TJ is working with Go because Joyent wasn't putting enough effort into releasing features for node and he also got tired of JavaScript callbacks. I think node will see some love very soon, and I know there are plenty of ways to deal with callback hell. That's just one guy's feeling. I really love working with node. But definitely looking forward some new features.

There are lots of reasons! I'd encourage people to try something new (Go, Rust, Scala, whatever), it's easy to ignore Node's shortcomings sometimes. Community was a big one for me, the "unixy" nature of node+npm is no good when the module quality is pretty poor and the names are completely nonsensical, your app just becomes an abstract blob of code that makes no sense. Go's stdlib is pretty rock solid, nothing in Nod…

Having just spent more time at work this week creating PR for bugs in npm modules, instead of doing actual work... I'm starting to agree.

But honestly I think that's just par for the course for any substantially popular language. I don't think Go (or any other language) is inherently immune to this.

Re: From Node.js to Go

#172

Post by Jweb_Guru »

Animats wrote: post #112
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.

Having written in both Go and Rust, I can see the arguments. Go has a relatively simple, easy to use type system. The problem is that whenever you need to do anything generic, you have to use Go's "any" type, "interface{}", and the reflection system. This results in doing stuff over and over at run time that could have been done once, preferably at compile time. For much web back-end stuff, though, you don't need a r…

Idiomatic Rust uses try!. It is a less verbose version of the most common pattern of error handling in Go. You have not programmed very much Rust and are not yet familiar with its idioms, but that is by far the most common and avoids all the problems you just described.

Re: From Node.js to Go

#173

Post by Jweb_Guru »

skj wrote: post #149
Animats wrote: post #112

Earlier quoted context omitted.

Having written in both Go and Rust, I can see the arguments. Go has a relatively simple, easy to use type system. The problem is that whenever you need to do anything generic, you have to use Go's "any" type, "interface{}", and the reflection system. This results in doing stuff over and over at run time that could have been done once, preferably at compile time. For much web back-end stuff, though, you don't need a r…

> I'm concerned that Rust is starting out at the cruft level it took C++ 20 years to achieve. That is the core reason why there are no generics in Go. Not because the Go team thinks they're a terrible idea, but because they think cruft is a terrible idea. The default answer to a new feature is "no". When everything seems to be going fine without generics (except for internet flamewars), the answer stays "no".

The reason there are no generics in Go is because nobody has implemented them in Go (or presented a concrete proposal for implementing them, i.e. something less vague than "just do what C# did" while ignoring that C# is not AOT compiled). Thre are some monomorphizing preprocessors but they tend to punt on the interaction betweeen generics and the rest of the language.

I find the community's insistence that Go does not have them because they somehow make programming worse to be fairly ludicrous, when there are much more practical reasons. Obviously you can write useful code without generics (C does not have them), but that does not make them useless, or "cruft", or an undesired feature (unless you simply choose to believe that every single person complaining about them does not use Go): you can also write useful code without many other features that Go does have.

Re: From Node.js to Go

#174

Post by wwweston »

engendered wrote: post #162
wwweston wrote: post #85

Earlier quoted context omitted.

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 li…

If being able to get things out the door anyway This is specious logic. People are not being told to use Go grudgingly because it is mandatory. It isn't a required component of some entrenched industry dictum. The only possible reason someone would choose Go is because, somehow, it is advantageous to their process. And we've seen an enormous number of success stories with Go recently -- all people choosing to use it…

> People are not being told to use Go grudgingly because it is mandatory. It isn't a required component of some entrenched industry dictum.

You're registering this objection on the basis of JS's privileged status in the browser; I'm invoking it because of The Fine Article's comparison with JS on the server, where it's adopted as voluntarily as any other language -- and where, yes, despite claims that event-driven/callback scattered code are worse than what Go offers, people are able to get things out the door anyway!

And that's true of Node, it's true of PHP, it's true of Java, it's true of most languages people have moved to Go from.

The claim that being able to ship in a language doesn't mean it's wart-free is a pretty solid one, and that's what we're talking about.

> I find it hard to even express clearly why Go feels so...natural and productive. But it does

Does it? I've been working in it for 8 months and... nope. Doesn't feel unusually productive. But I guess your subjective opinion that you can't explain should trump everyone else -- after all, we're using "specious logic!"

> And one of those reasons is that the language is so simple and, well, crude, that you don't stop and sit on questions of approach.

Ah, yes. It's like Java:

"I liked programming in Java mainly because I found it very relaxing. With a bad language, like say Fortran or csh, you struggle to do anything at all, and the language fights with you every step of the way forward. With a good language there is a different kind of struggle, to take advantage of the language's strengths, to get the maximum amount of functionality, and to achieve the clearest possible expression.

Java is neither a good nor a bad language. It is a mediocre language, and there is no struggle. In Haskell or even in Perl you are always worrying about whether you are doing something in the cleanest and the best way. In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated, and the only thing you can do is relax and keep turning the crank until the necessary amount of code has come out of the spout."

   http://blog.plover.com/prog/Java.html
(When I started working with Go last May, I had no idea or expectation of the extent to which I'd have thought this article would apply.)

> And FWIW, when people talk about the lack of generics causing them great pain, usually they aren't making a solution, but instead are toying with the language.

Really?

> it just...isn't a problem. It really isn't.

Oh. Sorry, then. I'll just realize that the unpleasantness I've encountered working with it really isn't there, and I'm not focusing on solutions.

Re: From Node.js to Go

#175

Post by engendered »

wwweston wrote: post #174
engendered wrote: post #162

Earlier quoted context omitted.

If being able to get things out the door anyway This is specious logic. People are not being told to use Go grudgingly because it is mandatory. It isn't a required component of some entrenched industry dictum. The only possible reason someone would choose Go is because, somehow, it is advantageous to their process. And we've seen an enormous number of success stories with Go recently -- all people choosing to use it…

> People are not being told to use Go grudgingly because it is mandatory. It isn't a required component of some entrenched industry dictum. You're registering this objection on the basis of JS's privileged status in the browser; I'm invoking it because of The Fine Article's comparison with JS on the server, where it's adopted as voluntarily as any other language -- and where, yes, despite claims that event-driven/cal…

"and where, yes, despite claims that event-driven/callback scattered code are worse than what Go offers, people are able to get things out the door anyway!"

You misunderstand my argument. If someone is begrudgingly complaining about JavaScript in the browser, well they have a legitimate gripe because they really have no option (beyond various compiles-to-javascript kludges). If those same people used nodejs, on the other hand, which many people do, they clearly found some compelling reason to do so. In the case of node it was that it made code very easily, and by default, asynchronous, instead of the classic .NET/PHP synchronous model. There was a benefit, and people gained from it.

Really?

Why are you using Go? Are you solving a real problem? Did you say "here is my itch, and I am using Go to scratch it?" I have never seen, in these discussions, people solving actual problems complaining about Go. Instead it's the code tourists who want to do some flippant, vaguely directed project and then add "Go Guru" on their resume to give credibility to their complaints.

Re: From Node.js to Go

#176

Post by skygazer »

je42 wrote: post #115

For testing frameworks, standard library tasks, workflow: he author prefers less choice and more standardisation, hence Go > Node.js. Which I find very disappointing. One thing that I learned, if some standardization happen and you have to use it, it will cause you pain eventually. Obviously, there is honey-moon period and a clear path what to do if you only got "one" standard, but the author will eventually there is…

I have to agree with your sentiment -- certain types of simplicity, though attractive, can be a misleading double edged sword.

I once let a team split in two for a week to separately build the same product using two competing UI frameworks, before our final decision. The simpler, more opinionated framework won, hands down at the end of one week, being far more productive with the least effort. But, over subsequent years, we found the framework far too restrictive, requiring convoluted solutions when problems strayed from the straight and narrow, leaving our code base littered with painful hacks.

Re: From Node.js to Go

#177

Post by azth »

Jweb_Guru wrote: post #173
skj wrote: post #149

Earlier quoted context omitted.

> I'm concerned that Rust is starting out at the cruft level it took C++ 20 years to achieve. That is the core reason why there are no generics in Go. Not because the Go team thinks they're a terrible idea, but because they think cruft is a terrible idea. The default answer to a new feature is "no". When everything seems to be going fine without generics (except for internet flamewars), the answer stays "no".

The reason there are no generics in Go is because nobody has implemented them in Go (or presented a concrete proposal for implementing them, i.e. something less vague than "just do what C# did" while ignoring that C# is not AOT compiled). Thre are some monomorphizing preprocessors but they tend to punt on the interaction betweeen generics and the rest of the language. I find the community's insistence that Go does no…

> while ignoring that C# is not AOT compiled

https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

Re: From Node.js to Go

#178

Post by azth »

engendered wrote: post #162
wwweston wrote: post #85

Earlier quoted context omitted.

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 li…

If being able to get things out the door anyway This is specious logic. People are not being told to use Go grudgingly because it is mandatory. It isn't a required component of some entrenched industry dictum. The only possible reason someone would choose Go is because, somehow, it is advantageous to their process. And we've seen an enormous number of success stories with Go recently -- all people choosing to use it…

> The only possible reason someone would choose Go is because, somehow, it is advantageous to their process.

Or because of the hype (and that they didn't know any better), which is quite common in the industry nowadays, unfortunately.

In a similar fashion, the Go designers were surprised that, what they thought was a C++ replacement, did not attract C++ programmers.

Re: From Node.js to Go

#179

Post by azth »

sagichmal wrote: post #157
gnuvince wrote: post #140

Earlier quoted context omitted.

Honestly, it's not the 2-4-8 indentation or the placement of braces that gets me when reading code. In Go, my biggest problem is that there are so many x, err := foo(); if err { ... } that I get lost trying to figure what the happy path behavior is.

> I get lost trying to figure what > the happy path behavior is. The happy path is idiomatically at indent level 0.

Except when it's

    if x, err := doSomething(); err != nil {
    }

Re: From Node.js to Go

#180

Post by Jweb_Guru »

azth wrote: post #177
Jweb_Guru wrote: post #173

Earlier quoted context omitted.

The reason there are no generics in Go is because nobody has implemented them in Go (or presented a concrete proposal for implementing them, i.e. something less vague than "just do what C# did" while ignoring that C# is not AOT compiled). Thre are some monomorphizing preprocessors but they tend to punt on the interaction betweeen generics and the rest of the language. I find the community's insistence that Go does no…

> while ignoring that C# is not AOT compiled https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

Does this take significantly longer to compile than regular C# code (I can't imagine the answer is no)? If so, it doesn't really address the concerns Go's implementors brought up, which precisely revolved around the compile time : runtime performance tradeoffs that the JIT compiler helps mitigate for C#'s generics.
Post reply on HN