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

Go as an alternative to Node.js for very fast servers

bbs.studygolang.com

Post reply on HN
Print view View original

141–150 of 168 posts

Re: Go as an alternative to Node.js for very fast servers

#141

Post by snupples »

ef4 wrote: post #121
gtaylor wrote: post #68

Earlier quoted context omitted.

At the same token, having frontend JS devs that don't have much experience in writing backends can leave you with a mess to clean up or completely re-write in the future. I think this "benefit" of using the same language for front and backend is pretty over-hyped, as well. In theory, I can agree that it sounds good. In practice, use the best tool for the job on both ends to fit your team's abilities and strengths. Th…

I have a rich, client-side, fully-offline-capable javascript application. I started out with a different language for the backend, but over time the benefit of switching to Node and sharing one codebase became overwhelming. Just to give one example: any data query can get answered locally or from the server, depending on what's already cached and whether you're online. Before, I had to implement every call twice and…

I love having the server and client share the same codebase.

I'm working on a webapp that mimics functionality of an existing desktop application -- mostly as a self-educational project. As I'm writing it and adding features, I can push processing from server-side to client-side and vice versa with hardly more than a copy and paste of the relevant chunk of code.

Say I don't really care about the security of some particular process, and I really don't want to use up any additional resources on the server for it, I can just push that load to the client browser in a couple clicks.

Did I just write some feature into the client that I suddenly realize presents a security problem? With node, there's no need to change my frame of mind or rethink how to do something in a different language -- just copy and paste from client.js to server.js and do some slight cleanup.

Re: Go as an alternative to Node.js for very fast servers

#142

Post by chc »

pallinder wrote: post #125
cgag wrote: post #113

Earlier quoted context omitted.

What's easier about deploying Go vs with the JVM? Deploying stuff I've written in Clojure has been pretty easy.

go build It compiles a binary, just send it to the server and it will run, no need to even have go installed on the server (or any libs really).

Doesn't this require your development machine to use the same architecture and OS as your server?

Re: Go as an alternative to Node.js for very fast servers

#143

Post by samstave »

invisible wrote: post #80

I've worked with both node and Go. There is a lot of hyperbole and fluff points about Go's strengths in the original article (sorry to the author!). Things that are touted as huge wins for Go have equally better things in node. Both platforms are great and they both have appeal for different people. My eloquent post was eaten by an expired link on the original article but here are some counter-points: The commutative…

If I am starting from zero, which is easier to lear/better to learn; Go or Node?

Re: Go as an alternative to Node.js for very fast servers

#144

Post by rartichoke »

drsintoma wrote: post #129
rartichoke wrote: post #123

Earlier quoted context omitted.

To be fair I didn't use revel. Instead I just used pat (the route mapper) and started to try and recreate most of what express does using go's stdlib because nothing else really existed yet. The gorilla toolkit's APIs are inadequate and it seemed like quite a few people agreed too because most of them said they rolled their own solutions to do things that certain gorilla libs did but with a more intuitive and friendl…

> Go really isn't that young either. It's been what at least 4 years now? There's no excuse. It's not like the language is 6 months old. 1.5 if you count from the first stable release. Which IMHO is what matters, before was just a experiment with a lot of uncertainties. It took ruby 9 years to arrive from 1.0 to Rails. They were other times, sure, but still. I still consider it very young, or at least I don't know of…

I'll believe it when I see it. Almost nothing has changed since I went through my Go adventure which was like 9 months ago I think.

9 months to me is a huge amount of time. I don't want to have to wait years to be super productive. I want to be super productive right now and by using other platforms I can be.

For a new viable web platform to be accepted it needs to really explode in popularity. It has to offer MASSIVE gains.

Look at node, it offers performance and also offers the benefit of using the same language on both ends. That's pretty neat... maybe, but I think you would at least agree with me that node's popularity and growth has been unmatched. Even so, it's still quite far behind rails and I don't think it will catch up.

I'm not some massive rails fan boy either. I only started using it when 4.0 came out because the ease of caching seemed interesting to me and I was looking for an excuse to go from node/express to something more opinionated just to see if it was more productive.

Re: Go as an alternative to Node.js for very fast servers

#145

Post by wtf_is_up »

chc wrote: post #142
pallinder wrote: post #125

Earlier quoted context omitted.

go build It compiles a binary, just send it to the server and it will run, no need to even have go installed on the server (or any libs really).

Doesn't this require your development machine to use the same architecture and OS as your server?

No. It's simple to build Go toolchains for whatever your deploy os/arch target is. Then you just cross-compile.

* Download Go source

* Extract, cd go/src/

* GOOS=linux GOARCH=386 ./make.bash #this will build the linux_386 toolchain

* GOOS=linux GOARCH=amd64 ./make.bash #linux_amd64

* GOOS=linux GOARCH=arm ./make.bash #you get the picture

GOOS can be windows, darwin, freebsd, netbsd, plan9.

Then when you want to cross-compile your app, you do:

GOOS=linux GOARCH=arm go build myApp.go

That's it. Now you have a statically linked binary that you can drop on whatever your target is. As someone who has had to cross-compile a lot of C and C++ code, I find this simplicity to be a huge win.

Re: Go as an alternative to Node.js for very fast servers

#146

Post by WalterSear »

samstave wrote: post #143
invisible wrote: post #80

I've worked with both node and Go. There is a lot of hyperbole and fluff points about Go's strengths in the original article (sorry to the author!). Things that are touted as huge wins for Go have equally better things in node. Both platforms are great and they both have appeal for different people. My eloquent post was eaten by an expired link on the original article but here are some counter-points: The commutative…

If I am starting from zero, which is easier to lear/better to learn; Go or Node?

Node and javascript. Vastly more learning resources and applicability at this time.

Re: Go as an alternative to Node.js for very fast servers

#147

Post by thrownaway2424 »

corresation wrote: post #109
thrownaway2424 wrote: post #73

Earlier quoted context omitted.

What do you think the difference is between a "real core" and a "hyperthread core"?

I'd be humored to hear your idea of what the difference is, given the misplaced use of scare-quotes. A hyperthread core is a virtual core -- it is not actually a core at all but is a re-purposed, possibly stalled physical core. While it can improve some scenarios, in some cases (particularly core-saturating benchmarks) it can actually hurt performance. This is hardly an out there or controversial statement. Further I…

It is an "out there" statement because it's entirely, radically incorrect. A processor thread represents a full-blown decode and issue pipeline. A core represents a set of execution resources. Each pipeline can dispatch to any execution unit equally. In case of contention for the same execution unit, one thread issues immediately and the other thread issues next.

If you don't disable hyperthreading, but instead run four threads on an 8-thread CPU, it is extremely likely that the threads will be scheduled on the first two cores/four threads and the other two cores will be shut down, especially on the newer intel CPUs with "turbo" features where this strategy can have large benefits.

Re: Go as an alternative to Node.js for very fast servers

#148

Post by invisible »

pbsd wrote: post #137
invisible wrote: post #80

I've worked with both node and Go. There is a lot of hyperbole and fluff points about Go's strengths in the original article (sorry to the author!). Things that are touted as huge wins for Go have equally better things in node. Both platforms are great and they both have appeal for different people. My eloquent post was eaten by an expired link on the original article but here are some counter-points: The commutative…

> 32-bit integers in JS don't have float problems because the precision doesn't break Unless you try multiplying them.

As long as the result is less than 9007199254740992 (9 quadrillion; 2^53). Who uses numbers that large? Regardless of the practicality, you can use a library if you need support for bigger numbers (e.g. crypto's BigInt.js).

Re: Go as an alternative to Node.js for very fast servers

#149

Post by corresation »

thrownaway2424 wrote: post #147
corresation wrote: post #109

Earlier quoted context omitted.

I'd be humored to hear your idea of what the difference is, given the misplaced use of scare-quotes. A hyperthread core is a virtual core -- it is not actually a core at all but is a re-purposed, possibly stalled physical core. While it can improve some scenarios, in some cases (particularly core-saturating benchmarks) it can actually hurt performance. This is hardly an out there or controversial statement. Further I…

It is an "out there" statement because it's entirely, radically incorrect. A processor thread represents a full-blown decode and issue pipeline. A core represents a set of execution resources. Each pipeline can dispatch to any execution unit equally. In case of contention for the same execution unit, one thread issues immediately and the other thread issues next. If you don't disable hyperthreading, but instead run f…

The operating system schedules threads across cores, and the processor has zero say in the matter (further, the execution units are primarily to facilitate branch to essentially execute future scenarios). Both Linux and Windows are hyperthread aware, and will schedule threads to physical processors first, then to hyperthread virtual processors (given that it shares resources with the physical core and can sabotage performance).

This is common knowledge, and your laughable obnoxiousness, which anyone who has ever worked with multithreaded code on a HT processor knows is farce, rings pretty ridiculous.

Re: Go as an alternative to Node.js for very fast servers

#150

Post by thrownaway2424 »

corresation wrote: post #149
thrownaway2424 wrote: post #147

Earlier quoted context omitted.

It is an "out there" statement because it's entirely, radically incorrect. A processor thread represents a full-blown decode and issue pipeline. A core represents a set of execution resources. Each pipeline can dispatch to any execution unit equally. In case of contention for the same execution unit, one thread issues immediately and the other thread issues next. If you don't disable hyperthreading, but instead run f…

The operating system schedules threads across cores, and the processor has zero say in the matter (further, the execution units are primarily to facilitate branch to essentially execute future scenarios). Both Linux and Windows are hyperthread aware, and will schedule threads to physical processors first, then to hyperthread virtual processors (given that it shares resources with the physical core and can sabotage pe…

No, the power-aware scheduler in Linux does not work as you describe. On a turbo-capable Intel CPU, if there are N program threads that will fit on M cores where M is less than the total cores on a socket, and the CPU will enter P0 state, then the threads will run on as few cores as possible and the remaining cores will be shut down.
Post reply on HN