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

Why I went from Python to Go (and not node.js)

orel.li

Post reply on HN
Print view View original

61–70 of 202 posts

Re: Why I went from Python to Go (and not node.js)

#61

Post by stcredzero »

taliesinb wrote: post #53
stcredzero wrote: post #29

If someone created a debugging environment for Go based on a VM, which also let one recompile source from within the debugger then continue execution, then it would be, for all intents and purposes, as productive and immediate as the old Smalltalk environments. You'd have the same small-grained cycles of inspecting state, modifying code, rewinding the stack to the place of your choosing, then getting immediate feedba…

Interactive coding is a very powerful way of working, it's one of the reasons I'm so productive in Mathematica. At a Go talk he did, I raised the idea with Russ Cox of having a "repl" package that would allow one to instrument a running program with a live REPL to do debugging and development on it. The reflect package is powerful enough to make some of that relatively straightforward, but one major problem is that G…

> one major problem is that Go can't construct new types at runtime.

The current implementations can't. I don't see any reason why one couldn't. In any case, I don't think that's such a big deal. One just goes from completely seamless interactive coding to mostly seamless interactive coding.

> Unless one builds a full Go interpreter

That is precisely what I was proposing. (Are you implying some sort of hard VM/interpreter dichotomy? I've met some people who implement VMs who think this is somewhat arbitrary.)

>but who wants to be in the business of maintaining a fully compliant Go interpreter that can interoperate with the Go runtime?

There would be no need to interoperate at all with the current Go runtime. One would have to have their own Go runtime, however. As an alternative, one could just target an emulator with no optimizations, then use debugging information and dirty tricks to map the new code with the old state in an entirely new process.

Re: Why I went from Python to Go (and not node.js)

#62

Post by erichocean »

zemo wrote: post #36
srj55 wrote: post #15

"As a Django developer, there wasn’t a straightforward and obvious way to just do things in the background on a page request. People suggested I try Celery, but I didn’t like that option at all. A distributed task queue? What? I just want to do something in the background without making the user wait; I don’t need some super comprehensive ultimate computing machine. The whole notion that I would need to set up and co…

well, the complaint isn't entirely that it's hard, per se, but that there are many different ways to do things concurrently in Python, and that it presents too many choices to be made for the novice programmer. In Go, you just say `go myfunction()` and you're done. There's a lot of value in that.

Until, that is, you tackle a problem for which one machine isn't big enough, at which time you need to do all of the "real" solutions anyway, and `go myfunction()` buys you...nothing.

There's way too much focus today on new languages that are designed to work on just one machine, and scale there – as if vertical scaling was the true problem we all face, when in fact, it's not. /sigh

Re: Why I went from Python to Go (and not node.js)

#63

Post by xyproto »

outworlder wrote: post #11
zemo wrote: post #9

Earlier quoted context omitted.

>Lots of fluff, not much substance. that was deliberate. There has been a glut of "introduction to Go" blog posts, and the documentation for introductory Go from the Go Team is quite good, so I didn't feel the need to author another introductory post. Most of the stories about why people use Go are bigger, established companies, so I wanted to show how it was perceived by a different audience. I don't remember where…

> but this is part of the problem: it's a library. Concurrency deserves language-level support. Adding concurrency at the library level is like adding an object system at the library level. Which is not a problem at all. Lisp and Scheme have been doing that since forever.

Not exactly prime choices for OO programmers, though

Re: Why I went from Python to Go (and not node.js)

#64

Post by MatthewPhillips »

ricardobeat wrote: post #22

Ah, code comparisons. I don't see much difference in the Go code vs Javascript, except for the extra comments and logging in the js. How about this? var cluster = require('cluster') , http = require('http') , os = require('os') if (cluster.isMaster) { os.cpus().forEach(cluster.fork) } else { http.createServer(function(req, res){ res.writeHead(200) res.end('Hello world') }).listen(8000) }

  os.cpus().forEach(cluster.fork)
Should be:

  os.cpus().forEach(cluster.fork.bind(cluster));

Re: Why I went from Python to Go (and not node.js)

#65

Post by zemo »

antihero wrote: post #57

I'd like to start porting a few of my little scripts to Go (that do pretty poor messy parallelism in Python), and I was wondering what a good resource/book type thing would be for people learning Go. Like, the equivalent of learn you some haskell or whatnot. Also some advice on "wtf library do I use for this". Is there some sort of Go package manager? How does all this shit work?

I recommend starting with http://tour.golang.org/#1.

Yes, the Go tool comes with package-management capabilities. "go get labix.org/v2/mgo" will download the very excellent MongoDB driver mgo, for example.

Re: Why I went from Python to Go (and not node.js)

#66

Post by swasheck »

SeanDav wrote: post #38
dons wrote: post #27

Earlier quoted context omitted.

You're digging in. > Haskell I would argue against being an industry language FYI, the problems the Haskell community has been working on are things like scalability, performance and safety because they're critical to industrial problems . Toy approaches don't work at the scale we operate at -- you need real computer science. You want 1,000,000 Haskell threads in your app? You've got it. Want to write numerical model…

The perception out there is that Haskell is an academic language, also that it is a "difficult" language. This is not fair on Haskell but that is what people think and that really is the issue that Haskell has to overcome.

Honestly, I find Go more difficult than Haskell

Re: Why I went from Python to Go (and not node.js)

#67

Post by ricardobeat »

MatthewPhillips wrote: post #64
ricardobeat wrote: post #22

Ah, code comparisons. I don't see much difference in the Go code vs Javascript, except for the extra comments and logging in the js. How about this? var cluster = require('cluster') , http = require('http') , os = require('os') if (cluster.isMaster) { os.cpus().forEach(cluster.fork) } else { http.createServer(function(req, res){ res.writeHead(200) res.end('Hello world') }).listen(8000) }

os.cpus().forEach(cluster.fork) Should be: os.cpus().forEach(cluster.fork.bind(cluster));

That's not needed. The API is designed so that you can do

    var fork = require('cluster').fork
Cluster methods keep a reference to the main object inside the module, see https://github.com/joyent/node/blob/master/lib/cluster.js#L4...

Re: Why I went from Python to Go (and not node.js)

#68

Post by zemo »

it wrote: post #42

It would help a bit if the article included at least roughly equivalent Go code next to the Python code. The Go code is wordier, but maybe it takes less time to write because it doesn't require as many decisions (libraries etc.) as with Python. package main; import ( "fmt" "net" ) func main() { hosts := []string { "www.google.com", "www.example.com", "www.python.org" } c := make(chan string) for _, h := range(hosts)…

This is a very good example of the type of thing I'm talking about. Nobody prompted you to do so, but you gracefully handled the case of a DNS failure in your code, because the control path was obvious throughout. Go makes this type of error handling a topic very early on in the literature. I find this type of clarity when structuring concurrent code to be very helpful in minimizing subtle concurrency bugs.

Re: Why I went from Python to Go (and not node.js)

#69

Post by reinhardt »

outworlder wrote: post #11
zemo wrote: post #9

Earlier quoted context omitted.

>Lots of fluff, not much substance. that was deliberate. There has been a glut of "introduction to Go" blog posts, and the documentation for introductory Go from the Go Team is quite good, so I didn't feel the need to author another introductory post. Most of the stories about why people use Go are bigger, established companies, so I wanted to show how it was perceived by a different audience. I don't remember where…

> but this is part of the problem: it's a library. Concurrency deserves language-level support. Adding concurrency at the library level is like adding an object system at the library level. Which is not a problem at all. Lisp and Scheme have been doing that since forever.

Their (lack of) popularity suggests that the "at all" part might be a bit too absolute.

Re: Why I went from Python to Go (and not node.js)

#70

Post by enneff »

ricardobeat wrote: post #22

Ah, code comparisons. I don't see much difference in the Go code vs Javascript, except for the extra comments and logging in the js. How about this? var cluster = require('cluster') , http = require('http') , os = require('os') if (cluster.isMaster) { os.cpus().forEach(cluster.fork) } else { http.createServer(function(req, res){ res.writeHead(200) res.end('Hello world') }).listen(8000) }

You should update the node.js docs if you consider the original JS snippet ugly, because that's where I pulled the original code sample from verbatim.

In any case, it's still not an apples to apples comparison. The node.js example forks separate processes that share nothing, while in the Go example it all runs in one process so the HTTP handlers can communicate with each other via channels or other shared data structures.

Post reply on HN