Dimissing Erlang and Haskell with a wave of the hand, while seriously considering node.js? Carry on, nothing to see here.
Why I went from Python to Go (and not node.js)
21–30 of 202 posts
Re: Why I went from Python to Go (and not node.js)
#22Ah, 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)
}Re: Why I went from Python to Go (and not node.js)
#23I'm in love with Go. I'm very close to deploying it in production.
Re: Why I went from Python to Go (and not node.js)
#24Dimissing Erlang and Haskell with a wave of the hand, while seriously considering node.js? Carry on, nothing to see here.
ah, so, I don't think I wrote that section particularly well. I hold Erlang and Haskell in very high regard; I was really trying to mock my own superiority complex, which I think is fairly common in the Python community. I guess what I was really trying to get at is that Go is verymuch an industry language. Haskell I would argue against being an industry language not because it can't be used in industry; that's not at all what I mean. I don't mean to compare them on their technical merits; what I mean to say is that Go has a broad appeal, in that it is welcoming to beginners, it has large corporate support, and that it is also technically capable. Of the programmers that I know, the Haskell programmers are typically capable of solving the hardest problems, but they also tend to be the most academic. The Erlang programmers typically build the most stable software, but I think Erlang is intimidating to less-experienced programmers (the same is true of Haskell, actually).
That could have been written better. Thanks for the feedback.
Re: Why I went from Python to Go (and not node.js)
#25Lots of sentiment, not much substance. Concurrency support is possible in Python, without gevent-style monkey patching (or callback madness). Have a look at concurrent.futures and http://www.dabeaz.com/coroutines/index.html . It really needs a lot more work before it's part of the language's DNA, though. Also, pypy needs much wider adoption as quickly as possible, to address the speed problems (and its STM branch hol…
"For me, Go's major shortcoming is its community's lack of focus on readability as compared to Python." Can you be a bit more concrete here? Because whether you like the code styles enforced by gofmt and the compiler itself or not, Go is the most consistently readable language I've ever used (once you adapt yourself to the language). IMO, this seems like an especially odd problem for someone to have with Go.
I can't speak for @ak217, but for me Go hits a bad spot on "expressibility". Some of the nuances of static typing are mitigated a bit with features, yes, like the type inference on local variables, or the automatic interface detection (i.e. no explicit "type X implements Y"). But overall, i think the chosen type system is lacking on expressibility. Having no parametric polymorphism in a static language is a deal breaker for me at least. No way of doing type-safe parametric container types for example.
Re: Why I went from Python to Go (and not node.js)
#26In Go, the coroutines are in the same thread. There is a single thread here too(just like node.js). Coroutines are just multiplexed to the one main thread. Multi-Core Processing is handled by coroutine internals too i.e. there may or may not be more than one threads and even if there are more than one threads, they too will be multiplexed with the one main thread.
>In Go, the coroutines are in the same thread.
.. until you set runtime.GOMAXPROCS(runtime.NumCPU())
Re: Why I went from Python to Go (and not node.js)
#27Dimissing Erlang and Haskell with a wave of the hand, while seriously considering node.js? Carry on, nothing to see here.
ah, so, I don't think I wrote that section particularly well. I hold Erlang and Haskell in very high regard; I was really trying to mock my own superiority complex, which I think is fairly common in the Python community. I guess what I was really trying to get at is that Go is verymuch an industry language. Haskell I would argue against being an industry language not because it can't be used in industry; that's not a…
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 models that compete with C++ code, in a fraction of the development time? Done. Want to guarantee the app won't crash? Solved. Run models over 10,000 cores? It happens.
Because we put the work in.
---
/me wanders back to a multi-million line Haskell codebase running systems in 25 countries, processing billions a year in financial transactions.
Re: Why I went from Python to Go (and not node.js)
#28"... as a Python programmer, I was the member of an elite cabal of superhuman ultranerds, smarter than those childish Rails/JavaScript/PHP/whatever developers that couldn’t write a bubble sort or comprehend even basic algorithmic complexity, but more in touch with reality than the grey-bearded wizards of Lisp/Haskell/whatever that sat in their caves/towers/whatever solving contrived, nonexistent problems for people that don’t exist, or those insane Erlang programmers who are content writing sumerian cuneiform all day long."
This made me laugh, thank you.
Re: Why I went from Python to Go (and not node.js)
#29If 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 feedback.
Source code changes could be saved as log-structured patch files, which could then be thrown away or applied to the source tree as desired. One could also steal some ideas from the Smalltalk Change Log tool by adding similar editing, search, and filtering commands.
With tools like this, one could recompile for "interpreted debug mode," have complete visibility and control of runtime state to debug a problem, then take the resulting patch file and apply it to the source tree. It would be a best of both worlds scenario -- all the enhanced debugging of an interpreted runtime with the type safety and speed of compiled code.
Re: Why I went from Python to Go (and not node.js)
#30It it true there's no way to spawn a background task in Django without making the user wait?
I haven't been using Django for a while, but I know there was no way built into the framework to do it. The complaint isn't really that it's too hard, it's that there's too many decisions to make, because it's not supported at the language level.