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

121–130 of 192 posts

Re: From Node.js to Go

#121

Post by MichaelGG »

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 the really disappointing part. I've read the thread where the designers talk about implementing generics, and they basically say that every language's implementation of generics sucks, and since they can't come up with a design that's perfect (no codegen duplication, but still all the perf of specialization), they're just gonna punt.

And then the code I've seen is littered with "interface {}".

That's a pretty big thing to give up, and I don't get the point. Something like F# gives you high level features (and green threads if you want) with fair perf, and Rust gives you a fair amount of language with C perf.

Re: From Node.js to Go

#122

Post by Sphax »

MichaelGG wrote: post #121
Touche wrote: post #103

Earlier quoted context omitted.

> 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 the really disappointing part. I've read the thread where the designers talk about implementing generics, and they basically say that every language's implementation of generics sucks, and since they can't come up with a design that's perfect (no codegen duplication, but still all the perf of specialization), they're just gonna punt. And then the code I've seen is littered with "interface {}". That's a pretty…

I think littered might be a bit strong. I'm writing a service in Go, and have yet to use interface{}. However, you might have to use it more when writing libraries.

Re: From Node.js to Go

#123

Post by Sphax »

chimeracoder wrote: post #43
wiremine wrote: post #33

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

> - Go is a minimal language and has been called boring. [2] I don't claim to be an expert yet, but I don't think I've reached this level of productivity with a language this quickly before. I was drawn to Go initially because of its promises around concurrency, but this is why I stayed. Within less than a month, I was as productive in Go as I was in Python, despite the fact that I had been programming in Python for…

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.

Re: From Node.js to Go

#124

Post by pjmlp »

kybernetikos wrote: post #47
pjmlp wrote: post #38

Earlier quoted context omitted.

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

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…

I see. However that is a common problem in any platform that doesn't follow the UNIX way.

I imagine node.js for IBM i or z/OS to have similar issues.

Re: From Node.js to Go

#125

Post by eklavya »

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…

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.

Re: From Node.js to Go

#126

Post by objectified »

neurosnap wrote: post #107
chimeracoder wrote: post #43

Earlier quoted context omitted.

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

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.

I do believe the need for virtualenv stays, in development as well as in production. Even when using a Docker container, you will still want to pin your dependencies strictly to specific versions and not risk any interference of Python modules that happen to be on the OS. I think it's important to not make assumptions in that area (dependency management) when wanting to create stable software.

Re: From Node.js to Go

#127

Post by grey-area »

gankgu wrote: post #105

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

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.

Re: From Node.js to Go

#128

Post by rogpeppe1 »

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.

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.

Re: From Node.js to Go

#129

Post by insertnickname »

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…

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

Re: From Node.js to Go

#130

Post by drapper »

Kiro wrote: post #120
TheCoelacanth wrote: post #41

Earlier quoted context omitted.

> I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I've found it to be practical and easy to use. Go doesn't have generics. To someone coming from a language like Rust, saying that your type system doesn't have generics is like saying your car doesn't have wheels. It's just considered non-negotiable.

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.

Say you have a function that can operate on various types, for example you'd have a function in JS like:

  function addKey(input, key, value) { input[key] = value; return input; }
this will work on either Objects or on an Array. But if you have static typing and no generics to make it work you have to either:

- create two versions of the same function, one for Objects, 2nd for Arrays

- use any as a type of input - this will work, but you will loose most of the benefits of type checking, e.g. you will be also able to pass Number as an input and compiler won't complain, it will be detected as error only on runtime and other things (your function will also return any so further on in the program you won't know what type is used).

With generic it's easy, you write the function once and when you call it you tell what types are used:

  // definition:
  function addKey(input:X, key:Y, value:Z):X { ... }
  // call:
  var a = addKey,Number,string>([],0,"fubar");
With this particular example there are probably other ways as well (sum types, common interface) and also compiler may actually detect passing Number as an error (depends how smart it is), but there are more complex cases, where lack of generics will lead to a lot of copy/pasting and boilerplate.
Post reply on HN