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

161–170 of 192 posts

Re: From Node.js to Go

#161

Post by srpeck »

u84six wrote: post #62
billsimpson wrote: post #50

Earlier quoted context omitted.

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

No, I actually do like programming. And I agree with you that there's more to choosing a language than having fun with it. I've had to make that decision for 2 decades. :) But my idea of fun is when I find a language that does a lot with less code, easy to apply patterns, doesn't have a lot of boilerplate, doesn't take a lot of tooling, simple, sleek, and allows any style of programming (e.g. oop, functional, procedu…

You might enjoy Lua (http://www.lua.org/) or k (http://kparc.com/k.txt).

Re: From Node.js to Go

#162

Post by engendered »

wwweston wrote: post #85
engendered wrote: post #81

Earlier quoted context omitted.

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 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 for no external reason, but somehow it benefits their project. This is in contrast to, for instance, JavaScript (which debatably has its own merits) where if you want to script on the web client, that's your choice, love it or leave it. In the Go domain, there are countless alternatives.

I find it hard to even express clearly why Go feels so...natural and productive. But it does. 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. Somehow it works.

If we need to stick with vehicle analogies, it's more like someone is using a dumptruck to move massive piles of Earth, but complaining that the steering isn't as light as their car.

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. Doing the typical "make a library that solves all problems" sort of thing. When I am using Go it is almost always for a specific, practical requirement (as duct tape between processes, to orchestrate some high performance C code, etc), and it just...isn't a problem. It really isn't. Unless you're making library code it just isn't this issue it is held to be.

Re: From Node.js to Go

#163

Post by acdha »

threeseed wrote: post #98
acdha wrote: post #86

Earlier quoted context omitted.

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

Again. Third party tools will have exactly the same benefits. People have been using standard code formatters in Eclipse/IntellIj for what decades now ?

> Again. Third party tools will have exactly the same benefits.

If that were true, the frictional problems I mentioned would not be the rule in every other language. Even something like Python, where PEP-8 has been recommended strongly by the community for many years and has widely available validators and automatic reformatters, still has perpetual low-level debates about this.

In languages like C, where there are multiple well-established conventions, you can still find bitter arguments going on over things like optional braces because there are still tons of bad programmers out there who think it's preferable to ship massive bugs every few years than type two extra characters.

Re: From Node.js to Go

#164

Post by tjholowaychuk »

u84six wrote: post #74
izolate wrote: post #53

So is this is a growing sentiment? Recall that TJ famously left Node.js in favor of Go. I find Node downright amazing for web development. npm has everything you could ask for. And the whole community takes the unix philosophy and runs with it. Also love that there's no single best way to create something, you as the architect, gets to decide. And io.js/ecma6 makes node even more appealing.

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 Node comes close IMO.

Re: From Node.js to Go

#165

Post by acdha »

gnuvince wrote: post #140
acdha wrote: post #86

Earlier quoted context omitted.

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

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'm hoping Go's error handling is improved in 2.0. I understand the objections to Java-style exceptions but I think they underestimated the actual cost of having so much boilerplate clogging up every non-trivial program, not to mention the way it actively encourages people to punt on error checking which is why so many projects are littered with `x, _ := foo()`.

The approach I'd like would be a lightweight assert-style failure mode where the compiler would treat any function which returns an error as being followed an implied `if err != nil { panic("Unhandled error") }` unless the error is checked on the next statement. That'd allow you to handle things which you expect to fail regularly while preventing the litany of bugs in C programs caused by forgetting to check return codes on things which rarely fail.

Re: From Node.js to Go

#166

Post by liotier »

gnuvince wrote: post #141
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 think it depends on the kind of things people write. Most people I see writing Go code seem to be writing programs , a piece of code that performs a specific function for a user. In those cases, you very often know exactly the domain types, and Go's type sy…

  > 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 types ?

Re: From Node.js to Go

#167

Post by lumpypua »

liotier wrote: post #166
gnuvince wrote: post #141

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 think it depends on the kind of things people write. Most people I see writing Go code seem to be writing programs , a piece of code that performs a specific function for a user. In those cases, you very often know exactly the domain types, and Go's type sy…

> 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.

Re: From Node.js to Go

#168

Post by thezelus »

swah wrote: post #144
thezelus wrote: post #106

Earlier quoted context omitted.

Did you get a chance to look into encoding/json package[1]? I come from Java background and have extensively used Gson in projects, I found encoding/json at par with Gson. You can find more examples here[2]. Would you mind if I ask what did you find lacking in Go's json package when compared to Gson? [1] http://golang.org/pkg/encoding/json/ [2] http://www.attilaolah.eu/2013/11/29/json-decoding-in-go/

That's exactly what he is talking about. In a dynamic language, you just parse the JSON and access the resulting object. In Go, you need to have a matching record or use the interface type and implement a decoder.

Oh, apologies. I thought he is talking about Gson[1], and hence the comment.

1. https://code.google.com/p/google-gson/

Re: From Node.js to Go

#169

Post by pswenson »

oscargrouch wrote: post #109

I for one hail our Go overlords, because that way it will mean less Python, Ruby and Javascript code for serious stuff like backends.. Given the language will please this crowd. Theres a lot of good stuff, created by good people, in those languages and while the solutions are great, the fact that they are in those languages, make them unfit for a lot of cases.

how is this a useful comment?

Re: From Node.js to Go

#170

Post by steveklabnik »

laumars wrote: post #97
yellowapple wrote: post #79

Earlier quoted context omitted.

Java's a bit of a special/odd case, since it's AOT-compiled into a bytecode that is then JIT-compiled into native instructions.

Not that unusual these days. CPython supports a similar intermediate binary (.pyo) and .NET does the same too, albeit the bytecode is shipped inside a PE.

And you can't even get that from the language itself. While MRI (last I checked) doesn't support an intermediate file of its bytecode format, Rubinius does (.rbc), for example.
Post reply on HN