Why I went from Python to Go (and not node.js)
orel.li
orel.li
This made me laugh, thank you.
Care to elaborate?
In short, it's a language best define by what it isn't: it isn't bad, but it also isn't good.
It isn't particularly elegant, but it isn't particularly ugly either. It isn't exceptionally expressive, but it's also no tarpit. It isn't very concise, but it isn't quite overly verbose.
It is the very essence of plainness. If languages had a color, Python's would be a dull gray.
An interesting thing to note is which communities do not like Python. For what it's worth, the least Python-endorsing site I've found is Lambda the Ultimate. That should definitely tell you something, although I suspect what it tells you depends entirely on your own preferences :P.
Python really is nothing but mediocre and uninspiring. Sure, it isn't bad, but I would like a language that is actively good.
The very interesting thing about all this is that, quite often, you need a mediocre language. So Python is actually a great fit for a bunch of startups--it's the modern lowest common denominator. But I--being deeply interested in programming languages--wouldn't want to work anywhere that settled on a language that way.
Overall, from your post, I don't believe you have used Python seriously.
I don't care what color Python would be, nor would I care what ice cream flavor it would be. Nor do I care whether it is cool on Lambda the Ultimate. Is this grade school?
If you are looking for a lowest common denominator, I think the language best fitting that description is C. I do not say this to damn C, which I rather like in its way. The core language is relatively simple and portable and is the closest thing that practical programming has to a lingua franca (not talking about academic stuff like ML).
If you can't understand why anyone would like C then it isn't at all surprising that you wouldn't understand why someone would like Python.
Use whatever you want for yourself, but let's be clear that this is a matter of you being too cool for Python, not of you having any real reason why it is a bad tool.
You only say there are no horrible gotchas with tuples because you've never spent hours hunting down a bug and finding that you forgot a trailing comma. More pertinently, changing something like
("foo",
"bar",
"baz")
("foo")
The performance problem isn't a problem per se--the performance just isn't good. But this does not mean it's bad! That was really the whole point of my post; the performance, like everything else about the language, is unimpressive. In my experience, even naively written Haskell tends to perform better while being shorter and easier to write.
My point with Lambda the Ultimate was more general--I've noticed that the more programming language oriented a community is, the less people like Python. The people who spend the most time thinking about and working on different programming languages--the denizens of Lambda the Ultimate--are the ones who like it least. It's very much like music that musicians don't like.
What I meant by lowest common denominator is that you could get virtually anybody, regardless of skill level, to use Python. C is far more tricky--and has far more odd edge cases and ways to shoot yourself in the foot--than Python. It trades this for lower-level hardware access and performance, but this makes it far less of a LCD language than Python.
This is not a matter of "cool"--and it's not even a matter of Python being a bad tool. It's a matter of Python not being an outstanding, or, honestly, even a good tool. And, as I said, this is perfectly fine; there are plenty of reasons to choose a solid tool you know well over something that may even be strictly superior. I can even understand why people would like this; many people like something approachable and bland over something seemingly exotic but also exciting.
But this does not fit with Python's general hype. People trot Python out as the gold standard of language design and are rather proud of themselves (as the post starting this whole discussion parodied) without having the substance to back that attitude up.
And all this goes back to the original thesis: Python is not actively bad, but it is also not actively good--it occupies a rather uninteresting middle ground. This is only surprising in light of its somewhat incongruous reputation as one of the best languages in certain circles.
You should get an achievement of some sort. Hackernews needs achievements.
And why the bitterness?
Anybody that's done Python for more than a day will instantly know that you'd do ("foo",), and to be honest you'd more likely write it as
(
"foo",
"bar",
"baz",
)
People trot Python out as the gold standard of language design
Who?
The point is that it's a subtle syntactical difference but a dramatic semantic difference. I think most newcomers to Python hit this.
> 4 * (3+2)
should throw:
> TypeError: unsupported operand type(s) for *: 'int' and 'tuple'
???
I beg to differ.
>>> isinstance(tuple, ("foo", "bar"))
True
>>> isinstance(tuple, ("foo"))
False
which is correct. In Python, a single-element tuple must end with a comma--otherwise it is just that element, e.g.:
"foo" == ("foo")
FWIW, OP is right--finding a bug related to this issue is almost a rite of passage for new Python devs.
IMO this is just an educational issue where people aren't taught that the comma is the tuple operator (e.g. `x = 3,4` is perfectly legal) and parentheses just come along for the ride to disambiguate other uses of commas. If I were king tuples wouldn't have the same syntax as argument lists (`f((3,2))` is pretty ugly), but both Python tuples and Python argument lists conform to a lot of people's expectations of how both those things should look.
The fact that duck typing makes tuples and literals (temporarily) indistinguishable to the interpreter is more of a rough edge of duck typing itself. Duck typing can result in tricky bugs in many scenarios well beyond singleton tuples.
You seem to be saying that 4 (3+2) should throw: TypeError: unsupported operand type(s) for : 'int' and 'tuple'???
Parent wasn't saying that at all, and I was clarifying.
> changing something like > ("foo", > "bar", > "baz") > to > ("foo") > actually breaks the code.
Of course it breaks the code because the first thing is a tuple and the second is a string. He's implying that the second thing shouldn't be a string. I'm saying that's nuts.
He's not actually proposing that a string be a tuple. He's just saying that a single element enclosed in parentheses doesn't work the way you'd expect it.
No offense, but your youth is showing--it appears you haven't used it long enough to fully understand it (gotchas), have unrealistic expectations of purity, and aren't very aware of the preceding. Yet you still have strong opinions... like most of us experience will beat you down, give it time.
I wrote a few of these stinkers a decade ago and would laugh at them now.
Exactly, as you point out in the end. It's a language for people who are deeply interested in getting shit done. Rather than people "being deeply interested in programming languages".
You are acting out the 2nd (tower type) stereotype so well I can almost believe you are a parody.
I think everything you've mentioned is pretty defensible, particularly the readability bit. Honestly if a language does everything reasonably well, I think that's pretty awesome. I'm also curious what magical dynamically-typed interpreted language you prefer. The only mainstream general-purpose alternatives I can think of are Ruby (which is basically alternate-universe python) and Perl (which seems strictly worse), or are you into JavaScript or APL-derivatives? It's all a matter of taste of course, but I could probably write a much more vicious rant against any of those.
I wouldn't say i espouse the view presented (have too much respect for what's been achieved in the other camps such as Ruby and even PHP), but internally yeah i think i do view the world that way.
I don't think it's any different from the common "anyone driving slower than you is a doddler, anyone faster is a maniac" - a patently absurd view to hold.
The enlightening part for me is that other pythonistas think this way, because as you said, i have also never experienced this view expressed publicly by the python community.
Then again, maybe I'm reading too much into it. For the record, I think Haskell is a strictly superior choice to Go, so I'm what he would probably call "gray-bearded" :P. (And I'm certainly working on a beard, even if it shouldn't be gray any time soon.)
no, you got it. It's not really meant to be a criticism of Python itself, it's just behavior that is common among 20-something web developers, which is representative of some areas of the industry, and is specifically the target audience for the post. You know, the kind of developer that is advanced enough that they can build non-trivial projects, but not experienced enough to have wisdom forged in the furnaces of years of industry experience (that's ... me and a lot of other HN users). The same type of attitude can be found in all languages and isn't specific to the Python community; the specific swipes at other languages are just what you get if you apply that attitude to Python. Judging people by the tools they use is a pretty useless metric.
>For the record, I think Haskell is a strictly superior choice to Go
I'm pretty sure it's the best programming language, that's why I put them in the gray-beard category. Or maybe it's OCaml or some Lisp dialect; it doesn't really matter. It's even why I further apologized to Dons and acknowledged that Haskell programmers tend to be able to solve harder problems than other programmers I know, but even after I twice acknowledged the superiority of Haskell, he basically just looked at me and said "you're a stupid idiot, and by the way, look at how many numbers I can compute with my superior Haskell program that runs on a lot of machines". Uh, ok, that's cool... I guess.
But every time I sit down with Haskell programmers and they explain to me how elegant their code is, I just don't really care. It's not what makes me interested in computer programming. I don't really care to use the best programming language; I really only care to make the best programs. PHP (and other shit technologies) have shown us that you don't need to understand monads to make people happy.
A friend of mine, who is a very strong programmer that I have a tremendous amount of respect for professionally, once showed me how to use Coq to prove that multiplication is commutative. I found that very boring, and it didn't make me want to learn Coq. Mind you, I spend between 40 and 60 hours a week working with software. I'm in it because I like to build things that are useful to people, and I think software is a great creative medium. I think that's a fairly common attitude.
Every time I say the name Haskell I am sorry for it, because every time I say the name Haskell I am met with bitter condescension. It makes me sad that despite talking about having experience with seven programming languages in my post, or mentioning having built a variety of things that are very different, Haskell programmers consistently treat me like I am a stupid person. So I'm glad you're not like that, and I'm glad that you understood I didn't mean to dismiss Haskell on technical grounds. Thank you for your comment.
Out of all the languages I've tried--and I've tried a decent amount--Haskell is by far the most productive. I can write my programs faster and they come out shorter, more readable, more maintainable and easier to test. I've found it far easier to go back to old Haskell code I've written than old Java or JavaScript or Perl or even Python code. All this without significantly sacrificing performance.
I've also found Haskell far easier to refactor. In most languages, my projects' code size goes up monotonically; in Haskell, it isn't rare for me to both add a feature and make the code shorter! This was a surprise the first couple of times, but now I almost expect it.
Also, critically, I've found Haskell's advantages scale superlinearly with the complexity of the problem. That is, the harder a problem is conceptually, the bigger the advantage of using Haskell over another language. Haskell actually helps me think about the problem, even if I don't want to write a program for it. I've certainly found certain tasks far easier even in other languages by thinking in Haskell terms about things like nondeterminism.
This may seem counter-intuitive, but I've even found Haskell to be very good for prototyping. Once you get used to the slightly different style of thinking it requires, the type system actually starts helping you develop solutions quickly. I'm sure other languages may be better at this than Haskell, but Haskell really shines when it's time to take your prototype and transition to a solid piece of software--it makes the refactoring much easier and makes even significant architectural changes more approachable.
The real problem is that Haskell, for whatever reason, has the rather unfair reputation of being impractical. Really nothing could be further from the truth--yes, there is plenty of theory and research in the language, but this is not there just for fun: it actually makes the language better to use, even for more mundane tasks!
You definitely don't need to understand monads to make people happy, but it certainly helps. In practice, as PHP has shown :P, you really don't need to understand much of anything to do awesome stuff. And yet we all still heavily recommend encapsulation and testing and code reuse and so on; the Haskell philosophy is just a systematic extension of this.
I think Haskell's widely spread reputation as just an academic curiosity makes some people a little defensive--and well it should! But never take it personally. It's just a little annoying for an immensely practical and productive language to be cast aside simply because it derives its efficiency from a well-founded theoretical basis.
I do run into a lot of egos but these don't seem much different from the types I see posting comments like this on Hacker News. And a lot of Python people have picked up Node or Go these days, so I wouldn't be too sure that you weren't damning a significant part of your own favorite community here.
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 holds huge potential).
For me, Go's major shortcoming is its community's lack of focus on readability as compared to Python.
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 I saw it, but someone talked about using Go in contrast with Java, and the overwhelming reaction was "that's cool but I'm a Python programmer, I'm curious what Python programmers think", so I was just trying to give it that angle.
>Have a look at concurrent.futures
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.
His arguments have much to do with what the compiler doesn't know, which could potentially be solved with macros.
I absolutely agree, which is why I said it needs more work.
I have seen more Python/Ruby programmers interested in Go than Java or C++ programmers. Rob Pike seems to have observed it as well.
I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
http://commandcenter.blogspot.in/2012/06/less-is-exponential...
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.
Idiomatic Python: http://python.net/~goodger/projects/pycon/2007/idiomatic/han... (doesn't cover a number of important things)
When comparing the two, I'm not impressed with Go.
I know that I frequently kick myself in Python when I typo a name somewhere, and everything dies far beyond where I made the mistake because it goes along happily storing something into that typoed variable, and then when I read it later it has the wrong value, and it takes me a while to trace back and find where I made the typo.
However, the built-in arrays, slices, and maps (which are parametrically polymorphic) seem to have covered all the cases where I need parametric types so far. Maybe I'm just lucky or haven't written enough lines of Go but it seems like an 80/20 sort of feature in the presence of the built-in maps.
Not being able to type-check something as simple as a container lookup is a show-stopper for me because using containers is a huge part of day-to-day programming. Static typing without parametric polymorphism is extremely retrograde -- like Java in the 90's.
I've read rsc's essays on adding parametric polymorphism to Go -- I'm not saying it's a "duh -- just add parametric polymorphism". I'm well aware of the issues -- I'm just saying that Go looks great except for this glaring exception.
I think we, as a profession, have a tendency to focus on what's "easy" (syntax and constructs we're already familiar with) to the exclusion of other, potentially more important factors. I am and have been guilty of this myself, so I'm not claiming any sort of sainthood, just making an observation.
Often people pick on the use of single-letter variable names as "unreadable." This is mostly a matter of keeping the code light on the page, as they put it. If you're dealing with a package centered around Foo, especially methods on same, it's customary to just abbreviate it to f. That clashes with a lot of people's instincts even though, once you get used to it, it works well.
"Once you get used to it" is key -- this is true of any language with substantially new or different syntax/semantics from what a programmer is used to. All else being equal, familiarity ought to be orthogonal to merit; the mere presence of a learning curve ought not be a deal-breaker.
Anyway, Go is one of the most readable languages I've ever seen, given that it is not a scripting language. Among other things, type inference and literals make the code very clean, to the point where you can in short order read the standard library code and expect to understand it.
For example there are issues with scope (what happens when I need a second or third "f" variable" and maintainability too (6 months from now I have to remember if "f" stands for "foo" or "file").
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.
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 Go can't construct new types at runtime. Another challenge would be dynamic linking of new code -- because the Go toolchain doesn't support dynamic linking there would seem to be no hope of say entering anonymous functions on the REPL.
Unless one builds a full Go interpreter -- but who wants to be in the business of maintaining a fully compliant Go interpreter that can interoperate with the Go runtime?
Still, calling existing functions and banging on variables would be pretty useful.
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.
That's pretty much what the modern JIT VM Smalltalk environments do. On recompiling a method, all the affected JIT compiled machine code is kicked out of the code cache, and you start from interpretation again, which eventually results in the "hot" code being JIT compiled again.
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) {
go get_ip(h, c)
}
for i := 0; i < 3; i++ {
fmt.Println(<-c)
}
}
func get_ip(host string, c chan string) {
addrs, err := net.LookupHost(host)
if err != nil {
fmt.Println("Host not found:", host)
c <- host + ": <error>"
return
}
c <- host + ": " + addrs[0]
}Lack of exceptions means the deeper the call stack the higher the proportion of error handling code relative to a normal (non-exceptional) code path.
For example, if you decide to refactor some code from a bigger function into its own smaller function then all error handling code have to be repeated twice (first in the child function then in the parent that calls it). It introduces unnecessary clutter and boiler-plate.
Exceptions allows you to limit the error handling to two places: the place where you detect an error and the place where you are ready to handle it and not throughout the whole call stack.
Language with a builtin garbage collection can (should) afford a builtin exception support.
I like that Go excludes some language features on purpose but in the case of exceptions Python has its merits.
However, I was interested to learn that Google style guide for C++ recommends not using exceptions. I don't know C++ (shame), but at least some of their reasoning is applicable to Python as well:
For example, when you start raising an exception in a Python function, you have to check its callers, whether they (or their callers) handle it. And vice-versa—when a Go function has “expected” error in its signature as return value, it's very obvious what you need to handle when you're the caller.
“Expected” error as return value also encourages single responsibility principle, I suppose. E.g., for a function that decodes JSON, bad syntax is “expected” error, the rest is a reason to panic().
I'm not sure if I get your example with refactoring, but it may be a case when you use panic() in inner function, recover() in outer, and return an error as usual.
That said, I've never actually used Go yet, so it's just theorizing.
[0] But then my Python code that (to me) looks more or less “solid” appears to contain a comparable amount of error handling lines, so not sure if it's a good metric.
The insight to async I/O is that this server, for this I/O bound task, will perform as well as your GOMAXPROCS example:
require('http').createServer(function(req, res) {
res.writeHead(200);
res.end("hello world\n");
}).listen(8000);
This was a great pity because I think it probably is one of the best languages ever made and didn't get the take up it absolutely deserved.
Will it?
Luvit, which is implemented on Node's libuv outperforms Node in the trivial case because of higher lua performance (and lua->c interop performance).
Like for example show me how to suspend the HTTP request and wake it up later when you receive a message back from some long running process.
Or simpler: show me how to start a long running async task from a request handler.
No, it doesn't scale on multiple CPUs if you don't use the 'cluster' package.
There's an awful global lock on the actual execution of python code, but unless the problem is performance or contention worrying about it is premature.
"As a Django developer, there wasn’t a straightforward and obvious way to just do things in the background on a page request"
I started thinking, "um, django produces http responses, you can only respond once...".
Clearly, from his gevents example, he's looking to do things that take time, and wants to do them as concurrently as possible, then send the whole response at once. But if he really doesn't want the user to wait, then this is not something you should be doing in a webserver anyways. You really should be building that into the front end javascript, and let it handle all the async data grabs from small, fast, cacheable web requests, then redraw the page as the data comes in.
This could be a lot more accessible to beginners, however, because there are moving pieces like a message queue that have to be set up and blah blah.
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)
os.cpus().forEach(cluster.fork.bind(cluster)); var fork = require('cluster').fork
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.
The documentation has the primary goal of explaining how things work, not being the canonical style guide.
Take a similar example from the Go documentation:
const NCPU = 4 // number of CPU cores
func (v Vector) DoAll(u Vector) {
c := make(chan int, NCPU) // Buffering optional but sensible.
for i := 0; i < NCPU; i++ {
go v.DoSome(i*len(v)/NCPU, (i+1)*len(v)/NCPU, u, c)
}
// Drain the channel.
for i := 0; i < NCPU; i++ {
<-c // wait for one task to complete
}
// All done.
} http = require 'http'
server = http.createServer 'localhost', (req, res) ->
res.writeHead 200
res.end 'ok'
app = server.listen 3000That could have been written better. Thanks for the feedback.
> 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.
Curious... Can't be a bank, too conservative. Hedge fund? I know Jane Street love their OCaml so functional does have a place in that world. But 25 countries? You'd have to be huge.
There is REAL WORK being done in Haskell! Now I just gotta find out how to get my foot in the door :)
This "throwaway" line on my resume: """Interest in functional programming (Erlang, Haskell, Lisp) and associated techniques as they relates to increasing software reliability and scalability."""
...has gotten me at least 2-3 calls/emails for erlang/haskell-specific work over 3-4 years, and that's without even trying.
Don't be afraid either to make up a second resume b/c from what I can tell recruiters just do google searches and click on links. With linked-in, write a "brave" summary up top and put in a strong haskell statement or two in your details section and you'll probably start getting some calls.
If you're happily employed right now then don't be afraid to change your resume / linked in / passive search to reflect your dream job instead of a "real" job-search resume. Just be ready to "change it back" when you get serious about looking.
I know two large international banks that have significant Haskell codebases. I don't know where you get the idea that banks are too conservative.
The idea comes from 10 years of working with them as an external vendor. I see all sorts (but especially Python and C++) on prop desks, but mostly C# in other areas (integration, data management etc.) That being said, nearly all of my experience is in front office trading and asset management, primarily in listed instruments, with little on OTCs, and nothing on payment processing, 'core banking' or the kind of stuff that spans the entire organisation.
It sounds like Haskell has found a niche at Standard Chartered doing perhaps just that. What are those two banks you mentioned doing with their Haskell code?
This is not fair on Haskell but that is what people think and that really is the issue that Haskell has to overcome.
But that is beside the point. Haskell is more difficult to learn.
For those of us who learned to program in an imperative language first, the difficulty with learning functional programming is unlearning all of our bad habits.
People like dons can do amazing work in Haskell. There at 10x or 100x as many people who can't (not without at least a PhD's worth of study at least), but could be productive in Go on a large array of projects they need to do.
/Studied haskell, hung out on #haskell, thinks its awesome, made me a better java programmer, but always gets blocked on showstoppers due to not knowing the incantations and deep type theory needed to structure a program for high performance and debug space leaks.
Hope the codebase runs well, because that's the bank I use in Singapore ;-)
Has you/anyone written something about how Haskell got picked for the task by that particular bank? Is the language used at other financial type businesses? I've heard some firms use Ocaml.
Jane Street.
Would be fun to see a panel with dons and Yaron Minsky discussing the pros and cons of Haskell and Ocaml, respectively.
I had some discussions about OCaml vs Haskell and, honestly, nobody could come up with a particularly strong case in either direction. (That said, we didn't do anything using multiple cores where Haskell has a bit of an advantage, I believe.) It always came down as "well, Haskell is awesome, but we're already using OCaml and it's pretty awesome too, and maybe easier to learn".
Much more interesting would be Haskell/OCaml vs everybody else, but that gets played out all the time anyhow :P.
Reality and PHP would disagree for 90 to 99% values of "you".
Widely used web servers include http://snapframework.com/ and http://www.yesodweb.com/. There are widely available numbers and reviews of these systems. A new book by O'Reilly covers Yesod (http://www.yesodweb.com/book)
Erlang is nice, but has its own not-so-simple issues: http://www.youtube.com/watch?v=G0eBDWigORY
Interestingly, many things in Go's design that might seem 'deficiencies' from the point of view of Erlang means most of those problems don't apply to Go at all.
Is there some sort of Go package manager? How does all this shit work?
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.
You will get an answer quite fast.
From https://github.com/bmizerany/pq/blob/master/conn_test.go:
func TestExec(t *testing.T) {
db := openTestConn(t)
defer db.Close()
_, err := db.Exec("CREATE TEMP TABLE temp (a int)")
if err != nil {
t.Fatal(err)
}
r, err := db.Exec("INSERT INTO temp VALUES (1)")
if err != nil {
t.Fatal(err)
}
It's not really that hard. I just latch on to a broker that I'm already using elsewhere in my stack (Redis). Celery makes it super simple to run a command in the background.
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
What's more, the strategy of just spawning a thread to do with async processing doesn't scale. Once you hit the limit of requests that a machine can process, you'll need a distributed work queue anyway. Or do Go coroutines run through some sort of managed execution queue?
Of course if speed is important, you should ditch CPython anyway.
A language is just one tool in your toolset. I love using Go very much, but I would recommend learning on Python. There's much more literature out there, more people you know will know it, and if you are looking for work, there are effectively zero entry-level programming jobs in Go.
The reason you keep hearing about Go is that it just very recently hit its 1.0 release, so it it a comparatively new language, and it's just a topic of conversation. Talking about Python isn't really newsworthy in the same way, because for most people, it's just a fact of everyday life. Go, however, is this new thing that's a little mysterious, that most people haven't tried yet.
Have you ever heard the phrase "you can never really know yourself until you know others"? Well, that's true of programming languages, too; learning new languages can help you to write better code in a language you were already familiar with. Learning new languages is great practice for any programmer.
But to start, I would just stick with Python and write some things that make you happy. That's the most important part; to figure out how to use code to make yourself happy. Which language you use is really just an implementation detail.
Actually, not without going out and meeting new people. I'm a physician, so meeting anyone who knows anything about IT is quite challenging. And the helpdesk folks at the hospital usually aren't in the mood to troubleshoot those kinds of errors!
I'm sure Go will mature here and the defaults will evolve along with that. Whether that will take years or not is up for debate but at least it's a possibility and doesn't cost the programmer anything other than a recompile if they start with careful use of goroutines today.
https://groups.google.com/d/topic/golang-nuts/bP6_KD51ed4/di...
.. until you set runtime.GOMAXPROCS(runtime.NumCPU())
Is it too early to switch from Python/Ruby to Go? Maybe it would be better to wait for Dart.
I known that Mozilla and MS won't support Dart however they also don't support Go.
narrows eyes...
/nerdhate
Sure, the go example is shorter, but the JavaScript version reads much nicer (at least to me).
Third party libs still are more uneven, but that is not much different from Python.
It's a usability thing. If you make something easier to use, more people use it; as a result, node.js has introduced the topic of nonblocking i/o in a way that other technologies have been unable to do. It also allows you to share code between the client and the server, which may or may not matter, depending on your project. And for a lot of developers, node.js means using a language you already know.
The guys at Kitchen Table Coders do a workshop where they make a physical game paddle with an arduino, and then hook it up to a node.js server, so that two people can play pong with physical controllers in their browser. They're able to teach that workshop in a day. I think that speaks volumes for types of things that you can do with node.js, and its mass appeal.
But, like I said in the article, I find that node.js becomes disorganized quickly, and I just plain don't enjoy debugging JavaScript. On top of that, if you need to do CPU-bound work, node.js basically forces you to create an isolated process and perform i/o with it, but now you have an OS process for each of these instances, whereas in Go, creating a goroutine and communicating with it over channels is much more lightweight. Node.js has its merits, and I don't mean to say "nobody use node.js ever!", I just don't like using it.