4 ms·

Also what to point out that I fully realize that Go is a lot faster than python at preforming the same task but this kind of analysis is dangerous because it le

Also what to point out that I fully realize that Go is a lot faster than python at preforming the same task but this kind of analysis is dangerous because it leads inexperienced engineers to believe that changing languages is a good performance optimization which should usually be the last step/idea considered. It's expensive and dangerous to switch languages mid stream and while it's sometimes the exact cure it needs to be weighed very heavily to make sure it's the right situation. This article, at least the headline misses that piece of the puzzle pretty fully IMO.

blt 12y ago
Not sure I agree with you there. IMO, porting between languages with similar abstraction levels is not that hard. I ported some Python code, whose logic took weeks of fine-tuning, to C# in less than a day. Go still has a garbage collector and its type system is similar in philosophy to Python's duck typing. Unless you are porting extra dynamic code (eval(), monkey-patching) or deeply intertwined with an unusual library, it should be a fast process. On the other hand, I was leaving Python get real OS threads, not to increase performance.
- wting 12y ago
  This is nitpicky, but Python threads are kernel threads. It's the GIL that restricts CPython to a single core. OTOH goroutines are green threads multiplexed onto kernel threads (aka N:M thread model).
- nkozyra 12y ago
  This obviously also depends heavily on the complexity of the application and the available resources. Even so, a production-ready transition in a few weeks time doesn't leave a ton of time for benchmarking and testing, but as someone who operates on a fly-by-the-seat ethos more often than I should I'm in no position to be tossing stones around.
merrua 12y ago
There has been articles talking about rewritting being less of a terrible idea if your writing a SaaS. Not to mention the throw one out, you will anyway idea. I'd be interested though, in hearing more about what they rewrote into Go. Its most probable its not all of their codebase.
- dev360 12y ago
  Yes, it sounds like its a websocket server. A lot of that stuff is relatively low complexity if you glue everything together with a message queue since they can be made language agnostic very easily.
- mattrobenolt 12y ago
  Just our realtime system, and we run some asynchronous tasks with Go now, specifying to replace a few things that were done by Celery previously. See this shitty thing I wrote to bridge the gap: https://github.com/mattrobenolt/go-celery https://github.com/mattrobenolt/go-celery :)
nkozyra 12y ago
Actually, I think "Go is faster" has two primary built-in points: 1. It's faster in terms of real performance - given its proximity to C, optimization at the compiler level for multiple platforms, that its highly concurrent and run compiled (usually), this is no shocker. But, 2. It's faster than transitioning from a dynamic scripting language than it would be to transition to, say, C or C++ or Java, etc. Not that it's syntactically similar (obviously), but that language, testing and deployment design won't present any egregious bottlenecks and that there's so much built into the core library that complements an http-based service such as this. In other words, the prospect of going from Python (or Rails or PHP or whatever) to "faster language X" has historically imposed an inherent cost in terms of development that I think a language like Go mitigates to some degree by design.
- yebyen 12y ago
  > and run compiled (usually) I think you are talking about 'go run', which one might easily mistake for an interpreter because of the speed of the compiler, but it's actually compiling your code and running it. Were you talking about something else?
  - nkozyra 12y ago
    I wasn't talking about go run, no - there have been a few examples of running go interpreted I've seen posted here. They may well just be experiments but I left the "usually" as my caveat. Edit: I swear there was an interpreter demo'd, but I may well have been thinking of something like agora, which interprets Go-like code within Go.
    - yebyen 12y ago
      I was actually fishing for cool stuff I hadn't heard of, like agora. I don't get to dive into very much Go news! Thanks

blt 12y ago

Not sure I agree with you there. IMO, porting between languages with similar abstraction levels is not that hard. I ported some Python code, whose logic took weeks of fine-tuning, to C# in less than a day. Go still has a garbage collector and its type system is similar in philosophy to Python's duck typing. Unless you are porting extra dynamic code (eval(), monkey-patching) or deeply intertwined with an unusual library, it should be a fast process. On the other hand, I was leaving Python get real OS threads, not to increase performance.

wting 12y ago
This is nitpicky, but Python threads are kernel threads. It's the GIL that restricts CPython to a single core. OTOH goroutines are green threads multiplexed onto kernel threads (aka N:M thread model).
nkozyra 12y ago
This obviously also depends heavily on the complexity of the application and the available resources. Even so, a production-ready transition in a few weeks time doesn't leave a ton of time for benchmarking and testing, but as someone who operates on a fly-by-the-seat ethos more often than I should I'm in no position to be tossing stones around.

merrua 12y ago

There has been articles talking about rewritting being less of a terrible idea if your writing a SaaS. Not to mention the throw one out, you will anyway idea. I'd be interested though, in hearing more about what they rewrote into Go. Its most probable its not all of their codebase.

dev360 12y ago
Yes, it sounds like its a websocket server. A lot of that stuff is relatively low complexity if you glue everything together with a message queue since they can be made language agnostic very easily.
mattrobenolt 12y ago
Just our realtime system, and we run some asynchronous tasks with Go now, specifying to replace a few things that were done by Celery previously. See this shitty thing I wrote to bridge the gap: https://github.com/mattrobenolt/go-celery https://github.com/mattrobenolt/go-celery :)

nkozyra 12y ago

Actually, I think "Go is faster" has two primary built-in points: 1. It's faster in terms of real performance - given its proximity to C, optimization at the compiler level for multiple platforms, that its highly concurrent and run compiled (usually), this is no shocker. But, 2. It's faster than transitioning from a dynamic scripting language than it would be to transition to, say, C or C++ or Java, etc. Not that it's syntactically similar (obviously), but that language, testing and deployment design won't present any egregious bottlenecks and that there's so much built into the core library that complements an http-based service such as this. In other words, the prospect of going from Python (or Rails or PHP or whatever) to "faster language X" has historically imposed an inherent cost in terms of development that I think a language like Go mitigates to some degree by design.

yebyen 12y ago
> and run compiled (usually) I think you are talking about 'go run', which one might easily mistake for an interpreter because of the speed of the compiler, but it's actually compiling your code and running it. Were you talking about something else?
- nkozyra 12y ago
  I wasn't talking about go run, no - there have been a few examples of running go interpreted I've seen posted here. They may well just be experiments but I left the "usually" as my caveat. Edit: I swear there was an interpreter demo'd, but I may well have been thinking of something like agora, which interprets Go-like code within Go.
  - yebyen 12y ago
    I was actually fishing for cool stuff I hadn't heard of, like agora. I don't get to dive into very much Go news! Thanks