From Node.js to Go

http://bowery.io/posts/Nodejs-to-Golang-Bowery/

by francesca • 11 years ago

316 185 11 years ago

drikerf3• 11 years ago

Go is definitely promising but the last time I checked the problem with web development with Go was that there is no mature libraries for User authentication etc(Please correct me if I'm wrong). This makes going with Node or something like Rails more tempting.

voidlogic• 11 years ago

no mature libraries for User authentication

"User authentication" can mean 1,000 different things, maybe if you clarify your use case, people can suggest solutions.

drikerf3• 11 years ago

Agree, that was a bit loose. Something like Passport.js(passportjs.org).

kawliga• 11 years ago

"User authentication" can mean 1,000 different things

you mean like 4 different things... and even those have common components

tptacek• 11 years ago

It's as easy to implement authentication in Golang as it is in Rails. There are gaps in the web stack for Golang (databases are particularly painful), but this isn't one of them.

mrKlin• 11 years ago

Checkout Negroni [1] for middleware configuration combined with restgate [2]

[1] https://github.com/codegangsta/negroni [2] https://github.com/pjebs/restgate

drikerf3• 11 years ago

Negroni looks interesting. I saw there is a middleware called permissions2 that have some nice features. Will check that out, thanks!

steakejjs2• 11 years ago

I wrote a Go Web Application with authentication and an API to learn Golang.

I must say, writing an API and some other services (SMTP pipe listener) was much nicer in Go than Authentication.

There is gorilla/sessions for sessions, but there's a lot to be desired here. A weak secret here means other people can decrypt the SessionStore Blob and possibly get secret information as a passive attacker or authenticate as another user. This sessionstore passphrase is the key to your entire webapp.

There's also nothing built in to Go for CSRF tokens, and HTMLTemplates are nice for preventing XSS but a pain in the butt for embedding, generating, and storing/regenerating (depending on how big you are) CSRF tokens.

Overall though....Writing Go has been pure joy for me. These are super knitpicky things to complain about.

lugg2• 11 years ago

I think those issues will improve over time with maturity. Golang seems to not like to do things in more than one way, as the article stated. Currently there is competing solutions to all of those problems[1]. I suspect you won't see built in solutions until community libs and users choose the prevailing standard solution to each problem.

To also be fair, web apps are nodes bread and butter, not so much so for Golang (apart from maybe api's - which tend to have pretty straight forward auth mechanisms and dont require csrf, xss or templating solutions, traditionally anyway). With that in mind I wouldn't be surprised if go's devs continue to leave web solutions up to the community. I expect to see a lot of frameworks come along similar to pythons django, rubys rails, and phps laravel.

Disclaimer: non elitist node dev, closely watching go

[1] https://github.com/golang/go/wiki/Projects

timClicks• 11 years ago

It's interesting the switch was prompted very few things that are JS vs Go, perhaps concurrency. The main factors were tooling related, enabling stable workflows and easy deployment.

eknkc• 11 years ago

For me the single biggest disadvantage of Go against Node.JS is the lack of a decent dependency management solution. NPM is awesome and Go doesn't even have a "meh" answer to that.

frakkingcylons• 11 years ago

What problems have you had managing dependencies with Go? I use Godep to vendor each dependency and rewrite import paths to use the vendored package. I found it to be an easy and effective solution.

bacongobbler• 11 years ago

I feel and share your pain. I dislike the model of having to vendor in every third party library's source code, so I'm trying to build an alternative tool to Godep[1]. It's still a work in progress but the basic functionality is there :)

[1] https://github.com/fishworks/dis

mcmillion• 11 years ago

NPM is only awesome until you need to do something with it on Windows.

pjmlp3• 11 years ago

Never had any problem with it when we did a Cordova based application for a customer of ours.

u84six4• 11 years ago

What kind of problems are you having with it? I'm using npm on Windows and it's working out great! I'm actually using it as my build/task runner rather than using bloated grunt or gulp. It's easy to configure and read. I run my linter, unit test, jscs, and bundler all configured in package.json.

I also install git bash and conemu to have bash on Windows which makes things much better. I don't use windows console.

britknight• 11 years ago

It's not just npm. A while back I had to set up a Rails dev environment for a client who used Windows. shudder.

xasos• 11 years ago

Maybe it's just me, but I really like the way Go does package management. Not needing to publish to a central place for packaging is awesome (just have it on any website), but I agree that it needs reorganization (godep is a step in the right direction)

enahs-sf2• 11 years ago

Go does lack quite a bit of the web pizzazz you'd find in rails, but I learned a lot more by writing web things in go than I did in rails because so much less of the magic is hidden away from you.

artursapek• 11 years ago

You can't really compare Go with Rails...

enahs-sf2• 11 years ago

This is true. They really are apples and oranges; but when life gives you lemons, I choose web frameworks.

tete• 11 years ago

I'd consider that a feature of Go. At least that this is not your only way.

What you want is maybe something like Beego.

http://beego.me/

touristtam• 11 years ago

I ve given beego a go and although it is closer to a full stack solution to write in golang, I find it lacking still, and I am still looking for someone to share their experience by example moving from NodeJs.

unoti• 11 years ago

This was something keeping me back from Go before. However, in 2015 when you're doing so much more on the client, and things like Angular and React are available, this concern becomes reduced or eliminated.

biot• 11 years ago

Would you have had the same experience by coding directly in Ruby? The magic of Rails would similarly be hidden from you, forcing you to learn what's going on under the hood.

mrcwinn2• 11 years ago

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 typical web development. That's not a rule by any means. Just pick the right tool for the job.

kxo• 11 years ago

systems

Here we go.

wldcordeiro• 11 years ago

Go is a language and Rails is a framework though it's not even an apt comparison. Ruby and Go is a better comparison though still not the best.

emehrkay• 11 years ago

"but he didn’t learn his lesson there"

This set me up for a negative article about Go, but, like other Go-related materials, it makes me want to use it. I should use it.

angersock• 11 years ago

"Something must be done. This is something. Ergo, we must do it."

Why should you use it? What problems does it solve for you?

balls1872• 11 years ago

Go is a compiled language so distributing applications for use on multiple platforms is just easier.

How is this a true statement? Ease of distribution isn't a function of a language's runtime environment (native vs interpreter).

andrewchambers2• 11 years ago

They just mean static compilation, the program is a single file with all dependencies linked inside it.

Touche2• 11 years ago

Presumably he's talking about statically linked binaries.

mrcwinn2• 11 years ago

Sure it's a true statement. Even if you have to compile to different targets (and you do), that's much simpler than implementing shared dependencies on those different targets. When you deploy a binary with no external dependencies, you can (generally) set it and forget it.

It's not to say there aren't meaningful differences across targets you need to account for, but it is "just easier" in my experience.

balls1872• 11 years ago

So, it's not a function of compiled vs interpreted. It's about a single binary vs shared resources.

So while you can't get a single binary with an interpreted language (you need the shared runtime), however you can also get shared libs using a compiled language.

I've found doing cross platform development using NodeJS significantly easier than using C++ (of course I had to use compilers that didn't default to IEEE 764).

So old.

gsastry• 11 years ago

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.

stanleee2• 11 years ago

You can use this (https://halcyon.sh) for Haskell. Still not the same though.

alanning2• 11 years ago

You may wish to explore Rust - http://www.rust-lang.org/. I can't speak to tooling but it has advanced typing and ease of distribution seems similar to Go.

Edit: mea culpa for my attempt at tongue-in-cheek humor, "I think that's called Rust - http://www.rust-lang.org/"

stanleee2• 11 years ago

Rust's type system is definitely more robust than Go's, however it's also a different language and different philosophy. Go was created to be easy to read and easy to write, which is mirrored in the language (e.g. no generics). Rust is more complex, which might be a factor when deciding between Go and Rust. Plus it does not have the same adoption in the industry as Go.

munro• 11 years ago

Yea, I really like GADT too much to give it up. With Swift/Haxe/Rust/Haskell/F# all having them.

You may find this interesting, someone implemented a parsec-like library in Go [1]. I haven't wrapped my head around it completely, but it looks like it's all dynamic [2].

[1] https://godoc.org/github.com/prataprc/goparsec [2] https://github.com/prataprc/goparsec/blob/master/json/json.g...

platz• 11 years ago

Are you sure GADTs are possible in Swift and F#? I haven't seen what syntax supports that in those languages. Do you just mean Discriminated Unions (i.e. ADTs). There is a difference between GADT and ADT.

jallmann• 11 years ago

OCaml is usually statically compiled with ocamlopt, so distribution is pretty easy. As long as build/deploy platforms match, then you're good to go. Shared libraries only come into the picture for unusual cases, eg FFI.

OCaml tooling has also gotten a lot better over the past few years, mainly because of OPAM. The library count has exploded, and the language still gets regular point-releases with improvements designed to aid tooling, such as extension points.

djur• 11 years ago

The last serious project I tried to do with OCaml (maybe 4 months ago) was impeded by a ton of dependency problems (this library in OPAM says it depends on this other library, but it doesn't compile because the latter has changed; this dependency won't build in OCaml version .X but another one won't build in .X-1) and ecosystem sparseness (two partially-complete, years-old libraries to do the same thing, etc.). I was eventually stopped in my tracks by an impressively opaque camlp4 error.

(My favorite example is when in #ocaml I asked what testing tools people used; the most positive answer was along the lines of "there's OUnit, but I don't know anything about it".)

There seems to be three awkwardly coexisting OCaml communities: the old academic crowd, the Jane Street people, and a crowd of clueless newbies like myself. It's a really great language, but the ecosystem is going through some growing pains right now.

kingmanaz• 11 years ago

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, I do wish Go 1.4 retained the Vim plugin that was bundled with the earlier distributions. I've had nothing but trouble setting up vim-go and its myriad of dependencies on Windows. The process was so easy before.

gnuvince3• 11 years ago

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.

wiremine• 11 years ago

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 a canonical dep management tool for go.

- The tooling for Go is excellent: More languages need something like "go fmt".

- In general the document is solid, but I've found the usability of the generated docs to be poor. You think they could bribe a few Google designers to spend some time fixing that...

- 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. The only issue is parsing JSON when you're not marshalling it to struct. They need to fix that (although there are some nice third-party tools to make it easier).

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

[1] https://github.com/tools/godep

[2] http://stevebate.silvrback.com/go-is-boring

TheCoelacanth• 11 years ago

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.

chimeracoder2• 11 years ago

saying that your type system doesn't have generics is like saying your car doesn't have wheels.

To overburden an analogy, it'd be more like complaining that your tank doesn't have wheels[0], or your hovercraft. Go takes a different approach to the same problem (in this analogy, getting from point A to point B).

But really, this is a rather tired flamewar that gets beaten to death literally every time a post about Go makes the front page, and there's really nothing more that can be said about it. Either program in idiomatic Go, which means using the language as it's designed (ie, without generics, at least in its current form), or don't, but it's very tiresome to see this argument rehashed again and again.

[0] https://en.wikipedia.org/wiki/Continuous_track#mediaviewer/F...

engendered4• 11 years ago

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.

shurcooL• 11 years ago

There are two types of people.

istvan__• 11 years ago

This was one of my main complaint against Go.

However, I still think the out of the box performance is great and for problems that don't require generics it is a very good option. I especially like the static compiling feature that makes deployments more straightforward. Handling HTTP requests and performing routing, dispatching requests to other services reliable async way is the biggest use case for me using Go. It can totally be written in any other language(Rust), if using generics is a must.

Animats2• 11 years ago

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 really fancy type system with generics. Mostly you're pushing strings around, which Go does quite well.

Rust's type system has most of the bells and whistles of C++, plus some new ones. It's clever, well thought out, sound, and bulky. Rust has very powerful compile-time programming; there's a regular expression compiler that runs at compile time. I'm concerned that Rust is starting out at the cruft level it took C++ 20 years to achieve. I shudder to think of what things will be like once the Boost crowd discovers Rust.

The lack of exception handing in Rust forces program design into a form where many functions return "Result" or "Some", which are generic enumeration/variant record types. These must be instantiated with the actual return type. As a result, a rather high percentage of functions in Rust seem to involve generics. There are some rather tortured functional programming forms used to handle errors, such as ".and_then(lambda)". Doing N things in succession, each of which can generate an error, is either verbose (match statement) or obscure ("and_then()"). You get to pick. Or you can just use ".unwrap()", which extracts the value from a Some form and makes a failure fatal. It's tempting to over-use that.

The lack of exception handling in Go yields too many "goto" statements. There's also a tendency to turn the panic/recover mechanism into an exception system. This has roughly the problems of C's" longjmp".

As a practical matter, Go now has most of the libraries you need for server-side programs. (Not GUI programs, though.) Rust has only very basic libraries, and they're not stable yet. The language hasn't quite settled down. People are writing and porting libraries at a good pace, and this problem will be solved.

Kiro3• 11 years ago

I've never used a typed language at all (only PHP, JS, Python etc). Why is it a big deal? I read the Wikipedia article but didn't understand why.

rogpeppe1• 11 years ago

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-safe as in any language with parametric polymorphism.

For example, bufio.NewReader would probably, in a language with generics, be phrased as a type with respect to a type parameter. Something like (in bastard Haskell)

    class Reader a where
        Read :: a -> [Char]


    newReader :: (Reader a) => a -> BufioReader a

In Go, it's:

    package bufio
    func NewReader(r io.Reader) *Reader

The interface argument is implicitly a type parameter here.

This subset of generics covers a wide range of software components, even if it doesn't include the usual container types.

burntsushi2• 11 years ago

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.

That's ridiculous. Plenty of people can appreciate the trade offs between "no generics" and "generics." There's nothing "non-negotiable" about it.

bsg75• 11 years ago

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

chimeracoder2• 11 years ago

- 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 several years at that point.

- I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see a canonical dep management tool for go.

For what it's worth, Docker has more or less replaced this need for me. I know it doesn't actually do "dependency management" in the traditional sense, but by the time that ad-hoc vendoring no longer works, I've found it's already time to start using Docker for deployment for other reasons anyway. At this point, it's just as easy to use Docker to manage the dependencies at the application level while developing as well.

neurosnap• 11 years ago

As someone who has recently ventured into the world of Docker, I have been questioning if there is a need for virtualenv anymore, especially in production.

Sphax2• 11 years ago

I'm curious, how does Docker help with that ? You still need to include the dependencies somehow, either by vendoring or using something like Gom, or straight go get.

aninhumer• 11 years ago

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.

threeseed2• 11 years ago

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.

acdha3• 11 years ago

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.

orkoden• 11 years ago

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

eklavya• 11 years ago

Actually languages with stronger/more capable type systems are a feature and like all features they are wanted by some people who find that it makes their life easier.

Not having a strong type system is not a fault per say it's just that I need a strong type system as a feature(indispensable for me).

For me choosing between Go and Rust is mostly because of the type system.

If Go works for you then it's fine. Although if you want to find out how type system can help you, it's a different story.

insertnickname• 11 years ago

- In general the document is solid, but I've found the usability of the generated docs to be poor. You think they could bribe a few Google designers to spend some time fixing that...

Please elaborate. What exactly do you mean?

gnuvince3• 11 years ago

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.

liotier• 11 years ago

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

fit2rule• 11 years ago

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

tmaly• 11 years ago

I will give Rust a try when it has a solid library like Go

u84six4• 11 years ago

I'm having a hard time enjoying Go. It just reminds me a little too much of Java, and I programmed in that language for way too long. After I finished my test program, I uninstalled the toolkit from my system. Right now, I feel that there's no perfect language for me. I do love JavaScript, but there are some things I wish they'd fix. And it takes browser makers way too long to support the latest features. Been messing around with Erlang. Kind of an interesting language.

billsimpson3• 11 years ago

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 implementing. This is, of course, easier said then done.

u84six4• 11 years ago

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, procedural). Like I said, I've tried Go and it just didn't feel like that. It felt like, well, Java. The language I used to build apps in the 90s.

sshillo• 11 years ago

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 hand, building you own messaging queue or doing heavy mathematical processing might be better suited for Go.

falcolas• 11 years ago

Fwiw, I have been doing a lot of crud work in Gonthe past few months, and haven't found it particularly burdensome. I have to write my own SQL and map it back to structs, but I consider that a good thing. I might have to write about some lessons learned.

kochthesecond• 11 years ago

Please do. I come from java, and am currently finding Go a bit cumbersome to work with. No Exceptions, lots of nil checks and a poorer ide makes it quite a bit of work. I also find testing a bit harder to do, but it's probably because I'm in a javian mindset.

collyw• 11 years ago

Do you mind me asking why you chose Go? It sounds like the problems you have would all be solved by using a traditional language with a mature framework or ORM.

je423• 11 years ago

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.

muraiki• 11 years ago

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

nawitus4• 11 years ago

In Go, you can define different files for different operating systems that implement functionality depending on the operating system.

That sounds like it's actually very difficult to support multiple operating systems. As a developer I never, ever want to write any OS-specific code. Sure, that's sometimes required, but saying that the solution is to have multiple files, each for a single OS, doesn't sound good. It's a lot better to abstract the OS away. Node.js does this quite well. Seemingly a lot better than Go.

Besides, Node.js doesn't need to be compiled for each system. This alone makes Node.js better for writing code for multiple operating systems.

Go is a compiled language so distributing applications for use on multiple platforms is just easier.

I disagree. You need to compile to code for every single platform, making code distribution costly. With Node.js you can simply distribute the code as it is and it probably works in any platform. (The probability is as high as it is for Go assuming no extra work for a new platform). Sure, each platform needs to have Node.js, but Node.js is supported in most platforms.

laumars4• 11 years ago

That's a very naive argument. There are so many other variables in choosing a cross platform language which you've overlooked:

]] Performance (AOT compiled languages will typically out perform JIT compiled language

]] user interface (is this going to be a command line app? Does it need a GUI? And if so, what frameworks are supported and do they need any OS specific boiler plate code?)

]] required runtime environment (does your language tool chains support compiling to a native binary (Windows PE / Linux ELF) or do you need a language runtime environment? And if the latter, what's the likelihood of the target OS having said framework pre-installed?)

I'm not trying to take anything away form Javascript / Node, but it loses as many points as it wins. And frankly both languages fail compared to some other languages too.

Personally I mostly target Linux and FreeBSD, but the majority of my Go tools will compile for Windows with zero code changes (the standard Go libraries actually do abstract away most OS specific discrepancies) and all of my code works on Linux and FreeBSD without any Linux / BSD specific code. So I think the issues of different files for different OSs is overstated anyway.

nawitus4• 11 years ago

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 make any arguments about that either.

required runtime environment

Now that's relevant when it comes to cross-platform distribution. Node.js has that covered pretty well.

I'm not trying to take anything away form Javascript / Node, but it loses as many points as it wins

My comment was not about Node.js vs Go as a whole, it was about developing cross-platform software.

So I think the issues of different files for different OSs is overstated anyway.

If you look at the core issue here, it's that theoretically speaking "all things equal" Go and Node.js needs about as much work to implement a new feature that works with most platforms. However, on top of that Go requires a compilation step for every supported platform, and that's not required for Node.js.

However, Node.js requires someone to compile the Node.js environment for each supported platform. For most cases that's already done.

This is my core argument that Node.js does cross-platform development better. It's one of the things that Java and C# got right.

swdunlop• 11 years ago

That sounds like it's actually very difficult to support multiple operating systems. As a developer I never, ever want to write any OS-specific code.

You may not, but if you want something to work on multiple platforms that someone else has not abstracted, you have to do it anyway. When you do, you may want something more orthogonal than cpp macros.

billsimpson3• 11 years ago

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 code distribution costly. With Node.js you can simply distribute the code as it is and it probably works in any platform.

You're missing the point about distribution. Let's say you write a non-trivial command line application, and want to distribute it to your clients. With Go, you can distribute your program as a self-contained executable file. 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 Windows, OS X, etc. executables. The cost is negligible.

Compare that to Node. How are you going to distribute your Node app to clients? Is every client going to install Node on their personal computer? Will they be able to figure out NPM? Yes, it's easy, but they'll mess it up anyway. What happens when the network has a hiccup and npm doesn't download your dependencies correctly, or they try to upgrade your dependencies and everything breaks?

If you plan on distributing your Node code, you're pretty much limited to distributing it to other Node developers. That's not going to work for everybody.

nawitus4• 11 years ago

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 Windows, OS X, etc. executables.

Except when the developer only compiles for Windows and Linux, but someone wants to run the code on Mac os X.

Will they be able to figure out NPM? Yes, it's easy, but they'll mess it up anyway.

You don't need NPM. You can fetch the dependencies and include that with the installer. There's a downside to that, though, which is binary-packages with npm.

rakoo• 11 years ago

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

It actually depends what you want to do. Since Go tends to be low-level, there may be a moment where your code goes into syscall land, in which case you're going to be OS-specific.

The most recent example I have in mind is mmaping a file: see https://github.com/edsrzf/mmap-go: there is a windows- and a unix- specific version. If you're using something else, you're out of luck (with this package at least)

There is a syscall package, but it's just piling up a lot of syscalls with already some OS-specific stuff. It is going to be so much of a burden to manage that the Go team plans to abstract this in a new package (https://golang.org/s/go1.4-syscall)

izolate2• 11 years ago

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.

u84six4• 11 years ago

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.

tjholowaychuk2• 11 years ago

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.

htilford• 11 years ago

They left out the most obvious reason for them to switch. Their business is based on docker, coreOS etc . . . aka the Go ecosystem. In that context developing Go expertise just makes business sense regardless of technical merits.

akhilcacharya• 11 years ago

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.

thezelus2• 11 years ago

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/

swah• 11 years ago

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.

20kleagues• 11 years ago

It is frustrating to see how many Go vs Node posts are happening here. I have been implementing a bluetooth LE module in Go, and due to lack of some robust libraries, had to go back to Node. This is primarily a question of maturity, but I also realised that my use-case didn't really need the thing which Go is most useful for - namely really really good concurrency primitives. I am quite sceptical about Node's future because of that forking fiasco, but at this point in time, both Node and Go provide enough distinct functionality that both will be used for a long time.

gankgu• 11 years ago

Golang only 2x ruby at net/http level and same as ruby at web framework level ?

https://news.ycombinator.com/item?id=8964255

grey-area• 11 years ago

On render speed, if you're trying to serialize json 1 million times a second, the benchmark you linked might have some relevance, if not, then you're being misled by looking at benchmarks like that, which measure an app doing not very much millions of times a second, so basically they're stressing the routing path and the json serialisation speed. This is unlikely to be a problem you ever encounter and if you did you'd just rip out the bits you don't need for that path - use static routing, cache json etc, and your speed would be massively improved.

Speed is not the only concern, or even the biggest concern, for most web apps, the constraints nowadays are typically in something like this order:

- Memory - CPU - Bandwidth - Database - Render speed

Clearly that doesn't hold true for all sites, but for most the order is something like that because with caching you can obviate any render speed concerns very easily. On memory and CPU usage, golang completely trounces a solution like Rails (I say this having built similar sites in both) - it's better by a factor of 10, which means you can run a pretty big site with very spartan resources.

The largest obstacles to go replacing languages like ruby as a tool for web apps is more that the libraries at present are not available for everything you might want to do (user auth, sophisticated templating, csrf, fragment caching, form helpers, orms and query builders etc), but that situation is steadily improving, and the standard library is pretty excellent as far as it goes.

oscargrouch• 11 years ago

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.

pswenson• 11 years ago

how is this a useful comment?

jcoffland• 11 years ago

Why on earth would a line editor need platform specific code? Sounds like a case of that's-a-cool-feature-let's-use-it!!!

je423• 11 years ago

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 no free-lunch. The standard will be insufficient for some his usecases and then what....

Node.js out of the box embraces multiple solutions - I know this can be overwhelming, but it gets better over time not worse. When you know, the trade-offs between the different choices, you feel empowered to pick the best tool / lib for the job.

spronkey2• 11 years ago

I think there's a difference between standards at the language level and standards in library code.

There's also the point of simplicity at which it actually doesn't matter how something is accomplished, only that it is, which is where the Node.js ecosystem falls apart. Too many libraries with half-baked feature sets, each new library built because the developer didn't like the last one.

skygazer• 11 years ago

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.

rmetzler• 11 years ago

One thing I hate about JS and the thing I love about Golang: the error handling. I love that there is only one way to do it in Go.

ok, More actually. Some APIs return ok instead of err.

jonpress• 11 years ago

I disagree with the concurrency part. Node.js has excellent built-in IPC support through the process and child_process objects.

Since Node.js is JavaScript, you can't possibly argue that Go code is more 'portable' than Node.js. For one, JavaScript can run on more machines than any other language.

Go will not run in the browser because most browser vendors will not let that happen. On the other hand, JavaScript is already universally accepted by everyone and it's everywhere - You can run JS in the browser, natively on mobile devices, on the server, on set-top-boxes, on robots/IoT devices and just about everywhere you can imagine. Anybody can implement and modify their own JavaScript engine to suit their specific needs.

No need to worry about protocols - Since JSON is a subset of JavaScript, you can seamlessly pass objects between the client and the server and no need to context switch between programming styles when going between client and server.

People who don't like JavaScript mostly feel that way because they don't understand it well enough (it's a lot more expressive and powerful than people imagine). I have programmed in many different languages - C/C++, C#, Java, ActionScript 3, Python, AVR Assembly (ATMEL ATMEGA8-16PU microcontrollers and family) and a few others but I feel that no other language has the expressiveness and elegance of JS.

Before I got into Node.js, I considered myself 'language agnostic' because I often switched between languages because no one language could do everything I needed. I no longer consider myself an agnostic - In fact, I feel quite comfortable saying that C/C++ and JavaScript are the only two languages worth knowing.

In reality, you can't be 'fluent' in that many languages because fluency requires constant practice - It makes sense to settle on fewer languages - Mastering a language/tool allows you to focus on what's really important - Logic and structure.

From Node.js to Go

Related Stories