13 ms·

Things from Python I'd miss in Go

128 points by smackay 12y ago

deleted 12y ago
[deleted]
jgrahamc 12y ago
Towards the end of the article there seems to be a confusion between servers and web servers. Yes, Go is nice for writing servers, no, web servers aren't the only things out there doing 'serving' in systems-land. Three examples from CloudFlare all written in Go: 1. Our Internet compression/optimization technology called Railgun 2. Our DNS server 3. Our CA infrastructure All are networked, all are highly concurrent. Also, our entire logging and analysis infrastructure is being migrated to Go. PS Forgot that we also recently rewrote the code that does image compression (using C tools) in Go as well. Here the Go code is working as a job server.
- ironchef 12y ago
  "Also, our entire logging and analysis infrastructure is being migrated to Go." This intrigues me. I've been moving a lot of ETL into Go (as it's pretty well suited to this), but I still end up doing a lot of the analytics in Spark (for bigger work) or Pandas or R (for smaller bits of data). What are you guys planning on doing for the analytics? Or is it more of straight up time series work (so you can use influx + whatever). Just curious and keep up the good work :)
  - jgrahamc 12y ago
    Since I'm not actually involved in that project I'm going to defer answering until we write a detailed blog post. Also, if you are interested in a job...
  - voidlogic 12y ago
    "Also, our entire logging and analysis infrastructure is being migrated to Go." This intrigues me.... Go is great for this kind of stuff. Spark is great when you have a lot of custom queries, but if you have a few fixed queries writing a simple solution in Go have have huge gains. I worked to implement a web service + simple map reduce (with network transparency) + a time series DB (storage engine too, NOT using levelDB like influx) all in Go and the result was it is many times faster than an order of magnitude larger hadoop cluster, BigQuery, etc for the limited operations it supports.
    - jobquestion123 12y ago
      Did you use a framework to run mapreduce with go or did you roll your own?
      - voidlogic 12y ago
        We wrote our own, Go 1.0 had just come out.
- alfor 12y ago
  It seems that you have the canonical type of use case for Go. Server systems for thousands of customer and huge number of requests. Python became a jack of all trade where concurrency and performance is not the main focus.
- dubcanada 12y ago
  Is the Lua stuff going away? What are your opinions of Go vs Lua?
  - deleted 12y ago
    [deleted]
  - jgrahamc 12y ago
    Nope. No need to throw away the Lua. We're moving more and more to a combination of C-based (nginx) for core serving, Lua-based for logic and Go for services.
- jamra 12y ago
  It looks like the author found the worst use case for Go in comparison to a library that Python absolutely soars in and uses that as a basis for this argument. Go does not have something as nice as numpy. For numeric computing, by all means use Python. He then makes some crazy statements about operator overloading as if that is the essence of a good language. I disagree. I don't want operator overloading. I almost never used operator overloading in C# or Java. Maybe that's just me, but it's certainly not a reason to avoid a language. The crux of his argument is that C++ users who switched to Java years ago are the types of programmers that Go wished to convert. He neglects to mention deployment. He neglects to mention stability in runtime. He neglects to mention any low level meddling that you have to do in compression. The examples you posted are exactly the kind of things that Go soars in. It's very convenient to leave them out while beating your chest about how your language is a superior language because it is superior in a very specific niche.
  - S4M 12y ago
    > I almost never used operator overloading in C# or Java. Dude, you can't overload operators in Java. You can overload methods of a class, but not operators. Operator overloading means that you can overload '+' for example for your particular class, which would enable you to write code like (in Java): Matrix a = zeroMatrix(4,4); Matrix b = identityMatrix(4,4); Matrix c = a+b; You can't do that, so you would have to write: Matrix c= a.add(b); Which makes your code verbose and makes Java (and Go) painful for doing numerical analysis.
    - nordsieck 12y ago
      It's important to note that numerical calculation is a domain particularly suited to operator overloading simply because the underlying domain (math) already uses operator overloading heavily (e.g. multiplication means something different when done on scalars and vectors, but in both cases it is well defined and in common usage).
      - Someone 12y ago
        You should leave out the 'overloading': - Math (and it's very close relative logic) are the only domains that use operators, period. - other domains use overloading; homonyms are very common.
Kurtz79 12y ago
Sometimes we get so invested in a language that we forget that it's just a tool, and a good engineer/hacker should try to choose the best one for the problem at hand. Go is just another tool in our toolbox: as the author says it sacrifices some of Python's friendliness and ease of use (but not as much as other compiled/statically typed languages) and features for performance and a solid concurrency model. It's up to us to decide what the best fit for our applications is. Even if Go it's definitely not "The Language to rule them all", it's nice to have more options.
- klibertp 12y ago
  I try to advocate polyglot programming - using the best tool for the job - everywhere I go, but unfortunately people are largely allergic to the idea. Most programmers don't want to learn new tools, much less new paradigms or methodologies. Even worse, the management agrees - the upside of building better systems isn't convincing enough to justify a temporary drop in performance while learning. More to the point, I don't understand why the OP wrote this article in the first place. It's obvious that Go is not designed to support his use-cases and that's really all there is to it. Listing reasons why Go is bad at doing things it wasn't meant to do seems a bit pointless to me. It's like bashing a screwdriver for how bad a hammer it makes...
  - swasheck 12y ago
    Though I agree with, the primary argument that I've heard has always been that fragmentation/heterogenous systems in a corporate infrastructure make the human and capital management more of a nightmare.
    - Derbasti 12y ago
      It's corporate infrastructure that is the nightmare, not the fragmentation.
  - gejjaxxita 12y ago
    The drop in performance isn't just while learning. I worked somewhere where I had to regularly use TCL, Java, PHP, C++ and Python - each was the most suitable tool for the job (at the time the tool was written anyway) but the constant context switching caused a real and permanent performance hit.
nkozyra 12y ago
The error handling one is an area I've never understood - in a well-designed Go app errors will be returned from functions/methods and you'll either deal with them or not _/err. I love try/catch/finally but I fail to see how doing either a _ or writing a simple log function to do something with returned errors necessarily represents "more code" than handling exceptions.
- drdaeman 12y ago
  That creates some mostly unnecessary boilerplate. I.e., if an error happens down the stack in function to read config, which calls a function to parse a file, which calls a function to read a file, you'll have to either propagate (or otherwise handle) that `err` manually or lose the precious information. On the contrary, Java-like pattern of functions like `Config readConfig() throws IOError, ParseError` simplifies code quite a bit. No need to deal with IOError in parseConfig - if an exception happens there it'll be propagated automatically. And `throws` clause allows for static checking and warning whenever you forgot to handle something. And sane code analysis tools would also warn you whenever you really wanted overly-broad `catch Exception(e)`, too. There's a panic/recover in Go, but they aren't serious. At least, to my limited knowledge of Go, there are no guidelines on using them properly, so everyone panics with whatever they fancy, and this lack of conventions is a bit problematic, like `raise "Failed to open file"` in Python.
  - RBerenguel 12y ago
    The standard is usually if err != nil { return (whatever null type), err } The error will propagate up, since all calls to a function returning err should be checking for the err. In a not-so-ideal world, just return err up. In a relatively more sane world, you can send "up" extra information along the error (just creating a new error with extra info) to know the error path. The first caller will/should handle this error then.
  - moreentropy 12y ago
    OTOH, if you follow Go's idioms and handle every error where it happens, your code will look like having a lot of boilerplate at first, but you end up with better error handling. It's the same as putting a try-except catchall around every single call in python, because in python you can never be sure (without reading the source) what kind of exceptions something will throw. For request based services and something where some big ass operation will either fail in some way (and i don't care where exactly) or be successful, exceptions are fine. If something goes wrong somewhere, log it and reply with HTTP 500. But for servers with data i care about, i most likely want to recover right where the error happened, and actively decide if i want to abort and push the error to the next layer. Not having exceptions makes this more intuitive.
Goranek 12y ago
In the beginning i missed repl, but i've realised using repl in the first place was a mistake.. Now i rely on docs(godoc is awesome) and when i need to test something i use go playground.
- yonaguska 12y ago
  Could you elaborate on why using the repl was a mistake? I don't really miss python's repl, but coming from the Lisp repl, the playground doesn't seem to cut it. Now, if anyone has written an emacs mode that lets you interact with the playground by loading a buffer- I think I'd be much happier.
  - Rapzid 12y ago
    The repl/insta-repl in LightTable was amazing to me. Particularly what you could do with clojure-script when it was hooked up to the browser.
  - Goranek 12y ago
    Instead of going through the docs and code i used dir function inside repl to figure out what to do, how something works and so on.
- phazmatis 12y ago
  The REPL is part of my TDD loop... Which is actually, write a test, come up with a plan to make it pass, google for the programming constructs I need in the language I'm using, test a snippet (or a fully functional line) in the REPL, copy over to my project, make the test pass, ..(refactor). Without the REPL I would have an extra cognitive overhead of wondering if I had introduced a bug through misunderstanding a sketchy part of the docs.
- niemeyer 12y ago
  I missed a REPL at first too, which made me play a bit with REPL-for-Go ideas, but that didn't end up on anything really convenient. What solved the problem was rethinking why the REPL was convenient in the first place, leading to the creation of hsandbox: http://labix.org/hsandbox http://labix.org/hsandbox Despite it being created for Go, I got quite fond of the approach. Nowadays I also use it for Python, C, etc.
ant_sz 12y ago
As for the GUI problem mentioned in the article, we now have https://github.com/andlabs/ui https://github.com/andlabs/ui I haven't yet tried this lib, It may not as good as something as Qt, but I think it is a good beginning.
- 0x006A 12y ago
  first thing it mentions in the readme: this package is very much incomplete
- dubcanada 12y ago
  I played around with it, it is nowhere near Qt, not even like 5% close. Qt isn't just a GUI library, it's everything you need to build a application in a nice large bundle. But it's a nice start... However I feel that Go is not really intended to be used for desktop applications, I would much rather see a Rust GUI library.
- rogerdpack 12y ago
  Yeah he says "Go's Qt bindings are 'not recommended for any real use'" but he is only linking to a 3rd party library that's [apparently] not ready for real use--I guess he could "there are not yet good Go bindings for Qt", or "the GUI toolkits are less developed than Python's" or "Go has no built in GUI but python does (tkinter)" [does anybody use tkinger anyway?]. Another thing that confuses me here is that he's saying "here are things I think I'd miss if I moved from Python to Go" without ever having done it to see if he actually misses them...[once more familiar with Go, he may end up not missing them as much as he anticipated]. Curiously absent also is a mention of significant whitespace, perhaps he wouldn't miss it? :)
atilaneves 12y ago
I've been waiting for someone to weigh in on this from the Python side for a while now. I'm a C++ and Python programmer (amongst other things) and I can't ever see myself switching to Go. I'd sooner switch to Rust or Swift, but D has been my favourite language by far since I picked it up last year. I actually don't understand why, in the absence of niche use-cases, how and why Python programmer would write Go code and _like_ it. Are these Python coders who've never heard of itertools??
- drdaeman 12y ago
  There are some Python programmers who sometimes regret Python doesn't have some static typing. Go has that and also provides an easy way to be quite dynamic when that's wished for (or even when not - without generics one'll have to resort to `interface{}` even if that's not desired, huh).
- sergiosgc 12y ago
  From what I understand, Go is an opinionated language, with a nice concurrency framework. It's not groundbreaking, it's not particularly expressive or adapted to any specific use case. It so happens that if your style fits Go's ideology (opinionated view), you become a fan. For me, the lack of exceptions kills the language. C-like error testing smells like a twenty year de-evolution. I also dislike the flat object model, but could force myself to live with it for the sake of trying composition over inheritance. Error returning, however, is taking the ideology too far.
  - niemeyer 12y ago
    You are assuming the use of exceptions is an evolution in the first place, but that's far from being a consensus. To some of us, exceptions are very convenient, but more easily lead to brittle software. I wrote a little bit about that before. Probably won't help you much, except perhaps in acknowledging that there's a different angle to that which some people may care about. http://blog.labix.org/2013/04/23/exceptional-crashes http://blog.labix.org/2013/04/23/exceptional-crashes
    - 12y ago
gbog 12y ago
When I read go specs or go vs python comparison, nearly every diff is a specific pain point of our big python code base. No keyword argument? to hell with them. Strict formatting? That should be in python interpreter. No unused import: would have saved our lives. No cyclic dependencies? No inheritance? No exceptions? Great, all of them are maintenance nightmares.
- mercurial 12y ago
  What's your issue with keyword arguments, apart from magic args/*kwargs? They're quite convenient. As for exceptions, the problem with Python is more that the exceptions are unchecked than exceptions in general.
- smnrchrds 12y ago
  Can you please elaborate. I don't understand what could be wrong with keyword arguments. Also I can't see how an unused import can waste a life, unless there is some lethal side-effect to importing that package (I don't like import side-effects, but they are inconvenient whether the import is used or unused). Exceptions seem pretty useful as well.
  - gbog 12y ago
    Python's keyword arguments: def f(a, b=1, c=2): pass Now, same call can be written `f(0, 1, 2)` and `f(0, b=2, a=1)`, which makes it much harder to refactor. For instance, suppose you want to add a non-keyword argument, you'll have to carefully grep for all calls. I think functions should be either full keyword arguments and naming them in calls should be mandatory. Or no keyword arguments at all. The mixing of both is "convenient" for prototyping, but has a high long-term cost. Unused imports: In a module bar, you have `import foo`. How do you know if it is used or not? You'll have to scan all modules importing bar to check if they import foo. Granted, the problem is not that import foo is unused, but that it is imported in bar's namespace. Exceptions make it hard to follow code paths and easy to hide important events. The hardest debugs I've endured are because of exceptions. An innocent looking `except AttributeError` can be hiding a deep issue in some remote library playing badly with getattr magic. That said, I love Python, and still think it is the most elegant language. I will most certainly teach Python to my kid when he'll be old enough. I also believe it is best suited for a full serie of programming tasks. But, when code base grow in size and complexity, some of its "tolerance" become a burden.
baldfat 12y ago
There is no one best language. Numpy is not something Go is going to do (Correct em if I am wrong). Julia would be the faster language to switch to, but personally I switched from Python to R due to the fact that I like languages that are made for what I am doing. Python always feels second best to whatever I am doing and I have branched away from Python. So R for statistics is great for me.
- howeman 12y ago
  Besides operator overloading, why can't Go do Numpy?
rogerdpack 12y ago
Did he say that people looking for faster build times than C++ went to java? They may not have found what they were looking for, in that case... Go does lack a quality [IMO] IDE [re: REPL use is for development], but that can still come with time. Quality GUI bindings can also come with time [how often do you actually use Python for GUI stuff, though...but still nice to have, just not its major use I doubt] Another thing you'll miss from Python is accidentally typo'ing variable names and having to discover that only at runtime :) Just my rebuttal :)
- pjc50 12y ago
  Java is faster to build than C++ almost all of the time. Header files (especially with templates) tend to turn C++ in to an O(n^2) run time, often running into hours.
  - rogerdpack 12y ago
    OK, the only thing I can compare it against is my current "java" build times, and I can tell you that using maven is somewhat slow. So I guess you could say that if people went to java from c++ for the improved build times, they might still be interested in Go for the same improvement over java :)
- kyllo 12y ago
  Another thing you'll miss from Python is accidentally typo'ing variable names and having to discover that only at runtime :) python -m compileall . :)
  - rogerdpack 12y ago
    I was referring to typo'ing for instance assignment (perhaps you were as well?) a = 3 if true: a2 = 4 # lame I know--but beginners like me do it --Python lets discover your failure at runtime...[as a good dynamic typed language does--Go doesn't FWIW]. It was just from an experience I had with learning Python recently. Now it makes me wonder what his blog post would look like saying things he'd miss going from Go to Python, or "what I wouldn't miss from Python..."
adwn 12y ago
It's ironic that the author dismisses C++ to a small niche: > Those who still stick to C++, after all these years, either really can't live with the "overheads" (real time apps - those are waiting for Rust to mature), or think they can't (and nothing will convince them except a competitor eventually forcing their employer out of business). Yet later he gives a good example for an important area where C++ is still unbeaten: scientific computing libraries. If you want/need maximum performance, then right now, there's no other language that has no overhead and zero-cost abstractions (to the degree that C++, especially C++11, has them). Hopefully Rust will get there eventually, but as of today, you have three choices: Fortran, C, and C++ – and neither C nor Fortran offer any abstractions worth mentioning.
- Touche 12y ago
  I don't understand your complaint, isn't "scientific computing libraries" a niche?
  - adwn 12y ago
    > isn't "scientific computing libraries" a niche In a way, yes. The point I'm trying to make is that there are many niches that require the performance of C++ [1], while the author implied that there's just a single one. Sorry, I should have been clearer on that. [1] If you're not convinced, I can give you a lot more examples.
- fulafel 12y ago
  Zero-cost abstractions come at a pretty hefty price if you pick C++. The cost is in programmer productivity & quality of resulting software. I'm sure there are some fields of academia where this is a reasonable tradeoff (if you're programming DSP algorithms running on a embedded battery powered device strapped to a dolphin, say...) but your generic number crunching job rarely calls for it. (As an aside, zero-overhead abstractions being unique to C++ doesn't sound right to me. Then again I haven't heard the term used outside C++ circles and its meaning is nebulous, so maybe it's just a name for C++'s tradeoffs?)
  - 12y ago
ChikkaChiChi 12y ago
The argument "would have switched to X before" seems to not consider the possibility of new adoptions. If I didn't need the things that Go provides before, that does not mean I do not need them today or tomorrow.
pothibo 12y ago
Most of the GUIs are done on a main thread which makes some of Go's advantages unneeded. Don't build GUI in Go, ever. Error handling is a way of thinking: TDD is one, Go's approach is another. REPL is not a must, environment without REPL means you have to think more about what you want. It's a process. You should be able to read source code and figure out how things work. Like many mentioned here, Go is great at doing system stuff, like background queues and processing. Stay with Python until you need to get thing faster, then move them to Go. That's how you should think of it.
higherpurpose 12y ago
He forgot the part about Go also being a great replacement for Java, for those who don't like Java.
hellbreakslose 12y ago
Go is Googles C#, I see good use on it, and it will evolve a lot more in the next few years.
dragonwriter 12y ago
> No exceptions [...] If I want higher-level error context I need to propagate the error upwards, with an if at every function call along the way. This is flat out false. Go has fairly standard exceptions (panics), though instead of using try/catch/finally blocks it uses deferred functions that perform a hybrid of the "catch" (if they use "recover") and "finally" functionality. It is a go convention that library code doesn't let panics escape to the calling code, so if you are going to use panics in your own code, to follow the convention you should be recovering from them somewhere in the call chain that you control rather than letting them escape across the public API of your code. But that's it, they exist, and can be used. So, while there may be some ground to complain that when calling the standard library you have to handle error returns rather than catching exceptions (equivalently, "recovering from panics") -- though, IMO, there is a good reason for this design choice -- there is absolutely no reason, aside from sheer ignorance and not reading even the most basic Go documentation -- to say that you don't have exceptions that you can use within your own code and that you have to to error-return handling at every level in your own code to deal with error propagation. If you make that complaint, it is clear you don't know what you are talking about.
- deleted 12y ago
  [deleted]
  - dragonwriter 12y ago
    I'm not objecting to you choosing not learn something in depth because you don't like how it looks on the surface (that's a rational approach to avoiding wasting time, which is a valuable resource), I'm objecting to you, in the linked article, commenting in depth (and inaccurately) on something its clear that you decided not to learn in depth because you didn't like how it looks on the surface. The statement that Go has "no exceptions", or that for deep error handling in your own code you have to handle errors at each level is false. And, fine, you didn't learn anything about it because maybe you saw sample code showing how you need to deal with the public API of common libraries because of the Go convention that panics aren't exposed across public APIs. And if all you said was that, it'd be fine -- but you went beyond that and said things that weren't true and which people who haven't learned the language might not realize were statements from ignorance rather than experience, and might turn them off of the language where they wouldn't be turned off if they knew the truth, because if they were true, they'd be real and deep problems with the language design. Choosing to remain ignorant about Go because it doesn't seem like its worth your time to learn is fine. Making up stories about why you don't like Go that aren't grounded in anything real is not. TL;DR: if you choose to be ignorant, you don't get to pretend to be an authority.
rakoo 12y ago
I think the author misses the point. The number one reason Go was created was to build maintainable softwares, the kind Google uses at large. The easiest way to build these are: - Automatic memory management -> GC - Bug catching before the software is run -> Static typing - Overall simplicity -> few features, added only if it is extremely needed The thing is, when you start using Go, you already know its features. There is nothing particularly new, and it all fits in your head. It is a bit strict though, so there is some boilerplate (error checking, sort.Sort, ...) but that's going to save you when you edit your software in 5 years. Here, performance (both compilation and running) is a byproduct of simplicity. Now, I'm not saying the OP's use cases are invalid, far from it; they're just not what was intended in the process of creating Go. Like OP, I tend to think that Go is the new Java: "boring" (ie no revolutionary features) but it just works for server-side softwares.
- _yosefk 12y ago
  Why do I miss the point if, like me, you think Go is the new Java? :-) I think it's exactly that, it works and that's fine, and why the JVM doesn't do cheap concurrency I don't know. If it did Java might have been the new Java :-)
  - rakoo 12y ago
    I was referring to these: > What does Go have that C++ lacks? Mandatory garbage collection, memory safety, reflection, faster build times, modest runtime overhead. > If on the other hand most code in most websites matters a lot for performance, then maybe you want Go Specifically, seeing only the features (performance) and not the intent in Go. I should have said "misses the point in why Go can be more interesting than other languages". Now, as you said, if your requirements can't be fullfilled by Go (or any blub), then it's not worth switching. > If it did Java might have been the new Java :-) I don't think people avoid Java because of the lack of light concurrency (there are multiple production-ready libraries to do that). I think people avoid it because of Java-the-platform... so Java would have stayed the bloated Java :-)
  - deleted 12y ago
    [deleted]
hellbreakslose 12y ago
I think on his point why Python Devs move from Python to Go, Its cause of the current version changes between Python 2 and 3.
micro_cam 12y ago
So I do a lot of scientific programing in go [1]. I am absolutely still using python + numpy/scipy/pyamg for linear algebra heavy stuff but this has more to do with the available and well documented packages then operator overloading. I actually find that the interfaces used for math [2] encourage a more memory efficient coding style. Without operator overloading I'm less tempted to jam everything into a pretty one liner and more likely to set things up to work with out unintended reallocations. Lack of efficient generics is a much bigger annoyance. [1] See for example my random forest package https://github.com/ryanbressler/CloudForest https://github.com/ryanbressler/CloudForest [2] See package big for example http://golang.org/pkg/math/big/ http://golang.org/pkg/math/big/
howeman 12y ago
As of at least a year ago, their are bindings for the BLAS library of your choice (github.com/gonum/blas), which are used in many parts of the matrix package (github.com/gonum/matrix/mat64). As of a week ago, there are bindings for the Lapack implementation of your choice (github.com/gonum/lapack). These have not yet been worked in with matrix, but will be eventually (PR welcome!).
- howeman 12y ago
  Not to mention there's 2/3rds of a go BLAS implementation (benchmarks https://groups.google.com/forum/#!msg/gonum-dev/Cqa41tbUUCw/EuTBQFBhod0J https://groups.google.com/forum/#!msg/gonum-dev/Cqa41tbUUCw/...). Level 3 routines are much harder to make efficient (people are still researching efficient matrix multiply)
mimighost 12y ago
Go could take a bite from Python in web development area, but scientific computing...No chance

128 points by smackay 12y ago

deleted 12y ago

[deleted]

Towards the end of the article there seems to be a confusion between servers and web servers. Yes, Go is nice for writing servers, no, web servers aren't the only things out there doing 'serving' in systems-land. Three examples from CloudFlare all written in Go: 1. Our Internet compression/optimization technology called Railgun 2. Our DNS server 3. Our CA infrastructure All are networked, all are highly concurrent. Also, our entire logging and analysis infrastructure is being migrated to Go. PS Forgot that we also recently rewrote the code that does image compression (using C tools) in Go as well. Here the Go code is working as a job server.

ironchef 12y ago
"Also, our entire logging and analysis infrastructure is being migrated to Go." This intrigues me. I've been moving a lot of ETL into Go (as it's pretty well suited to this), but I still end up doing a lot of the analytics in Spark (for bigger work) or Pandas or R (for smaller bits of data). What are you guys planning on doing for the analytics? Or is it more of straight up time series work (so you can use influx + whatever). Just curious and keep up the good work :)
- jgrahamc 12y ago
  Since I'm not actually involved in that project I'm going to defer answering until we write a detailed blog post. Also, if you are interested in a job...
- voidlogic 12y ago
  "Also, our entire logging and analysis infrastructure is being migrated to Go." This intrigues me.... Go is great for this kind of stuff. Spark is great when you have a lot of custom queries, but if you have a few fixed queries writing a simple solution in Go have have huge gains. I worked to implement a web service + simple map reduce (with network transparency) + a time series DB (storage engine too, NOT using levelDB like influx) all in Go and the result was it is many times faster than an order of magnitude larger hadoop cluster, BigQuery, etc for the limited operations it supports.
  - jobquestion123 12y ago
    Did you use a framework to run mapreduce with go or did you roll your own?
    - voidlogic 12y ago
      We wrote our own, Go 1.0 had just come out.
alfor 12y ago
It seems that you have the canonical type of use case for Go. Server systems for thousands of customer and huge number of requests. Python became a jack of all trade where concurrency and performance is not the main focus.
dubcanada 12y ago
Is the Lua stuff going away? What are your opinions of Go vs Lua?
- deleted 12y ago
  [deleted]
- jgrahamc 12y ago
  Nope. No need to throw away the Lua. We're moving more and more to a combination of C-based (nginx) for core serving, Lua-based for logic and Go for services.
jamra 12y ago
It looks like the author found the worst use case for Go in comparison to a library that Python absolutely soars in and uses that as a basis for this argument. Go does not have something as nice as numpy. For numeric computing, by all means use Python. He then makes some crazy statements about operator overloading as if that is the essence of a good language. I disagree. I don't want operator overloading. I almost never used operator overloading in C# or Java. Maybe that's just me, but it's certainly not a reason to avoid a language. The crux of his argument is that C++ users who switched to Java years ago are the types of programmers that Go wished to convert. He neglects to mention deployment. He neglects to mention stability in runtime. He neglects to mention any low level meddling that you have to do in compression. The examples you posted are exactly the kind of things that Go soars in. It's very convenient to leave them out while beating your chest about how your language is a superior language because it is superior in a very specific niche.
- S4M 12y ago
  > I almost never used operator overloading in C# or Java. Dude, you can't overload operators in Java. You can overload methods of a class, but not operators. Operator overloading means that you can overload '+' for example for your particular class, which would enable you to write code like (in Java): Matrix a = zeroMatrix(4,4); Matrix b = identityMatrix(4,4); Matrix c = a+b; You can't do that, so you would have to write: Matrix c= a.add(b); Which makes your code verbose and makes Java (and Go) painful for doing numerical analysis.
  - nordsieck 12y ago
    It's important to note that numerical calculation is a domain particularly suited to operator overloading simply because the underlying domain (math) already uses operator overloading heavily (e.g. multiplication means something different when done on scalars and vectors, but in both cases it is well defined and in common usage).
    - Someone 12y ago
      You should leave out the 'overloading': - Math (and it's very close relative logic) are the only domains that use operators, period. - other domains use overloading; homonyms are very common.

Kurtz79 12y ago

Sometimes we get so invested in a language that we forget that it's just a tool, and a good engineer/hacker should try to choose the best one for the problem at hand. Go is just another tool in our toolbox: as the author says it sacrifices some of Python's friendliness and ease of use (but not as much as other compiled/statically typed languages) and features for performance and a solid concurrency model. It's up to us to decide what the best fit for our applications is. Even if Go it's definitely not "The Language to rule them all", it's nice to have more options.

klibertp 12y ago
I try to advocate polyglot programming - using the best tool for the job - everywhere I go, but unfortunately people are largely allergic to the idea. Most programmers don't want to learn new tools, much less new paradigms or methodologies. Even worse, the management agrees - the upside of building better systems isn't convincing enough to justify a temporary drop in performance while learning. More to the point, I don't understand why the OP wrote this article in the first place. It's obvious that Go is not designed to support his use-cases and that's really all there is to it. Listing reasons why Go is bad at doing things it wasn't meant to do seems a bit pointless to me. It's like bashing a screwdriver for how bad a hammer it makes...
- swasheck 12y ago
  Though I agree with, the primary argument that I've heard has always been that fragmentation/heterogenous systems in a corporate infrastructure make the human and capital management more of a nightmare.
  - Derbasti 12y ago
    It's corporate infrastructure that is the nightmare, not the fragmentation.
- gejjaxxita 12y ago
  The drop in performance isn't just while learning. I worked somewhere where I had to regularly use TCL, Java, PHP, C++ and Python - each was the most suitable tool for the job (at the time the tool was written anyway) but the constant context switching caused a real and permanent performance hit.

nkozyra 12y ago

The error handling one is an area I've never understood - in a well-designed Go app errors will be returned from functions/methods and you'll either deal with them or not _/err. I love try/catch/finally but I fail to see how doing either a _ or writing a simple log function to do something with returned errors necessarily represents "more code" than handling exceptions.

drdaeman 12y ago
That creates some mostly unnecessary boilerplate. I.e., if an error happens down the stack in function to read config, which calls a function to parse a file, which calls a function to read a file, you'll have to either propagate (or otherwise handle) that `err` manually or lose the precious information. On the contrary, Java-like pattern of functions like `Config readConfig() throws IOError, ParseError` simplifies code quite a bit. No need to deal with IOError in parseConfig - if an exception happens there it'll be propagated automatically. And `throws` clause allows for static checking and warning whenever you forgot to handle something. And sane code analysis tools would also warn you whenever you really wanted overly-broad `catch Exception(e)`, too. There's a panic/recover in Go, but they aren't serious. At least, to my limited knowledge of Go, there are no guidelines on using them properly, so everyone panics with whatever they fancy, and this lack of conventions is a bit problematic, like `raise "Failed to open file"` in Python.
- RBerenguel 12y ago
  The standard is usually if err != nil { return (whatever null type), err } The error will propagate up, since all calls to a function returning err should be checking for the err. In a not-so-ideal world, just return err up. In a relatively more sane world, you can send "up" extra information along the error (just creating a new error with extra info) to know the error path. The first caller will/should handle this error then.
- moreentropy 12y ago
  OTOH, if you follow Go's idioms and handle every error where it happens, your code will look like having a lot of boilerplate at first, but you end up with better error handling. It's the same as putting a try-except catchall around every single call in python, because in python you can never be sure (without reading the source) what kind of exceptions something will throw. For request based services and something where some big ass operation will either fail in some way (and i don't care where exactly) or be successful, exceptions are fine. If something goes wrong somewhere, log it and reply with HTTP 500. But for servers with data i care about, i most likely want to recover right where the error happened, and actively decide if i want to abort and push the error to the next layer. Not having exceptions makes this more intuitive.

Goranek 12y ago

In the beginning i missed repl, but i've realised using repl in the first place was a mistake.. Now i rely on docs(godoc is awesome) and when i need to test something i use go playground.

yonaguska 12y ago
Could you elaborate on why using the repl was a mistake? I don't really miss python's repl, but coming from the Lisp repl, the playground doesn't seem to cut it. Now, if anyone has written an emacs mode that lets you interact with the playground by loading a buffer- I think I'd be much happier.
- Rapzid 12y ago
  The repl/insta-repl in LightTable was amazing to me. Particularly what you could do with clojure-script when it was hooked up to the browser.
- Goranek 12y ago
  Instead of going through the docs and code i used dir function inside repl to figure out what to do, how something works and so on.
phazmatis 12y ago
The REPL is part of my TDD loop... Which is actually, write a test, come up with a plan to make it pass, google for the programming constructs I need in the language I'm using, test a snippet (or a fully functional line) in the REPL, copy over to my project, make the test pass, ..(refactor). Without the REPL I would have an extra cognitive overhead of wondering if I had introduced a bug through misunderstanding a sketchy part of the docs.
niemeyer 12y ago
I missed a REPL at first too, which made me play a bit with REPL-for-Go ideas, but that didn't end up on anything really convenient. What solved the problem was rethinking why the REPL was convenient in the first place, leading to the creation of hsandbox: http://labix.org/hsandbox http://labix.org/hsandbox Despite it being created for Go, I got quite fond of the approach. Nowadays I also use it for Python, C, etc.

ant_sz 12y ago

As for the GUI problem mentioned in the article, we now have https://github.com/andlabs/ui https://github.com/andlabs/ui I haven't yet tried this lib, It may not as good as something as Qt, but I think it is a good beginning.

0x006A 12y ago
first thing it mentions in the readme: this package is very much incomplete
dubcanada 12y ago
I played around with it, it is nowhere near Qt, not even like 5% close. Qt isn't just a GUI library, it's everything you need to build a application in a nice large bundle. But it's a nice start... However I feel that Go is not really intended to be used for desktop applications, I would much rather see a Rust GUI library.
rogerdpack 12y ago
Yeah he says "Go's Qt bindings are 'not recommended for any real use'" but he is only linking to a 3rd party library that's [apparently] not ready for real use--I guess he could "there are not yet good Go bindings for Qt", or "the GUI toolkits are less developed than Python's" or "Go has no built in GUI but python does (tkinter)" [does anybody use tkinger anyway?]. Another thing that confuses me here is that he's saying "here are things I think I'd miss if I moved from Python to Go" without ever having done it to see if he actually misses them...[once more familiar with Go, he may end up not missing them as much as he anticipated]. Curiously absent also is a mention of significant whitespace, perhaps he wouldn't miss it? :)

atilaneves 12y ago

I've been waiting for someone to weigh in on this from the Python side for a while now. I'm a C++ and Python programmer (amongst other things) and I can't ever see myself switching to Go. I'd sooner switch to Rust or Swift, but D has been my favourite language by far since I picked it up last year. I actually don't understand why, in the absence of niche use-cases, how and why Python programmer would write Go code and _like_ it. Are these Python coders who've never heard of itertools??

drdaeman 12y ago
There are some Python programmers who sometimes regret Python doesn't have some static typing. Go has that and also provides an easy way to be quite dynamic when that's wished for (or even when not - without generics one'll have to resort to `interface{}` even if that's not desired, huh).
sergiosgc 12y ago
From what I understand, Go is an opinionated language, with a nice concurrency framework. It's not groundbreaking, it's not particularly expressive or adapted to any specific use case. It so happens that if your style fits Go's ideology (opinionated view), you become a fan. For me, the lack of exceptions kills the language. C-like error testing smells like a twenty year de-evolution. I also dislike the flat object model, but could force myself to live with it for the sake of trying composition over inheritance. Error returning, however, is taking the ideology too far.
- niemeyer 12y ago
  You are assuming the use of exceptions is an evolution in the first place, but that's far from being a consensus. To some of us, exceptions are very convenient, but more easily lead to brittle software. I wrote a little bit about that before. Probably won't help you much, except perhaps in acknowledging that there's a different angle to that which some people may care about. http://blog.labix.org/2013/04/23/exceptional-crashes http://blog.labix.org/2013/04/23/exceptional-crashes
  - 12y ago

gbog 12y ago

When I read go specs or go vs python comparison, nearly every diff is a specific pain point of our big python code base. No keyword argument? to hell with them. Strict formatting? That should be in python interpreter. No unused import: would have saved our lives. No cyclic dependencies? No inheritance? No exceptions? Great, all of them are maintenance nightmares.

mercurial 12y ago
What's your issue with keyword arguments, apart from magic args/*kwargs? They're quite convenient. As for exceptions, the problem with Python is more that the exceptions are unchecked than exceptions in general.
smnrchrds 12y ago
Can you please elaborate. I don't understand what could be wrong with keyword arguments. Also I can't see how an unused import can waste a life, unless there is some lethal side-effect to importing that package (I don't like import side-effects, but they are inconvenient whether the import is used or unused). Exceptions seem pretty useful as well.
- gbog 12y ago
  Python's keyword arguments: def f(a, b=1, c=2): pass Now, same call can be written `f(0, 1, 2)` and `f(0, b=2, a=1)`, which makes it much harder to refactor. For instance, suppose you want to add a non-keyword argument, you'll have to carefully grep for all calls. I think functions should be either full keyword arguments and naming them in calls should be mandatory. Or no keyword arguments at all. The mixing of both is "convenient" for prototyping, but has a high long-term cost. Unused imports: In a module bar, you have `import foo`. How do you know if it is used or not? You'll have to scan all modules importing bar to check if they import foo. Granted, the problem is not that import foo is unused, but that it is imported in bar's namespace. Exceptions make it hard to follow code paths and easy to hide important events. The hardest debugs I've endured are because of exceptions. An innocent looking `except AttributeError` can be hiding a deep issue in some remote library playing badly with getattr magic. That said, I love Python, and still think it is the most elegant language. I will most certainly teach Python to my kid when he'll be old enough. I also believe it is best suited for a full serie of programming tasks. But, when code base grow in size and complexity, some of its "tolerance" become a burden.

baldfat 12y ago

There is no one best language. Numpy is not something Go is going to do (Correct em if I am wrong). Julia would be the faster language to switch to, but personally I switched from Python to R due to the fact that I like languages that are made for what I am doing. Python always feels second best to whatever I am doing and I have branched away from Python. So R for statistics is great for me.

howeman 12y ago
Besides operator overloading, why can't Go do Numpy?

rogerdpack 12y ago

Did he say that people looking for faster build times than C++ went to java? They may not have found what they were looking for, in that case... Go does lack a quality [IMO] IDE [re: REPL use is for development], but that can still come with time. Quality GUI bindings can also come with time [how often do you actually use Python for GUI stuff, though...but still nice to have, just not its major use I doubt] Another thing you'll miss from Python is accidentally typo'ing variable names and having to discover that only at runtime :) Just my rebuttal :)

pjc50 12y ago
Java is faster to build than C++ almost all of the time. Header files (especially with templates) tend to turn C++ in to an O(n^2) run time, often running into hours.
- rogerdpack 12y ago
  OK, the only thing I can compare it against is my current "java" build times, and I can tell you that using maven is somewhat slow. So I guess you could say that if people went to java from c++ for the improved build times, they might still be interested in Go for the same improvement over java :)
kyllo 12y ago
Another thing you'll miss from Python is accidentally typo'ing variable names and having to discover that only at runtime :) python -m compileall . :)
- rogerdpack 12y ago
  I was referring to typo'ing for instance assignment (perhaps you were as well?) a = 3 if true: a2 = 4 # lame I know--but beginners like me do it --Python lets discover your failure at runtime...[as a good dynamic typed language does--Go doesn't FWIW]. It was just from an experience I had with learning Python recently. Now it makes me wonder what his blog post would look like saying things he'd miss going from Go to Python, or "what I wouldn't miss from Python..."

adwn 12y ago

It's ironic that the author dismisses C++ to a small niche: > Those who still stick to C++, after all these years, either really can't live with the "overheads" (real time apps - those are waiting for Rust to mature), or think they can't (and nothing will convince them except a competitor eventually forcing their employer out of business). Yet later he gives a good example for an important area where C++ is still unbeaten: scientific computing libraries. If you want/need maximum performance, then right now, there's no other language that has no overhead and zero-cost abstractions (to the degree that C++, especially C++11, has them). Hopefully Rust will get there eventually, but as of today, you have three choices: Fortran, C, and C++ – and neither C nor Fortran offer any abstractions worth mentioning.

Touche 12y ago
I don't understand your complaint, isn't "scientific computing libraries" a niche?
- adwn 12y ago
  > isn't "scientific computing libraries" a niche In a way, yes. The point I'm trying to make is that there are many niches that require the performance of C++ [1], while the author implied that there's just a single one. Sorry, I should have been clearer on that. [1] If you're not convinced, I can give you a lot more examples.
fulafel 12y ago
Zero-cost abstractions come at a pretty hefty price if you pick C++. The cost is in programmer productivity & quality of resulting software. I'm sure there are some fields of academia where this is a reasonable tradeoff (if you're programming DSP algorithms running on a embedded battery powered device strapped to a dolphin, say...) but your generic number crunching job rarely calls for it. (As an aside, zero-overhead abstractions being unique to C++ doesn't sound right to me. Then again I haven't heard the term used outside C++ circles and its meaning is nebulous, so maybe it's just a name for C++'s tradeoffs?)
- 12y ago

ChikkaChiChi 12y ago

The argument "would have switched to X before" seems to not consider the possibility of new adoptions. If I didn't need the things that Go provides before, that does not mean I do not need them today or tomorrow.

pothibo 12y ago

Most of the GUIs are done on a main thread which makes some of Go's advantages unneeded. Don't build GUI in Go, ever. Error handling is a way of thinking: TDD is one, Go's approach is another. REPL is not a must, environment without REPL means you have to think more about what you want. It's a process. You should be able to read source code and figure out how things work. Like many mentioned here, Go is great at doing system stuff, like background queues and processing. Stay with Python until you need to get thing faster, then move them to Go. That's how you should think of it.

higherpurpose 12y ago

He forgot the part about Go also being a great replacement for Java, for those who don't like Java.

hellbreakslose 12y ago

Go is Googles C#, I see good use on it, and it will evolve a lot more in the next few years.

dragonwriter 12y ago

> No exceptions [...] If I want higher-level error context I need to propagate the error upwards, with an if at every function call along the way. This is flat out false. Go has fairly standard exceptions (panics), though instead of using try/catch/finally blocks it uses deferred functions that perform a hybrid of the "catch" (if they use "recover") and "finally" functionality. It is a go convention that library code doesn't let panics escape to the calling code, so if you are going to use panics in your own code, to follow the convention you should be recovering from them somewhere in the call chain that you control rather than letting them escape across the public API of your code. But that's it, they exist, and can be used. So, while there may be some ground to complain that when calling the standard library you have to handle error returns rather than catching exceptions (equivalently, "recovering from panics") -- though, IMO, there is a good reason for this design choice -- there is absolutely no reason, aside from sheer ignorance and not reading even the most basic Go documentation -- to say that you don't have exceptions that you can use within your own code and that you have to to error-return handling at every level in your own code to deal with error propagation. If you make that complaint, it is clear you don't know what you are talking about.

deleted 12y ago
[deleted]
- dragonwriter 12y ago
  I'm not objecting to you choosing not learn something in depth because you don't like how it looks on the surface (that's a rational approach to avoiding wasting time, which is a valuable resource), I'm objecting to you, in the linked article, commenting in depth (and inaccurately) on something its clear that you decided not to learn in depth because you didn't like how it looks on the surface. The statement that Go has "no exceptions", or that for deep error handling in your own code you have to handle errors at each level is false. And, fine, you didn't learn anything about it because maybe you saw sample code showing how you need to deal with the public API of common libraries because of the Go convention that panics aren't exposed across public APIs. And if all you said was that, it'd be fine -- but you went beyond that and said things that weren't true and which people who haven't learned the language might not realize were statements from ignorance rather than experience, and might turn them off of the language where they wouldn't be turned off if they knew the truth, because if they were true, they'd be real and deep problems with the language design. Choosing to remain ignorant about Go because it doesn't seem like its worth your time to learn is fine. Making up stories about why you don't like Go that aren't grounded in anything real is not. TL;DR: if you choose to be ignorant, you don't get to pretend to be an authority.

rakoo 12y ago

I think the author misses the point. The number one reason Go was created was to build maintainable softwares, the kind Google uses at large. The easiest way to build these are: - Automatic memory management -> GC - Bug catching before the software is run -> Static typing - Overall simplicity -> few features, added only if it is extremely needed The thing is, when you start using Go, you already know its features. There is nothing particularly new, and it all fits in your head. It is a bit strict though, so there is some boilerplate (error checking, sort.Sort, ...) but that's going to save you when you edit your software in 5 years. Here, performance (both compilation and running) is a byproduct of simplicity. Now, I'm not saying the OP's use cases are invalid, far from it; they're just not what was intended in the process of creating Go. Like OP, I tend to think that Go is the new Java: "boring" (ie no revolutionary features) but it just works for server-side softwares.

_yosefk 12y ago
Why do I miss the point if, like me, you think Go is the new Java? :-) I think it's exactly that, it works and that's fine, and why the JVM doesn't do cheap concurrency I don't know. If it did Java might have been the new Java :-)
- rakoo 12y ago
  I was referring to these: > What does Go have that C++ lacks? Mandatory garbage collection, memory safety, reflection, faster build times, modest runtime overhead. > If on the other hand most code in most websites matters a lot for performance, then maybe you want Go Specifically, seeing only the features (performance) and not the intent in Go. I should have said "misses the point in why Go can be more interesting than other languages". Now, as you said, if your requirements can't be fullfilled by Go (or any blub), then it's not worth switching. > If it did Java might have been the new Java :-) I don't think people avoid Java because of the lack of light concurrency (there are multiple production-ready libraries to do that). I think people avoid it because of Java-the-platform... so Java would have stayed the bloated Java :-)
- deleted 12y ago
  [deleted]

hellbreakslose 12y ago

I think on his point why Python Devs move from Python to Go, Its cause of the current version changes between Python 2 and 3.

micro_cam 12y ago

So I do a lot of scientific programing in go [1]. I am absolutely still using python + numpy/scipy/pyamg for linear algebra heavy stuff but this has more to do with the available and well documented packages then operator overloading. I actually find that the interfaces used for math [2] encourage a more memory efficient coding style. Without operator overloading I'm less tempted to jam everything into a pretty one liner and more likely to set things up to work with out unintended reallocations. Lack of efficient generics is a much bigger annoyance. [1] See for example my random forest package https://github.com/ryanbressler/CloudForest https://github.com/ryanbressler/CloudForest [2] See package big for example http://golang.org/pkg/math/big/ http://golang.org/pkg/math/big/

howeman 12y ago

As of at least a year ago, their are bindings for the BLAS library of your choice (github.com/gonum/blas), which are used in many parts of the matrix package (github.com/gonum/matrix/mat64). As of a week ago, there are bindings for the Lapack implementation of your choice (github.com/gonum/lapack). These have not yet been worked in with matrix, but will be eventually (PR welcome!).

howeman 12y ago
Not to mention there's 2/3rds of a go BLAS implementation (benchmarks https://groups.google.com/forum/#!msg/gonum-dev/Cqa41tbUUCw/EuTBQFBhod0J https://groups.google.com/forum/#!msg/gonum-dev/Cqa41tbUUCw/...). Level 3 routines are much harder to make efficient (people are still researching efficient matrix multiply)

mimighost 12y ago

Go could take a bite from Python in web development area, but scientific computing...No chance