What's wrong with good old threads. It's not that hard. And threading in Java will blow away any pseudo concurrency setup in python. Been there done that. Love python but just couldn't get the performance we needed.
Why I went from Python to Go (and not node.js)
171–180 of 202 posts
Re: Why I went from Python to Go (and not node.js)
#172Why do you need concurrency to send an e-mail? Why do you need to do it in the background? Just trying to understand this concurrency thing...
it's a slow, i/o operation. Perhaps it takes a second or two; maybe you're generating a PDF and the email is of non-negligible size, or your email provider is slow that day, or something of that nature. When a user clicks a button, and the response is just "ok, we sent you an email", you can just issue that response immediately, and then send the email. Otherwise, the user's browser just sits there and hangs until the entire process is done.
Re: Why I went from Python to Go (and not node.js)
#173Why would anyone go to Node.js? Serious question.
nonblocking i/o is an important feature if you want to make something responsive that will handle a lot of connections. node.js brings that to the foreground, and makes it a topic that is digestible for a lot of programmers that have never seen it before. The end result is that by using node.js, a developer is able to experience one element of concurrency that they may not have had exposure to using Ruby/Python/PHP. Yes, it is possible to do nonblocking i/o in Ruby/Python/PHP, but it isn't as natural of an experience.
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.
Re: Why I went from Python to Go (and not node.js)
#174Why would anyone go to Node.js? Serious question.
[deleted]
Re: Why I went from Python to Go (and not node.js)
#175Why would anyone go to Node.js? Serious question.
[deleted]
Re: Why I went from Python to Go (and not node.js)
#176Based solely on this article, and this article alone, and knowing nothing more about Jordan Orelli, the conclusion I drew about the author is that he thinks "Java Web Programming" strictly refers to applets and nothing more. narrows eyes ... /nerdhate
ah, I was working on a game. It was a space shooter. I wanted it to be viewable in the browser so that I could just send a link to my friends and they wouldn't have to download it. I wound up writing it in AS3.
Re: Why I went from Python to Go (and not node.js)
#177Earlier quoted context omitted.
It doesn't look like C!!!
C is can be intimidating, C++ often is. You have to gain much experience to be able to write good C++ code. With Erlang it's simple. It's supervisiors and gen_servers all the way down.
C++ is not intimidating, it is terrifying.
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.
Re: Why I went from Python to Go (and not node.js)
#178Why do you need concurrency to send an e-mail? Why do you need to do it in the background? Just trying to understand this concurrency thing...
it's a slow, i/o operation. Perhaps it takes a second or two; maybe you're generating a PDF and the email is of non-negligible size, or your email provider is slow that day, or something of that nature. When a user clicks a button, and the response is just "ok, we sent you an email", you can just issue that response immediately, and then send the email. Otherwise, the user's browser just sits there and hangs until th…
[deleted]
Re: Why I went from Python to Go (and not node.js)
#179Earlier quoted context omitted.
There is no 'horrible gotcha' with tuples of one element. Have you even tried generator expressions? Do you have any specific performance problem, or do you just suppose that you couldn't write sufficiently performant code in Python? 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 whethe…
For what it's worth, I've used Python professionally and in several classes. I certainly don't have much experience in it, but it would be odd if I did--why would I use a language I don't particularly like too much? 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", "…
I don't get your tuple example. If you don't use the tuple operator - the comma - why would you expect to get a tuple?
People trot Python out as the gold standard of language design
Who?
Re: Why I went from Python to Go (and not node.js)
#180Earlier quoted context omitted.
I think the issue with single-letter variables goes deeper than it just being unreadable (although its that too for someone that isn't "used to 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").
Generally, I try not to use single letter variable names in any scope that doesn't fit into a single screen in my editor. That way, I don't need to remember what "f" means, it's right there in front of me. And I shouldn't have too many variables in that scope, so conflicts aren't all that important; if I really do, I just start using multi-letter names again.
This is a good heuristic. For me, single letter variables are almost always iterators in places where space is at a premium (i.e. one line list comprehensions in python). If I'm breaking a loop out over multiple lines (which is almost always the case), I prefer a longer, more informative variable name.