17 ms·

From Node.js to Go

316 points by francesca 12y ago

drikerf 12y 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 12y 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.
  - drikerf 12y ago
    Agree, that was a bit loose. Something like Passport.js(passportjs.org).
  - kawliga 12y ago
    > "User authentication" can mean 1,000 different things you mean like 4 different things... and even those have common components
- tptacek 12y 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 12y ago
  Checkout Negroni [1] for middleware configuration combined with restgate [2] [1] https://github.com/codegangsta/negroni https://github.com/codegangsta/negroni [2] https://github.com/pjebs/restgate https://github.com/pjebs/restgate
  - drikerf 12y ago
    Negroni looks interesting. I saw there is a middleware called permissions2 that have some nice features. Will check that out, thanks!
- steakejjs 12y 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.
  - lugg 12y 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 https://github.com/golang/go/wiki/Projects
    - steakejjs 12y ago
      I agree. Go was really nice to write code in since I do a huge variety of system level and Web things. It's my goto for practically everything now. It will get better but for now I think writing a full web-app in Go, (presentation etc) is pretty annoying.
      - lugg 12y ago
deleted 12y ago
[deleted]
timClicks 12y 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 12y 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 12y 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 12y 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 https://github.com/fishworks/dis
- mcmillion 12y ago
  NPM is only awesome until you need to do something with it on Windows.
  - pjmlp 12y ago
    Never had any problem with it when we did a Cordova based application for a customer of ours.
    - kybernetikos 12y ago
      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 you could naturally fit into the node ecosystem to build native libraries.
enahs-sf 12y 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 12y ago
  You can't really compare Go with Rails...
  - enahs-sf 12y ago
    This is true. They really are apples and oranges; but when life gives you lemons, I choose web frameworks.
- tete 12y 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/ http://beego.me/
  - touristtam 12y 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 12y 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 12y 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.
- deleted 12y ago
emehrkay 12y 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 12y 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?
balls187 12y 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).
- andrewchambers 12y ago
  They just mean static compilation, the program is a single file with all dependencies linked inside it.
- Touche 12y ago
  Presumably he's talking about statically linked binaries.
- mrcwinn 12y 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.
  - balls187 12y 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.
    - laumars 12y ago
      Minor nit pick, but theses days "interpreted" languages are also compiled. What we are really taking about is AOT vs JIT (though even here, there are AOT compiled languages that still require a supporting run time environment installed, such as Java)
gsastry 12y 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.
- stanleee 12y ago
  You can use this (https://halcyon.sh https://halcyon.sh) for Haskell. Still not the same though.
- alanning 12y ago
  You may wish to explore Rust - http://www.rust-lang.org/ 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/" http://www.rust-lang.org/"
  - stanleee 12y 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.
    - alanning 12y ago
      No argument here. OP specifically mentioned advanced typing, tooling, and distribution. Rust covers at least two out of the three (can't speak to tooling) so I thought OP might like to explore it a bit.
- munro 12y 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 https://godoc.org/github.com/prataprc/goparsec [2] https://github.com/prataprc/goparsec/blob/master/json/json.go#L60-L86 https://github.com/prataprc/goparsec/blob/master/json/json.g...
wiremine 12y 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 https://github.com/tools/godep [2] http://stevebate.silvrback.com/go-is-boring http://stevebate.silvrback.com/go-is-boring
- TheCoelacanth 12y 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.
  - chimeracoder 12y 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/File:Caterpillar_track_shingle.JPG https://en.wikipedia.org/wiki/Continuous_track#mediaviewer/F...
u84six 12y 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.
- billsimpson 12y 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.
  - u84six 12y 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.
    - billsimpson 12y ago
      That does sound fun. Let me know if you find it.
    - gcv 12y ago
      Any modern Lisp gets you there. The three leading dialects, namely Common Lisp, Racket, and Clojure, are all excellent. Each makes different trade-offs in what it offers. As a former Java programmer, you will probably like Clojure's near-perfect Java interop and excellent performance. Racket is probably the best batteries-included language and environment available today. Common Lisp is a bit grandfatherly, but it's the kind of grandfather who teaches you to fly his aerobatics plane. Its condition system, in particular, should be required study to anyone who purports to design languages and runtimes. I read up and played with Rust earlier this week. It's also excellent, and while it's too young and has been too volatile for libraries to solidify, that will change in the next few months. The tooling (as far as Emacs modes and the dependency/build system, Cargo, are concerned) looks solid. Performance is already decent, and has the potential to eventually match C. To be honest, Rust feels like what Go would have been had its authors understood Lisp and Haskell.
deleted 12y ago
[deleted]
sshillo 12y 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 12y 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 12y 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 12y 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.
- je42 12y 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 12y ago
    Not exactly what you're looking for, but it might help: http://notes.ericjiang.com/posts/791 http://notes.ericjiang.com/posts/791
nawitus 12y 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.
- ossreality 12y ago
  >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. lmao. Fine, ship the go source code and require go to be installed on the target. "go run" and you're done. >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. I don't think you know what you're talking about or understand what you're really saying.
- laumars 12y 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.
izolate 12y 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.
- u84six 12y 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.
  - tjholowaychuk 12y 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.
    - izolate 12y ago
      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.
      - tjholowaychuk 12y ago
        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.
htilford 12y 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 12y 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.
- deleted 12y ago
  [deleted]
- thezelus 12y 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/ http://golang.org/pkg/encoding/json/ [2] http://www.attilaolah.eu/2013/11/29/json-decoding-in-go/ http://www.attilaolah.eu/2013/11/29/json-decoding-in-go/
  - swah 12y 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.
    - thezelus 12y ago
      Oh, apologies. I thought he is talking about Gson[1], and hence the comment. 1. https://code.google.com/p/google-gson/ https://code.google.com/p/google-gson/
20kleagues 12y 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 12y ago
Golang only 2x ruby at net/http level and same as ruby at web framework level ? https://news.ycombinator.com/item?id=8964255 https://news.ycombinator.com/item?id=8964255
- grey-area 12y 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 12y 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 12y ago
  how is this a useful comment?
jcoffland 12y 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!!!
je42 12y 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.
- spronkey 12y 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 12y 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 12y 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 12y 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.

316 points by francesca 12y 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 12y 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.
- drikerf 12y ago
  Agree, that was a bit loose. Something like Passport.js(passportjs.org).
- kawliga 12y ago
  > "User authentication" can mean 1,000 different things you mean like 4 different things... and even those have common components
tptacek 12y 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 12y ago
Checkout Negroni [1] for middleware configuration combined with restgate [2] [1] https://github.com/codegangsta/negroni https://github.com/codegangsta/negroni [2] https://github.com/pjebs/restgate https://github.com/pjebs/restgate
- drikerf 12y ago
  Negroni looks interesting. I saw there is a middleware called permissions2 that have some nice features. Will check that out, thanks!
steakejjs 12y 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.
- lugg 12y 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 https://github.com/golang/go/wiki/Projects
  - steakejjs 12y ago
    I agree. Go was really nice to write code in since I do a huge variety of system level and Web things. It's my goto for practically everything now. It will get better but for now I think writing a full web-app in Go, (presentation etc) is pretty annoying.
    - lugg 12y ago

deleted 12y ago

[deleted]

timClicks 12y 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 12y 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 12y 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 12y 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 https://github.com/fishworks/dis
mcmillion 12y ago
NPM is only awesome until you need to do something with it on Windows.
- pjmlp 12y ago
  Never had any problem with it when we did a Cordova based application for a customer of ours.
  - kybernetikos 12y ago
    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 you could naturally fit into the node ecosystem to build native libraries.

enahs-sf 12y 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 12y ago
You can't really compare Go with Rails...
- enahs-sf 12y ago
  This is true. They really are apples and oranges; but when life gives you lemons, I choose web frameworks.
tete 12y 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/ http://beego.me/
- touristtam 12y 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 12y 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 12y 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.
deleted 12y ago

emehrkay 12y 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 12y 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?

balls187 12y 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).

andrewchambers 12y ago
They just mean static compilation, the program is a single file with all dependencies linked inside it.
Touche 12y ago
Presumably he's talking about statically linked binaries.
mrcwinn 12y 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.
- balls187 12y 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.
  - laumars 12y ago
    Minor nit pick, but theses days "interpreted" languages are also compiled. What we are really taking about is AOT vs JIT (though even here, there are AOT compiled languages that still require a supporting run time environment installed, such as Java)

gsastry 12y 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.

stanleee 12y ago
You can use this (https://halcyon.sh https://halcyon.sh) for Haskell. Still not the same though.
alanning 12y ago
You may wish to explore Rust - http://www.rust-lang.org/ 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/" http://www.rust-lang.org/"
- stanleee 12y 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.
  - alanning 12y ago
    No argument here. OP specifically mentioned advanced typing, tooling, and distribution. Rust covers at least two out of the three (can't speak to tooling) so I thought OP might like to explore it a bit.
munro 12y 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 https://godoc.org/github.com/prataprc/goparsec [2] https://github.com/prataprc/goparsec/blob/master/json/json.go#L60-L86 https://github.com/prataprc/goparsec/blob/master/json/json.g...

wiremine 12y 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 https://github.com/tools/godep [2] http://stevebate.silvrback.com/go-is-boring http://stevebate.silvrback.com/go-is-boring

TheCoelacanth 12y 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.
- chimeracoder 12y 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/File:Caterpillar_track_shingle.JPG https://en.wikipedia.org/wiki/Continuous_track#mediaviewer/F...

u84six 12y 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.

billsimpson 12y 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.
- u84six 12y 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.
  - billsimpson 12y ago
    That does sound fun. Let me know if you find it.
  - gcv 12y ago
    Any modern Lisp gets you there. The three leading dialects, namely Common Lisp, Racket, and Clojure, are all excellent. Each makes different trade-offs in what it offers. As a former Java programmer, you will probably like Clojure's near-perfect Java interop and excellent performance. Racket is probably the best batteries-included language and environment available today. Common Lisp is a bit grandfatherly, but it's the kind of grandfather who teaches you to fly his aerobatics plane. Its condition system, in particular, should be required study to anyone who purports to design languages and runtimes. I read up and played with Rust earlier this week. It's also excellent, and while it's too young and has been too volatile for libraries to solidify, that will change in the next few months. The tooling (as far as Emacs modes and the dependency/build system, Cargo, are concerned) looks solid. Performance is already decent, and has the potential to eventually match C. To be honest, Rust feels like what Go would have been had its authors understood Lisp and Haskell.

deleted 12y ago

[deleted]

sshillo 12y 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 12y 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 12y 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 12y 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.
je42 12y 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 12y ago
  Not exactly what you're looking for, but it might help: http://notes.ericjiang.com/posts/791 http://notes.ericjiang.com/posts/791

nawitus 12y 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.

ossreality 12y ago
>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. lmao. Fine, ship the go source code and require go to be installed on the target. "go run" and you're done. >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. I don't think you know what you're talking about or understand what you're really saying.
laumars 12y 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.

izolate 12y 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.

u84six 12y 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.
- tjholowaychuk 12y 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.
  - izolate 12y ago
    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.
    - tjholowaychuk 12y ago
      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.

htilford 12y 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 12y 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.

deleted 12y ago
[deleted]
thezelus 12y 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/ http://golang.org/pkg/encoding/json/ [2] http://www.attilaolah.eu/2013/11/29/json-decoding-in-go/ http://www.attilaolah.eu/2013/11/29/json-decoding-in-go/
- swah 12y 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.
  - thezelus 12y ago
    Oh, apologies. I thought he is talking about Gson[1], and hence the comment. 1. https://code.google.com/p/google-gson/ https://code.google.com/p/google-gson/

20kleagues 12y 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 12y ago

Golang only 2x ruby at net/http level and same as ruby at web framework level ? https://news.ycombinator.com/item?id=8964255 https://news.ycombinator.com/item?id=8964255

grey-area 12y 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 12y 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 12y ago
how is this a useful comment?

jcoffland 12y 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!!!

je42 12y 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.

spronkey 12y 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 12y 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 12y 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 12y 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.