Space Monkey dumps Python for Go

https://www.spacemonkey.com/blog/posts/go-space-monkey

by jtolds • 12 years ago

338 203 12 years ago

phaedryx• 12 years ago

I'm curious what the memory usage was like before and after.

jtolds26• 12 years ago

Doh, I totally should have mentioned that, cause yeah that was big too. We went from about 80-95mb resident memory (and our cgroups config doesn't allow for much swap) to about 50-60mb on average, which is a metric we weren't even trying to get lower. So, yeah, that's another win we should have mentioned.

jessaustin2• 12 years ago

After all of this optimization, we got up to 1.2 MB/s.

Ouch. That was a lot of work for 0.2 MB/s. The next 2.8 MB/s was also a lot of work, but it seems conceptually more straightforward.

wspeirs2• 12 years ago

Switching to Go though they were able to get 4MB/s. Even though they claimed to do "line-by-line" translation, I wonder how much of that speed-up was language/libraries vs rearchitecting.

robotresearcher• 12 years ago

Unless there is some reason to disbelieve the line-by-line claim, can't we assume it's all due to the more performant implementation?

Python is a joy when it's fast enough, but it's not surprising that it isn't good at throughput on small devices.

melling• 12 years ago

"So in the bottom of the ninth, we decided to transliterate our 90k lines of Python directly to Go, line by line.

It took us about 4 weeks."

How many people worked on the project? What's the build time on a program of this size?

jtolds26• 12 years ago

We had about 3 or 4 guys full time. On my silly little i3 laptop, the whole codebase builds in 18 seconds - I suspect most of that is our C extensions.

yukichan2• 12 years ago

C extensions because something you wanted wasn't in go? Are you using cgo to build?

yukichan2• 12 years ago

I wonder how many lines of code they ended up with afterward, although admittedly lines of code is a pretty silly metric. I think it is useful in orders of magnitude when describing the size of a project, 100 lines, 1,000 lines, 10,000 lines, 100,000 lines all speak volumes about effort. So I guess what I'm wondering if you got about a roughly similar sized code base or significant change difference?

jtolds26• 12 years ago

EDIT: fixed my calculations again.

Without tests but with our supporting libraries, our codebase was 36784 lines of Python. Those same lines became 41717 lines of Go.

Counting lines of code is hard.

collyw• 12 years ago

Actually in this case, comparing two languages doing exactly the same thing, LOC is a relevant measure (its a crap measure of programmer productivity). It could show the expressiveness of a language. Also I am a believer that less lines of code = less likely to have bugs.

sandGorgon3• 12 years ago

We rewrote Twisted Deferred handling to be 30% faster. We optimized the Twisted Reactor event loop to not only do less constant work, but to prefer incoming I/O.

...We spent long nights poring over profiling readouts and traces, wrote our own monitoring system, and wrote our own benchmarking tools

... We enabled cgroups on our Python process to tightly control memory usage and swap contention without requiring a different Python memory allocator scheme.

This is very interesting for the rest of the Python/Twisted community - now that they are not using this (and so is'nt part of the secret sauce), I wonder if they are willing to push this out as a patch/blog post ?

jtolds26• 12 years ago

We're planning on open sourcing a bunch of stuff. We'll have some follow up posts.

sandGorgon3• 12 years ago

thanks !

really look forward to this..

stuaxo• 12 years ago

Did you release your faster version of the Protocol Buffer library ?

jtolds26• 12 years ago

While we're planning on open sourcing some things, I'm not sure we'll ever open source that one. Even though it was much faster, it didn't see much time in production due to the less than desirable impact it made (go Amdahl's law), and it still has some bugs and was highly customized to our specific protocol buffer definitions.

Internally, Google has something faster for Python, but they haven't released it yet. You might try putting pressure on them here: https://code.google.com/p/protobuf/issues/detail?id=434

http://yz.mit.edu/wp/fast-native-c-protocol-buffers-from-pyt... talks about the issues some more with some links to other rewrite attempts.

sandGorgon3• 12 years ago

would you have gone with thrift if you had to do it all over again ? I ask because I saw the bug description and the glacial response ;)

leccine4• 12 years ago

Well it is kind of obvious that a compiled language is going to be faster than an interpreted one, especially the way how these interpreters work (https://wiki.python.org/moin/GlobalInterpreterLock). You can fool yourself with Twisted (or in Ruby with EventMachine, Goliath etc.) but it gets so just a bit ahead. The surprising fact for me is that Go is not as much faster. I was expecting a bigger gap in the performance between Go and Python. Understanding where your bottlenecks are is crucial and it is not super hard in Go. https://www.datadoghq.com/2014/04/go-performance-tales/ I guess the SpaceMonkey guys might further improve the performance just by doing a thorough analysis on their code.

MBlume2• 12 years ago

They wrote a naive, line-by-line translation of their python code in Go. There's probably still a lot of low-hanging optimization to be had.

leccine4• 12 years ago

Exactly. I am kind of wondering why this 1:1 translation came up why not just follow best practices and implement a functionality instead...

angersock2• 12 years ago

I was expecting a bigger gap in the performance between Go and Python.

Perhaps we've come a pretty long ways in the interpreted languages department? Or, that the cost of interpreting is vastly less than speed losses due to IO or memory access?

"Interpreted is always slower than compiled lol right guise?" was a tired refrain ten years ago, much less today.

alayne• 12 years ago

CPython's bytecode interpreter has not really improved at all in 10 years relative to JITs and compilers.

jtolds26• 12 years ago

Well and more so, our workload really should be mostly I/O bound. We freed up the CPU with Go, but CPU is no longer the current bottleneck.

Artemis22• 12 years ago

Python has benefited from years of throughout optimization of the language for real-world use. Go is still under heavy development and is not as optimized as other languages that have devs focused on optimization (that explains why node.js is a bit faster than Go for handling HTTP requests at the moment).

stock_toaster2• 12 years ago

  > (that explains why node.js is a bit faster than Go for handling HTTP requests at the moment)

Pretty sure node's http parsing is handled by http-parser[1], which is written in C (originally pulled from nginx as I recall).

Go's http parser is written in Go.

[1] https://github.com/joyent/http-parser

nickpresta• 12 years ago

    > (that explains why node.js is a bit faster than Go for handling HTTP requests at the moment)

I'm not sure that is true any more:

http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...

At any rate, "handling HTTP requests" can't possibly be your bottleneck, given network communication, serialization, etc.

rakoo2• 12 years ago

it is kind of obvious that a compiled language is going to be faster than an interpreted one

While it may be obvious, the interesting question is why exactly. There's been a good presentation from Alex Gaynor [0] on this topic. TL;DR: Dynamic languages ar slow not because they can't be optimized, but because developers make a worse use of memory and have sucky algorithms, inducing way more mem allocation and copy than needed. If you can be smart about those, then your dynamic language can match static languages.

[0] https://speakerdeck.com/alex/why-python-ruby-and-javascript-...

leccine4• 12 years ago

There are certain things that you can't really avoid using an interpreted language. How would you go around Ruby's GIL for example when you specifically need multiple threads (not talking about green threads). I agree that some of the stuff is on the developers developing libraries and performance is not kept in mind but there are hard limits you can't really do anything about.

outworlder• 12 years ago

Except for the fact there are no 'interpreted' or 'compiled' languages. What we have are implementations.

This is not merely nitpicking. Any turing-complete language can be interpreted or compiled. Language specs tend to make one side easier, but that doesn't mean that Python cannot be compiled (and it is actually compiled to bytecode). You can have something similar to a GIL in a compiled language too.

One of the things that makes it easier to increase performance is having type declarations. This makes it much easier for the compiler to reason about the code, which can lead to increased efficiency. But optional type annotations can accomplish just as much.

wisty2• 12 years ago

That's actually kind of shocking. I thought it would take way more work to port from Python to Go, and a 400% speedup is way less than I'd have expected (though this is string handling, and the Python was already brutally optimised with C modules where it counted).

jtolds26• 12 years ago

We're I/O bound now (as we should have been to begin with), so speedup isn't the linear function you might expect here.

impostervt• 12 years ago

Is anyone else getting SSL errors on the site?

jtolds26• 12 years ago

We're getting slammed :( We're spinning up a new webserver.

nkozyra2• 12 years ago

This would have never happened with Python ;)

chimeracoder2• 12 years ago

This article doesn't address one of the biggest benefits I've noticed in switching from Python to Go.

I've been using Go for almost two years now. Like OP, I am/was primarily a Python developer. Like OP, my first Go project was a time-sensitive rewrite[0] of a project from Python (tornado) to Go.

Even though I was an experienced Python developer, the Go rewrite was marginally (~20%) faster[1]. But the real benefit came from the subsequent development - refactoring, rearchitecting, and maintaining the project on an ongoing basis. Go was designed to make it easy to scale the maintenance[2] of software, and on this one axis, it absolutely blows every other language and environment I've used out of the water.

For a fresh project, I'd say Go is about 10% slower to write than the equivalent Python[3] for the average case. But the time/cost savings are very quick to come thereafter.

[0] I would absolutely not recommend doing time-sensitive rewrites in general, but that decision was a separate matter.

[1] Some of this is due to the nature of rewrites in general, but the fact that it wasn't slower to use a language I'd never used before says something about the language.

[2] Scaling software development as teams grow is very different from scaling software as users grow.

[3] Assuming comparable familiarity with both languages, which is rarely the case, of course

aturek• 12 years ago

This sounds really interesting, but can you elaborate on how Go scales better with maintenance?

(disclosure: I haven't fiddled with Go at all yet, so I know nothing about the language itself)

SpikeGronim• 12 years ago

Several things make it easier to maintain:

- super fast compile times for fast developer iterations

- you can create an interface (set of methods) that your module owns, and apply it to objects created by other modules without recompiling. If you only need one method you can take that one. It encourages decoupling you from your dependencies.

- the code has one correct formatting convention and a tool that will auto-format your code

- many complex rules for numeric conversions that are implicit in C and cause no end of trouble are explicit and much simpler in Go.

- treating concurrency as a series of sequential process connected with channels makes it MUCH easier to reason about.

eternalban• 12 years ago

Would you please expand on [2] please with concrete examples.

codezero• 12 years ago

I also rewrote a tornado service in Go. The thing I found most surprising was that the length of the program was about the same as the Python version. I had expected it to be quite a bit longer.

nostrademons7• 12 years ago

I'm curious, how does it compare to Java with a good IDE (eg. Eclipse or IntelliJ)?

One thing I really missed when I abandoned the Java world and went to C++/Python was the refactoring and formatting tools available in the IDE. I could set it up so it'd auto-format my code on save, so that I could rename methods with a single keystroke, so that I could pull out classes or add getters/setters, so that I could add parameters, etc. I know Go supports some of that through gofmt and go fix, but I'm curious if anyone is both an experienced Java dev and an experienced Go dev and can compare the continued maintenance costs of the two.

BTW, I would put the productivity premium of Go over Python at about 50%-2x, not 10%. I did a mid-size (~6 man-months, though much of that time went into interactions with other teams) green-field prototype in Go at Google, and found myself really missing constructs like list comprehensions, dynamic typing, strong support for literal data, ability to treat user-defined types just like the built-ins, etc. I do think you'll make some of that back in continued maintenance - I actually really enjoyed working with Go - but I didn't experience the claims of "Go is just as good as Python for prototyping", as someone with a fair amount of Python experience.

MBlume2• 12 years ago

Doesn't Go come with an executable that reformats .go files to a canonical format?

micro_cam3• 12 years ago

The availible go ide's are still young but go includes a lot of really nice tooling in the core distribution. The gofmt tool enforces a canonical format for go code and I have sublime text set up (via gosublime) to reformat on save and use the gocode autocomplete/linting daemnon.

Gofmt is actually one of my favorite parts about go and I feel that it, along with the simple documentation system and godoc.org save me a ton of time making my code ready for others to read/use.

The code base behind gofmt and gofix can also be used for other tools, i haven't felt the need for a powerful refactoring tool but I'm sure one will show up eventually.

I do miss list comprehensions and operator overloading but I understand the dev's arguments against those.

stcredzero3• 12 years ago

missing constructs like list comprehensions, dynamic typing, strong support for literal data, ability to treat user-defined types just like the built-ins, etc.

Of those, I only see comprehensions as something that's severely lacking, though I am not a Python guru by any measure. Dynamic typing: Go has duck typing, which gives some of the same benefits. Different refactoring strategies that take advantage of duck typing over other things you'd do with dynamic languages (like just substituting an object of a different type willy-nilly) will probably make up for the rest. I don't see strong support for literal data as a big productivity gain. Go also does a rather good job of treating user defined types like the built-ins and vice-versa, with a few exceptions like maps.

I didn't experience the claims of "Go is just as good as Python for prototyping", as someone with a fair amount of Python experience.

A lot of your competence with Python for prototyping probably has to do with your competence with Python. A lot of the advantage of Go is what it doesn't have. It's a much simpler system, so it's easier to design around, especially as one needs to get closer to the metal.

jbooth• 12 years ago

Experienced Java and Go dev here.

On formatting, gofmt is awesome. There's an IDE called LiteIDE which automatically calls gofmt for you, or you can just run it yourself whenever. Additionally, because there's deliberately no room to customize gofmt, you don't have to spend time in pointless meetings when "that guy" decides it's time to rewrite your company eclipse templates and argue over all the minutiae.

As far as refactoring, nobody's built an IDE integration that comes close to eclipse/IDEA for that as far as I know. It's totally doable in Go, in a way that it wouldn't be for Python (yay types), but I don't think anyone's done it. On the upside, doing it manually is less painful than it would be in typical Java code, due to type inference and having less code to begin with.

jaimeyap• 12 years ago

There is actually a decent open source, third party Go plugin for Intellij that works pretty well. Our team has been using it successfully on a fairly large project.

It's slightly annoying to setup, but absolutely worth it.

JPKab• 12 years ago

Is there a book or tutorial or blog you would recommend for a Python person to learn Go? I'm certainly interested in what your thoughts are.

stanley• 12 years ago

Here's a few links you might find helpful. They're not specific to Python developers, though.

http://www.golang-book.com/

http://www.golangbootcamp.com/book

http://talks.golang.org/2012

https://gobyexample.com/

chimeracoder2• 12 years ago

Sure - I actually gave a talk last year on this exact topic. There's an audio recording somewhere, but here's the repository for the slides (which contains a link to the PDF): https://github.com/ChimeraCoder/go-for-pythonists

waterside81• 12 years ago

I wrote about my experience here:

http://blog.repustate.com/migrating-code-from-python-to-gola...

ragsagar• 12 years ago

How does Go makes it easy to scale the maintenance of software?

andybak• 12 years ago

I've got a completely data-free feeling that Ruby people hitting performance bottlenecks seem to reach for node whilst Python people have a tendency to look at Go.

Does anyone else think that this rings true? And if so - is it a cultural thing?

steveklabnik2• 12 years ago

There are a _lot_ of Rubyists interested in Go, I'm not sure we can draw any real conclusions about the relative popularity of the move at this time.

AYBABTME• 12 years ago

I have the feeling that both camps are going for Go instead of Node.

My only data-point is the shop I work for, and folks in the community that I know come from a Ruby background, such as Dominik Honnef, Ben Johnson, Mitchell Hashimoto.

chc• 12 years ago

My impression is that people writing Web interfaces reach for Node while people writing CPU-heavy programs reach for Go. It so happens that Ruby people are more often writing simple Web apps while Python is somewhat more likely to be used for more computationally intensive tasks, but I think that's about as far as the correlation goes.

bdcravens• 12 years ago

I think that depends on whether they're more of a "Rubyist" or primarily Rails developers who know "just enough Ruby". I think Node (and especially a framework like Meteor or Express) is more approachable for those who spend most of their time in a framework like Rails.

_random_• 12 years ago

JavaScript people go for Node.js - they have nothing to loose.

sigil2• 12 years ago

It sounds like the cost of context switching between these very different workloads (crypto, disk I/O, network I/O, protocol buffer parsing and formatting) could be improved in Twisted.

Any idea where the overhead comes from? Twisted, or the Python interpreter itself? Is this a GIL performance issue? Or perhaps even lower -- something here is really hostile to CPU cache?

I realize this is a matter of taste, but my favorite async framework is still the kernel. Write small programs that do one thing well (and thus have pretty uniform workloads) and then let the kernel balance resource usage.

After continuing to hit walls with the standard Python Protocol Buffer library, we wrote our own that was 5x faster than the barely-documented C++ Python Protocol Buffer compiled module support.

Ugh yeah, the standard Python protobuf library is pure python and horribly slow. And it requires code generation -- in a dynamic language! The C++ one is faster, but also requires code generation and is just nasty to work with.

Not that this matters much to you at this point, but I have a small C/Python protobuf library that's 10x faster than the standard Python protobuf: https://github.com/acg/lwpb

PS. I see you're in SLC area -- me too. We should talk tech shop in person sometime!

jtolds26• 12 years ago

Hi! Yes, you should totally swing by. Shoot us an email :)

I think the sort of performance issues we were hitting were honestly related to just Python runtime overhead. A Python function call is actually really expensive, and with Twisted Deferred handling, it's really hard to eliminate the massive amount of function calls each I/O event does.

We just had a really slow CPU so we did our best to eliminate as many Python function calls in hotspots as possible, but yeah that was challenging.

sigil2• 12 years ago

A Python function call is actually really expensive, and with Twisted Deferred handling, it's really hard to eliminate the massive amount of function calls each I/O event does.

Ah, makes total sense. Any particular reason you chose to use Twisted in a hardware appliance? Is there a web interface that's supposed to be super responsive?

lvh• 12 years ago

Did you ever get a chance to evaluate what it does under PyPy? In my experience, there's quite a few such cases where it eliminates most of the overhead, and it's not even uncommon to see it generate what appears to be optimal x86_64.

hyp02• 12 years ago

Wouldn't java be the natural rewrite, for performance speed up? Java is betwen Python and C, in terms of ease-of-use and performance. They mention a C rewrite, but not a java one...

I guess the concept here is that Go is between Python and Java: (much of) the ease of use of Python + (much of) the performance of Java. The type system literally straddles the dynamic and static.

[ I also detect an enthusiasm for cool, new tech for its own sake (despite risks and cost, or whether it's actually better or not - hell let's find out!) ]

untothebreach• 12 years ago

Since they are targeting an embedded ARM system, maybe they had concerns about running the JVM on such constrained hardware?

pjmlp2• 12 years ago

You mean like these?

https://www.aicas.com/cms/en/JamaicaVM

rcfox• 12 years ago

Actually, some ARM processors have instruction set extensions to execute Java bytecode in hardware. http://en.wikipedia.org/wiki/Jazelle

sagichmal3• 12 years ago

    > The type system literally straddles the dynamic and 
    > static

The Go type system is fully static...

nostrademons7• 12 years ago

Go has an escape hatch (interface{} and downcasts) that basically give it an embedding of a dynamic type system inside the static one. You end up having to use this a lot if you're doing things like decoding complex JSON data structures or working with containers, since Go doesn't have generics.

bsg75• 12 years ago

[ I also detect an enthusiasm for cool, new tech for its own sake (despite risks and cost, or whether it's actually better or not - hell let's find out!) ]

Why? Because they did not choose Java?

njharman• 12 years ago

Java is betwen Python and C, in terms of ease-of-use

Opinions vary highly on that claim. In fact, I've never seen anyone claim "ease-of-use" as one of Java's properties.

kazagistar3• 12 years ago

He is putting it higher then C. Its not like he is setting a particularly high bar.

flavoie• 12 years ago

I'm curious if they tried Cython. I've read that you can achieve up to 35% speedup just by compiling python code, plus you can type pyx file to get near C performance.

I never tried it, this would have been a nice use case.

jtolds26• 12 years ago

We did. We used Cython where we could, but Cython doesn't work with Twisted (or at least inline deferreds, which holy we had everywhere), due to different generator semantics. Edit: in fact, our internal protobuf lib was all generated Cython. We had a code-gen inception.

sfk3• 12 years ago

And the website takes more than 30s to load...

bananas• 12 years ago

At least it does load. A lot of sites fall over on a good HN'ing.

sfk3• 12 years ago

And a lot of sites survive just fine. I don't think "at least it loads" is something to be proud of, especially when the topic is performance.

yelnatz• 12 years ago

Our website is Apache + Python

jtolds26• 12 years ago

We just doubled our instance count, we should be good now.

sfk3• 12 years ago

LGTM, and your response time to "support" requests is certainly great! I'll leave my grumpy comment, so that the context does not get lost.

jlafon• 12 years ago

If you did a line for line transliteration, did you use any of Go's concurrency features such goroutines or channels? I ask because I find that when I translate a program from Python to Go that it's beneficial to structure the program differently so that I can use goroutines.

jtolds26• 12 years ago

With Twisted (and with our threadpool worker pools), many patterns translated directly into Goroutine usage in a much cleaner way. Where with Python we were using our own helper libraries, Go's stdlib and the language itself were often more than enough.

We didn't end up using channels too much. Deferreds got translated into Futures that we wrote a small library for. Many of our Go-specific utility classes do use channels heavily though.

jpatel3• 12 years ago

fyi..login link fails on the site.

wting• 12 years ago

I think people are rediscovering the benefits of static typing for performance and correctness reasons. The latest generation of statically typed languages[0] all have some level of type inferencing which helps.

If Python is fast enough for you, it’s a fantastic language. The problem is once performance or codebase demands scale, dynamic typing rears its ugly head and there are no simple solutions. At work we sidestep this issue by writing a plethora of tests, but now dynamic typing productivity gains are offset and we spin up a lot of AWS instances for performance.

[0] Go, Rust, Scala. Haskell and OCaml have had it for a while.

diminish• 12 years ago

While web 2.0. and mobile is reaching maturity with winners are consolidating the market we see the trading of productivity with performance and reduction of operational costs... I m more curious of upcoming booms and which languages and frameworks they are going to bring.

femngi• 12 years ago

C++ isn't exactly a new language but has also had type inference for a few years. I think people still think of C++ as that dusty old thing in the corner and forget that it is actually capable of a lot of the things users of these new languages get excited about.

masklinn2• 12 years ago

C++'s auto is younger than most of these languages (let alone than Haskell or MLs), to say nothing of actual tooling support.

decasteve• 12 years ago

C++11 is almost a new language. Coming back to C++ now after almost a decade away is exciting.

micro_cam3• 12 years ago

I really hope the go compilers will soon support shared object output so we can write python extensions in go instead of having to fully dump one for the other. I know it was a maybe for go 1.3 but I haven't heard much chatter and fear it will get pushed backed.

jtolds26• 12 years ago

It's not going to be in 1.3 but the chatter is they might attempt something for 1.4

micro_cam3• 12 years ago

I hope so, I have some analytical code I really want to wrap for R and Python without the overhead other methods require.

dalek2point3• 12 years ago

Can someone tell me how much control GOOG has over the development of Go? I'm interested, but worry that is this another GOOG "open source" project that they have a huge say in.

wmf• 12 years ago

Even if Go is completely controlled by Google today, there are enough companies using it that they can fork if Google turns evil.

GhotiFish• 12 years ago

Looks pretty open to me:

here's the current bleeding edge: https://code.google.com/p/go/source/browse

here's the issue tracker: https://code.google.com/p/go/issues/list

looks like it's being used by the dev team.

If you would like to fork the golang project, run this command:

  hg clone https://code.google.com/p/go

This is pretty clearly not Android.

ansible• 12 years ago

Note also that Googlers have stated that they use the public version like everyone else.

dilap2• 12 years ago

I'm curious as to how they did a line-by-line port of the twisted program -- twisted's async (plus coroutines-light w/ via generators) seems like a significantly different model than goroutines + channels. I wonder if they actually implemented Deferred in Go?

jtolds26• 12 years ago

We implemented a future class that had very similar functionality to a deferred. We used goroutines heavily but channels not so much.

I suspect we can improve go runtime scheduler performance by starting to go through and replace pieces with channels where appropriate.

adem• 12 years ago

"So in the bottom of the ninth, we decided to transliterate our 90k lines of Python directly to Go, line by line."

A question here: Is it always a practical approach to transliterate line by line when transitioning to another language or because "Go [is] semantically very similar to Python"?

avenger123• 12 years ago

Usually it's too much work to do a refactor with the new language and a conversion.

Much easier to convert first (with whatever warts the existing code base has) then do a refactor.

So I doubt their approach had too much to do with Go per se and more with wanting to get something out sooner rather than later.

kazagistar3• 12 years ago

Both language semantics and language best practices are pretty similar in Python and Go, and I am sure this helps a lot. Transliterating to something like Java would be hard because their interfaces work differently enough from duck typing to force a lot of refactoring. And switching to something even more different, like Haskell or Clojure, would just make transliteration impossible.

saurik• 12 years ago

I once consulted for a company whose previous consultant had tried to help them do a line-for-line translation (using off-site random-people-in-a-sweatshop online programmers for hire) from ASP to Rails. They pitched it as "transcoding". I will argue that this was not practical (though I can appreciate the idea that at first glance it almost sounds amazingly scalable ;P).

TD-Linux• 12 years ago

I wrote some Python to run on an OpenWRT (MIPS-based, 400MHz) router that interfaced with an Xbee radio and ran a web interface. I quickly discovered that what I expected to be IO-bound was in fact CPU-bound - reformatting the data and all the related text operations were fast enough after optimization, but only by a hair.

Our solution was to switch to a dedicated ARM board (beaglebone) attached to the router. But I'm definitely going to take a look at using a compiled language now, as the codebase is still very small.

cgag• 12 years ago

I like seeing people embrace static typing, but it makes me sad that it's a language where you can't even write a container (a map/dictionry/linked-list/etc) without giving up type safety.

I recognize that Golang is filling a gap, letting people get static typing without having to learn much new stuff, and there's value in that, but I think Go enthusiasts should read these great posts by Tikhon Jelvis with an open mind:

https://www.quora.com/Googles-programming-language-Go-seems-...

https://www.quora.com/Go-programming-language/Do-you-feel-th...

burntsushi2• 12 years ago

Quite frankly, those articles are absolutely terrible. Firstly, it's clear that the author assumes there exists some correct way to design a language. (I reject that.) Secondly, the author never acknowledges any of the trade offs that come from adding additional features to a language. (Hint: one of those trade offs is... there are more features!)

This isn't a revolutionary thought. More compile time safety generally means more complexity in the type system. We, as programmers, must decide when, where and how much we're willing to pay for that type safety.

You can go balls-to-the-wall with Idris or Agda or ATS and encode a whole mess of things directly into your types. Maybe you can completely remove out-of-bounds errors! Surely, this is better than the alternative, which admits less safety.

This isn't a fair comparison because all three of those languages are ridiculously hard to use for practical things. (Well, it's hard for me, anyway.)

Then there are other, more practical languages like Rust, Java, Haskell, OCaml, etc., that all provide a helluva lot more compile time type safety than Go does. (Or, to be precise, a lot more expressive power with respect to compile time safe polymorphism.) Some of the languages go even further; Rust eliminates data races and Haskell isolates "side effects" with monads.

All of these things are wonderful, because we get a lot more guarantees about ways in which our program cannot fail once it's compiled. But they aren't free. They come with a cost. Typically the cost is in greater language complexity. The programmer must write code that the compiler accepts. If you're in that language's wheelhouse, maybe the complexity isn't so bad. But when you want to write a program that isn't easily accepted by the compiler, you run into complexity. Maybe it's not that bad---maybe you just need to figure out how to write a monad transformer. Or maybe you just need to think a bit more carefully about the lifetime of a borrowed pointer. But other times, you need type families and multi-parameter type classes before you can make an unboxed vector with your own type: http://hackage.haskell.org/package/vector-0.10.9.1/docs/Data... --- The safety is great, but dammit, you're going to pay for it.

On some days and for some projects, I'm more than happy to pay the price for safety. It is immensely satisfying to write a program and be able to make all sorts of claims about its safety. (I just wrote a regexp implementation in Rust. Guaranteed no memory errors. No GC. Totally type safe. It's awesome.) But other times, I don't feel like paying the cost.

And that's OK. It's not sad. It's not "ugly." It's a legitimate and reasonable choice given a trade off.

Saying a language is "badly designed" just because it didn't include your preferred set of features is bad juju IMO.

fauigerzigerk• 12 years ago

I agree with much of what you said, but an expressive type system isn't just a safety mechanism. It's also a tool to write fast code productively. Without compile time metaprogramming some things will always be either extremely resource hungry or extremely repetitive.

It's absolutely true that there is always a trade-off. Metaprogramming makes code more difficult to understand and hence more prone to certain types of errors. That's true for runtime metaprogramming as well though.

So if the lack of generics leads to an overuse of reflection (or worse to custom code generators) then the complexity you avoided in the language is re-introduced through the backdoor.

At the end of the day I think it's about the culture that gets established around a language. Go's creators are trying really hard to socially engineer a culture of simplicity, and that's laudable. But it reminds me of the early days of Java even though the Go community would rather have me think of C.

The big difference: C had compile time metaprogramming from the beginning, Java did not. Look which one turned out to be the simpler ecosystem in the end.

zurn• 12 years ago

you can't even write a container (a map/dictionry/linked-list/etc) without giving up type safety

Nit: they're typesafe (when done using interfaces), just not statically so.

dekhn4• 12 years ago

One thing to mention, since the OP talks about developing for ARM:

I was surprised recently: first that Go itself bundles a cross compiler (you can easily download Go on x86 and compile ARM binaries with it), second that this made developing for Raspberry Pi and similar platforms very productive, and third that many Linux distributions have QEMU and set up binfmt translation so ARM-compiled binaries run on x86 with no extra effort.

jtolds26• 12 years ago

The qemu binfmt extensions inside a chroot are so great.

For the uninitiated: https://wiki.debian.org/EmDebian/CrossDebootstrap#QEMU.2Fdeb...

azth4• 12 years ago

provided that your problems are not algorithmic complexity

What does that even mean?

gjm112• 12 years ago

It means "provided the reason your code is too slow isn't that its performance scales very badly as a function of a parameter that, in practice, is not small".

If your code takes time proportional to 2^2^n then for n=4 that's 2^16 x constant, which is probably fine for any reasonable constant, and for n=6 that's 2^64 x constant, which is probably too much for any reasonable constant, so if you're running into problems with n>=6 then moving to a different language or faster hardware or more-micro-optimized code is not going to help you.

On the other hand, if your code takes time of order n^2 and typical values of n are in the thousands or millions, then the difference between C and Python, or Core i7 and Z80, or sloppily written code and highly-bummed code with an inner loop in hand-tuned assembler, may make a big difference.

azth4• 12 years ago

Thanks for the explanation. I am aware of that; however, the sentence I quoted does not make sense grammatically; "algorithmic complexity" is not an adjective.

azth4• 12 years ago

Was the CPU pegged at 100% when using Python then?

jtolds26• 12 years ago

yep

aet• 12 years ago

Can someone explain why SpaceMonkey is better than Dropbox?

jtolds26• 12 years ago

Space Monkey is cheaper for more space - $49/yr for 1TB. Further, because there's a device in your home, getting your data synced off your laptop is a much faster process - you aren't bottlenecked by whatever Dropbox is throttling your upstream at. Not to mention all of the DLNA, Samba, home media system integration we're working on.

shiven• 12 years ago

And lack of oligarchs, who signed-off on torture, on the company board.

Now that can't be a bad thing! SpaceMonkey needs to use it as a selling point.

ternaryoperator• 12 years ago

It would be good if you explained this more on your site. I couldn't figure out what the device was for, nor whether it was required, etc. I'd suggest a home page that clearly explains what you do and how it works. It's also not clear what happens price-wise after the first year. Is there some fee to pay for the device or just the $49/yr for the storage? Etc.

bsder• 12 years ago

Why not just bump your processing power?

No offense, but that was a hideous amount of effort for just 20% in one area. An extra dollar or two spent on a hardware upgrade wins for everything.

azatris• 12 years ago

What are the disadvantages of using Go instead of Python?

NateDad3• 12 years ago

Testing can be more difficult in some cases, if you haven't carefully structured your code. In python you can always monkey patch whatever outside dependencies you have, whereas in Go, you can't do that without structuring your code to allow it. Careful use of interfaces and dependency injection can let you do it, but if you don't know to use that style, you can get big blocks of code that become hard to test because they expect the whole operating environment to exist, which may be hard to do during testing.

If you want to write code in a Domain Specific Language (even if that domain is "math"), it's nearly impossible in Go. You can't do operator overloading or all the really crazy hacking on the functionality of basic parts of the language to make it work in fundamentally different ways (the way you can with numpy etc). Go will always look like types, functions, and methods.

Right now, Go has no user-defined generics.. this is actually not a problem for many projects, but if you happen to need a lot of specialized containers for different types (like red black trees, graphs, etc), then it can be a barrier. There are ways around it, probably the best way is just code generation to duplicate the container code per type that you need. The other option is just using interface{}, which is basically void* or "Object" for Go, and casting in and out of it... but that can be slow.

There's probably some stuff I'm missing, but those are the major points that I can think of.

jtolds26• 12 years ago

My guess is that if you've written code that's hard to test in Go, it's going to be hard to write good, non-brittle tests in Python. It's not so much that you need to write code amenable to dependency-injection to write good tests, you just need to write modular code.

As a fan of DSLs, I actually do appreciate how easy it is to understand any Go that anyone has written, since there aren't any cutesy DSL tricks anywhere. So, yeah, it's hard/impossible to do DSLs, but that might not be a Bad Thing.

Generics is a (frequently discussed) downside. It's definitely a tradeoff. For every container type we had, we had to make a copy of it or a typesafe wrapper around it for every possible instantiation of the container with different types. If you're used to coding by making flexible containers and so on, that's definitely much more brittle and challenging in Go. Go peeps will tell you that's part of a tradeoff they're willing to take.

Space Monkey dumps Python for Go

Related Stories