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

151–160 of 192 posts

Re: From Node.js to Go

#151

Post by skj »

Gurkenmaster wrote: post #143
laumars wrote: post #68

Earlier quoted context omitted.

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

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

Speaking as someone from a team that bundles a large portion of a (python) runtime with a distributable, this is a BIG BIG BIG pain in the ass.

Re: From Node.js to Go

#152

Post by collyw »

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.

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.

Re: From Node.js to Go

#153

Post by tmaly »

wiremine wrote: post #33

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

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

Re: From Node.js to Go

#154

Post by burntsushi »

TheCoelacanth wrote: post #41
wiremine wrote: post #33

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

> I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I'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.

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

Re: From Node.js to Go

#155

Post by burntsushi »

Touche wrote: post #103
chimeracoder wrote: post #44

Earlier quoted context omitted.

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

> Go takes a different approach to the same problem (in this analogy, getting from point A to point B). Go doesn't take any approach to writing generic code at all.

That's false. Go has structural subtyping. It enables you to sort collections of things without actually writing a sorting algorithm. Seems like generic code to me.

Re: From Node.js to Go

#156

Post by ufo »

4ydx wrote: post #108
ufo wrote: post #88

Earlier quoted context omitted.

Parametric polymorphism gives safety guarantees that you can't easily obtain without language support. For example if you have a function typed "forall a . a -> a" you know it has to be the identity function (or something that bypasses the typesystem, like infinite loops or a runtime exception).

And in Go since there is no parametric polymorphism you would end up writing either: 1) Methods with names that indicate the parameter types. 2) Method calls on objects to convert some internal struct data from one type to another. 3) Something I haven't thought of that doesn't involve losing a handle on your type. So there is certainly a loss in convenience, but if you use the type system it can be just as safe as a…

No you can't. The point of generics is that you don't need to specify the parameter types - the parameter type is also a parameter. This means that you can write type safe container operations like "map" and "filter".

The only way to write this kind of generic code in Go is to cast everything to `interface{}`, which can't be checked statically.

If you are still not convinced, one of the things you can do with generics is say "these two parameters have the same type". In Go the best you can do is say "these two parameters are subclasses of something", which is less precise.

Re: From Node.js to Go

#157

Post by sagichmal »

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

Earlier quoted context omitted.

I used to agree with you more strongly but I think it's easy to forget just how much time and confusion is saved by having a single standard format which anyone can trivially check and apply. It's not just about avoiding unnecessary bike-shed arguments but also things like the cognitive cost of having to dealing with each project / developer's style quirks. I'm now inclined to believe that a basically free way to avo…

Honestly, it's not the 2-4-8 indentation or the placement of braces that gets me when reading code. In Go, my biggest problem is that there are so many x, err := foo(); if err { ... } that I get lost trying to figure what the happy path behavior is.

    > I get lost trying to figure what 
    > the happy path behavior is.
The happy path is idiomatically at indent level 0.

Re: From Node.js to Go

#158

Post by chaotic-good »

Touche wrote: post #103
chimeracoder wrote: post #44

Earlier quoted context omitted.

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

> Go takes a different approach to the same problem (in this analogy, getting from point A to point B). Go doesn't take any approach to writing generic code at all.

It has interfaces to write generic code. It doesn't allow you to write your own generic data structures but it's not an issue because it has built-in dynamic arrays and dictionaries. You supposed to use built in data structures most of the time like with python or ruby.

Re: From Node.js to Go

#159

Post by rmetzler »

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.

Re: From Node.js to Go

#160

Post by jonpress »

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.

Post reply on HN