Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Node.js to Go

bowery.io

Post reply on HN
Print view View original

71–80 of 192 posts

Re: From Node.js to Go

#71

Post by threeseed »

wiremine wrote: post #33

I'e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations: - The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python/Ruby background, that was nice to see. - I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see…

Most languages have an equivalent of go fmt.

They are just third party tools that aren't integrated into the language. Which for me is perfectly acceptable. There are sometimes legitimate reasons for formatting code different to what the language creators believe.

Re: From Node.js to Go

#72

Post by htilford »

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.

Re: From Node.js to Go

#73

Post by nawitus »

billsimpson wrote: post #66
nawitus wrote: post #51

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

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

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

Re: From Node.js to Go

#74

Post by u84six »

izolate wrote: post #53

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

From what I've heard, TJ is working with Go because Joyent wasn't putting enough effort into releasing features for node and he also got tired of JavaScript callbacks. I think node will see some love very soon, and I know there are plenty of ways to deal with callback hell. That's just one guy's feeling. I really love working with node. But definitely looking forward some new features.

Re: From Node.js to Go

#75

Post by kxo »

mrcwinn wrote: post #57
enahs-sf wrote: post #10

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.

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

> systems

Here we go.

Re: From Node.js to Go

#76

Post by pekk »

mitchty wrote: post #69
khyryk wrote: post #49

Earlier quoted context omitted.

This happens because almost every time there's someone who more or less asks what in the world generics are for since they can do everything they want to with Go's type system. Sure, it's possible, but it's missing the point.

I always saw it as the classical: why do you want a screwdriver to put the screw in place? The hammer should be good enough! Well, sure, I guess you can pound a screw into things with a hammer but you're missing the point.

Or just build your furniture without using screws, like in Japanese carpentry. When people are already having a decent time building things using the tool, it looks pretty stupid to tell them they've done it all wrong for years in all the decent products they made.

Re: From Node.js to Go

#77

Post by kochthesecond »

falcolas wrote: post #54
sshillo wrote: post #48

This is just another generic Go vs Node post. Do we really need another post telling us about Go's concurrency/built-in features/compile benefits. This post sadly doesn't really go into much details that bowery.io is trying to solve, how Go fits that and why Node was so bad. A basic crud webapp would probably be better suited towards node and it's larger list of libraries supporting that kind of stuff. On the other h…

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.

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.

Re: From Node.js to Go

#78

Post by lugg »

steakejjs wrote: post #37
lugg wrote: post #36

Earlier quoted context omitted.

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…

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.

I don't think you can really beat node for static web-apps.

Its just too strong. The development loop is great when using a build chain like gulp, deployment is relatively easy, scaling up and out is easy (by nature of it being a static webapp), single toolchain, single language (well at its core anyway) etc etc.

Writing API's, specifically restful ones, can be done, and for small stuff its quite nice, but as soon as you start adding processes, services and anything more complex than crud functionality it falls over development wise.

Re: From Node.js to Go

#79

Post by yellowapple »

laumars wrote: post #65
balls187 wrote: post #35

Earlier quoted context omitted.

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

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)

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

Re: From Node.js to Go

#80

Post by gcv »

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

Earlier quoted context omitted.

Maybe you don't like programming? Or you did once, but you've grown bored with it now that it's not as challenging? In my opinion, a programming language is good if it enables the programmer to move from a concept to correct and maintainable implementation with minimal friction. I don't expect a programming language to entertain me. The burden is then on me to find projects that I believe in and will enjoy implementi…

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

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.

Post reply on HN