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

141–150 of 192 posts

Re: From Node.js to Go

#141

Post by gnuvince »

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 system is perfectly adequate there.

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. This is a big reason why people like having parametric polymorphism.

The constant arguments that we see online probably comes from people writing programs and people writing libraries arguing with one another without understanding the context in which the other writes code.

Re: From Node.js to Go

#142

Post by gnuvince »

kingmanaz wrote: post #60
gsastry wrote: post #16

I wish a language with advanced types like Haskell or OCaml would have the same tooling and ease of distribution around it that Go does. I haven't built anything in Haskell/ML in a while, so if anyone has any updates on this please chime in.

>I wish a language with advanced types like Haskell or OCaml would have the same tooling and ease of distribution around it that Go does. I love the philosophy behind Go and enjoy coding in the language, and the tooling is a major part what makes development in Go such a breeze. Go seems to be consistently praised for its tooling and I suspect the developers of other languages are paying attention. Having said that,…

OCaml does have opam (package manager), ocp-indent (a code formatting backend), merlin (a code formatting front-end for Emacs, Vim and Acme), a REPL, a byte code compiler, a native code compiler, a debugger that supports stepping backwards, can integrate with gprof, has ocamllex for building scanners, merlin for building LR(1) parsers, etc. And OCaml's been gaining speed in the past years, so there's a lot of nice things to see there.

Re: From Node.js to Go

#143

Post by Gurkenmaster »

laumars wrote: post #68
nawitus wrote: post #63

Earlier quoted context omitted.

>Performance I didn't argue anything about performance. Go might have better performance than Node.js, but that doesn't make Go better for cross-platform distribution! They are separate factors. If performance is your top priority and Go has better performance than Node.js then choose Go while acknowledging that it's possible that Node.js has better cross-platform code distribution support. >user interface I didn't m…

javascript requires you install Node on your target platform alongside your Javascript program, where as Go doesn't. So the extra step you described gets equalled out. as I said, it's very naive to blanket claim that node is better for cross platform development. If I'm completely honest, i find people who say languages are definitively better at boardly defined subjects are usually lacking objectivity. Programming c…

What prevents me from bundling node with the app? That's how NW.js does it. (I hate the 100MB wasted space)

Re: From Node.js to Go

#144

Post by swah »

thezelus wrote: post #106
akhilcacharya wrote: post #91

I'm primarily a mobile dev, so the biggest impediment to me adopting Go over Node is the fact that converting and manipulating my data models to send as JSON documents is considerably harder on Go - there's no Go equivalent to Gson yet, nor will there likely ever be due to the nature of the language.

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.

Re: From Node.js to Go

#145

Post by fit2rule »

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…

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

Tried Lua? Your opinion interests me ..

Re: From Node.js to Go

#146

Post by orkoden »

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.

It always great to have whole files change because your coworker is using a different code formatting template for Java in his eclipse.

Re: From Node.js to Go

#147

Post by aninhumer »

chimeracoder wrote: post #43
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…

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

>Within less than a month, I was as productive in Go as I was in Python

That's not really surprising. Go is actually pretty similar to Python in a lot of ways, the most obvious being the set of built-in data structures.

Re: From Node.js to Go

#148

Post by muraiki »

je42 wrote: post #119
sshillo wrote: post #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 h…

Actually, I would like to see a case by case comparison why / how go's concurrency primitives are nicer/better than something equivalent in node.js/javascript.

Not exactly what you're looking for, but it might help: http://notes.ericjiang.com/posts/791

Re: From Node.js to Go

#149

Post by skj »

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…

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

Re: From Node.js to Go

#150

Post by skj »

rogpeppe1 wrote: post #128
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.

FWIW Go does implement a significant subset of generics in a type-safe way. For any parametric type P[T], if P has no public methods or fields that mention T, then Go can implement it by allowing an interface (not necessarily interface{}) type for T. As long as the implementation of P does not upcast T values (something which is generally frowned upon, although tolerated in some circumstances), this will be as type-s…

I think it's important to think of these features in terms of their smallest possible descriptions. One mistake with Java, I think, is that "inheritance" is how you do both polymorphism and composition (I know you can do either without inheritance, but it's especially a pain to do composition without).

With Go, polymorphism is done with interfaces. Composition is done with embedded fields (and the very convenient method promotion).

Post reply on HN