51–60 of 202 posts
It it true there's no way to spawn a background task in Django without making the user wait?
Lots 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 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.
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…
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.
Earlier quoted context omitted.
"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 brea…
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.
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) }
I'd like to see more detail about the real problem he was facing in python. It sounds like he mostly wants a non-blocking background job "I don’t want to set up another daemon, I just want to send some email in the background!" Why not just use Queue (thread-safe, waitable, built-in) and a background thread(pool)? There's an awful global lock on the actual execution of python code, but unless the problem is performan…
Not only that, but there's a multiprocess Queue class as well that is a drop in replacement for the threaded one. So if you are having problems with GIL contention (unlikely, but possible), you can still just as easily use multiple processes.
Is there some sort of Go package manager? How does all this shit work?
Earlier quoted context omitted.
> /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.
According to his profile, he works with/for Standard Charter Bank. 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.
Another gonatic? I'm immediately reminded of the days when everyone who liked D proclaimed it would overtake C++ and rule the world with terrible, contrived examples: "let me show you why my language is better than yours by completely misunderstanding how to solve a problem, then implementing that broken/overengineered solution in your language, then compare it to something my language's API can do for me, just so we…
Big difference is that D did not have a Google backing it and D had a fairly major falling out by different factions. 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.