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

181–190 of 192 posts

Re: From Node.js to Go

#181

Post by wwweston »

engendered wrote: post #175
wwweston wrote: post #174

Earlier quoted context omitted.

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

> You misunderstand my argument.

Apparently. I have no idea why JavaScript's position in the browser is relevant at all to the point that being able to ship in a language isn't evidence that its featureset is ideal.

I do invite you to argue the point further, though. And please continue to ask questions like this again:

"Why are you using Go? Are you solving a real problem?"

Yes, please do imagine out loud that everyone who's critical of Go is just not building real software in it. Hell, follow your "argument" to its natural consequence: anyone not using your personal flavor of Blub is probably just farting around.

Re: From Node.js to Go

#182

Post by engendered »

wwweston wrote: post #181
engendered wrote: post #175

Earlier quoted context omitted.

"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 o…

> You misunderstand my argument. Apparently. I have no idea why JavaScript's position in the browser is relevant at all to the point that being able to ship in a language isn't evidence that its featureset is ideal. I do invite you to argue the point further, though. And please continue to ask questions like this again: "Why are you using Go? Are you solving a real problem?" Yes, please do imagine out loud that every…

Ah, sweet delicious sarcasm. Always the last resort.

There is absolutely nothing drawing anyone who doesn't want to use Go into using it. There are zero external forces or dependencies that are making you build solutions in Go.

So when you come telling a tall tale of your peril with Go, it just stinks. Do you understand? You can, from the outside looking in, have criticisms of the language, but when you try to add authority to your claims by manufacturing great experience, it sounds absurd.

The relevance of JavaScript -- and this really doesn't seem that difficult, though I think you're trying to be difficult -- is that, to reiterate, people have to bear it regardless of their feelings about it, so there are a lot of people who despise JavaScript but ply their trade in it daily. There is zero parallel with Go, where there is absolutely no reason for anyone to ever make use of it if it doesn't offer some significant advantage to their project.

Re: From Node.js to Go

#183

Post by tjholowaychuk »

izolate wrote: post #171
tjholowaychuk wrote: post #164

Earlier quoted context omitted.

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.

For sure, there are lots of skillful people working on node as well, I just think the Go team has a lot more experience and it shows.

Re: From Node.js to Go

#184

Post by bsg75 »

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.

If its not-negotiable, then get over it, and use a language that meets your requirements.

Re: From Node.js to Go

#185

Post by Animats »

Jweb_Guru wrote: post #172
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…

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.

"try!" is close to something one might call "cruft". It tests a function for an error value, and if it gets one, it returns from the containing function. "try!()" is written like a function call, but it doesn't work like one - it can execute a return statement. That's outside the normal semantics of the language. This is the only macro in the standard macros with such semantics. Fortunately. This is a capability which needs to be used with extreme restraint. Writing a macro "try_except_finally!(maincode, exceptioncode, cleanupcode)" would probably be a bad idea.

There was at one time a fad for extending C with macros like that. Fortunately for program readability, it didn't last.

Re: From Node.js to Go

#186

Post by Jweb_Guru »

Animats wrote: post #185
Jweb_Guru wrote: post #172

Earlier quoted context omitted.

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.

"try!" is close to something one might call "cruft". It tests a function for an error value, and if it gets one, it returns from the containing function . "try!()" is written like a function call, but it doesn't work like one - it can execute a return statement. That's outside the normal semantics of the language. This is the only macro in the standard macros with such semantics. Fortunately. This is a capability whi…

Except that in Rust, all macros are syntactically distinguished from non-macros (as well as hygienic, unlike C macros), and try! is extremely common (so the claim that people won't know what it does is questionable). I agree that macros like this should be carefully considered, but I think experience has already shown us that try! is perfectly fine.

Re: From Node.js to Go

#187

Post by kybernetikos »

pjmlp wrote: post #124
kybernetikos wrote: post #47

Earlier quoted context omitted.

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…

I see. However that is a common problem in any platform that doesn't follow the UNIX way. I imagine node.js for IBM i or z/OS to have similar issues.

This is almost certainly true, and if there were as many people trying to use node on those operating systems as there are on windows I expect you would see a similar number of complaints.

Re: From Node.js to Go

#188

Post by Manishearth »

Animats wrote: post #185
Jweb_Guru wrote: post #172

Earlier quoted context omitted.

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.

"try!" is close to something one might call "cruft". It tests a function for an error value, and if it gets one, it returns from the containing function . "try!()" is written like a function call, but it doesn't work like one - it can execute a return statement. That's outside the normal semantics of the language. This is the only macro in the standard macros with such semantics. Fortunately. This is a capability whi…

`throw` in Java's exception handling also prematurely exits a function. So?

While `try!()` is a macro and not a core language feature, most of the macros in the standard library can be treated as such. So a Rust programmer will know that `try!()` can return, just like a Java programmer knows that `throw` returns early.

Besides, macros are syntactically distinguishable in Rust. When you see that exclamation mark, you have to rememeber that it's a macro and might be doing arbitrary compile time things along with arbitrary token tree expansion.

Re: From Node.js to Go

#189

Post by 4ydx »

ufo wrote: post #156
4ydx wrote: post #108

Earlier quoted context omitted.

And in Go since there is no parametric polymorphism you would end up writing either: 1) Methods with names that indicate the parameter types. 2) Method calls on objects to convert some internal struct data from one type to another. 3) Something I haven't thought of that doesn't involve losing a handle on your type. So there is certainly a loss in convenience, but if you use the type system it can be just as safe as a…

No you can't. The point of generics is that you don't need to specify the parameter types - the parameter type is also a parameter . This means that you can write type safe container operations like "map" and "filter". The only way to write this kind of generic code in Go is to cast everything to `interface{}`, which can't be checked statically. If you are still not convinced, one of the things you can do with generi…

Yeah I follow you. I am providing ways of trying to work around the lack of a higher level type class system. As a baseline, I would recommend not jumping outside golang's given type system just because it feels inconvenient for the programmer. That means you don't get to write a generic method for, for instance, all integers. Too bad :P This means the programmer does have to do more work, but the type system is always strictly enforced. That is better in my opinion.

Re: From Node.js to Go

#190

Post by omega_rythm »

lumpypua wrote: post #167
liotier wrote: post #166

Earlier quoted context omitted.

> Other programmers write libraries, functionality that is meant > to be used by other programmers to build their code upon. > In this case, you rarely know the context in which a user of > your library will use it, therefore you > cannot really make any decision about types. Uh ? Even for a library you certainly can make decisions about types, document them and enforce them. Who wants to accept unspecified data type…

Literally everyone who's ever written a container.

That doesn't mean no decision has been made: in a typed language with subtyping, this amounts to choose the "top" type of the type hierarchy, and without subtyping, you're choosing not to enforce structural constraints. In untyped languages with structured values (like any usable language), you make those decisions in the way your code checks for this or that value attribute or runtime structure. I guess unspecified and specified as "any" is often the same, but for me the former is a design mistake.
Post reply on HN