10 ms·

Go is boring

137 points by iand 14y ago

trung_pham 14y ago
I love static typed language. With a proper IDE, code navigation, completion work like magic. I end up doing less typing than the dynamic typed language. Have you ever tried to auto complete the 'init' function in RubyMine? It will ask you which one of the 100 init functions do you mean. :) Not with static typed language. There is only one init function to choose from because the IDE knows the exact type you are working with at all time.
- fshen 14y ago
  Yes. I can't agree more. One example to backup: Eclipse makes Java fun.
  - chadmaughan 14y ago
    Is this sarcasm? =) If you want to know how real auto-complete works, try out IntelliJ. Auto-complete on Eclipse is like slowly being pecked to death by ducks. A more accurate statement in my mind is "Eclipse makes Java palpable, IntelliJ makes Java fun."
    - fshen 14y ago
      I am downloading IntelliJ. I've use Eclipse for years, It works for me. I will give Eclipse a try.
      - trung_pham 14y ago
        IntelliJ is the best IDE out there. It might be pricy, but it will save you so much time in the long run. Since time is money, you will end up saving money too. :)
        Mr_T_ 14y ago
        The Community Edition is free of cost. The choice depends on what you need: http://www.jetbrains.com/idea/features/editions_comparison_matrix.html http://www.jetbrains.com/idea/features/editions_comparison_m...
        thebluesky 14y ago
        yeah free version supports Java SE, with a really nice Scala plugin for download via the plugin manager.
- hasenj 14y ago
  I'm also starting to find that a language with static typing and generally an enforced structure is easier to deal with. With dynamic languages, you have to hold a lot in your head. Having an enforced structure offloads some things off your brain so you have more mental space to think clearly and not panic or get burned.
- irishcoffee 14y ago
  I think the counter-argument here would be that dynamically-typed languages let the person behind the keyboard run the show, as opposed to the IDE.
  - eru 14y ago
    Alas, nobody has written a really good IDE for Haskell, yet. So we still have to run the show for that statically typed language manually.
    - protomyth 14y ago
      If I ever develop a program language, the first action I will take is the clang approach and make it a library based architecture. That way, people can build tools for the language including IDE integration without having to reinvent the wheel.
      - pcwalton 14y ago
        Yes, this has been invaluable for us in Rust. One cool thing we've been able to do with this architecture is to write a fuzzer -- a tool that uses the Rust compiler itself to generate random Rust programs to test the compiler's correctness.
      - tikhonj 14y ago
        I think GHC does something like that. At the very least, it exposes an API that lets you do all sorts of fun things. There are projects like Scion[1] that let you integrate that into an editor. [1]: https://github.com/nominolo/scion/ https://github.com/nominolo/scion/ However, there is simply less drive to develop tooling like that for Haskell than there is for Java. Haskell is a much easier language to use given just a moderately intelligent text editor and a REPL than most others. Java, on the other hand, it verbose and annoying even with a very good IDE. So Haskell can have good support, but since it isn't terribly necessary it isn't anything like a top priority.
        obtu 14y ago
- eru 14y ago
  Static typing also makes overloading your f.unctions on return type instead of just arguments types possible. Not a lot of languages do this, though. I only know of one, but it's invaluable there.
  - mikebike 14y ago
    Perl's a dynamic language, but return type can vary based on context. I once saw this really bite someone where the presence of parentheses on the left-hand side of the expression changed the behavior of the function being called on the right-hand side. Not fun to debug that one.
    - Evbn 14y ago
      Once? That is a daily occurrence in Perl development. Perl is more like a friend than a tool. It does what it wants, not what you say, and usually what it thinks you want, but sometimes it stabs you in the back.
    - trung_pham 14y ago
      Exactly. Duck typing sucks. I don't know why it was invented...
      - batista 14y ago
        The above is not an example of duck typing. Even if it was, one example of a difficult bug in one system does not invalidate a whole concept. And duck typing is almost as old as programming itself...
      - jroesch 14y ago
        It only "sucks"(causes problems rarely, and can be quite useful regardless) in dynamic languages. Languages like Go, Rust, and Haskell provide the same flexibility with static guarantees. All you must do is define type specific implementations to satisfy the interface(or typeclass). For example in Haskell, I can so something like: class Stream s where read :: s -> (a, s) write :: a -> s -> s and extend it to any type: instance Stream [Int] where read s = ... write a s = ... instance Stream File where ... and so on, and I can now pass any type that is a member of Stream, to a function that expects one.
- cageface 14y ago
  I do too but I'm finding that a lot of the time there are so many untyped inputs to a system that the static typing doesn't buy you that much. There always seems to be a ton of xml configuration data, incoming JSON from web services, databases with different type schemes etc.
  - MaxGabriel 14y ago
    I don't know about other environments, but on iOS I just create a class that I store the e.g. JSON data in.
  - alexatkeplar 14y ago
    As soon as you receive an untyped input, make it conform to a typed data structure, and throw some kind of error if you can't. That way you catch any issues in your input data long before it bubbles through your app and causes a problem which is super-hard to track down. See e.g. DictShield for Python (https://github.com/j2labs/dictshield https://github.com/j2labs/dictshield), Jackson for JVM (http://jackson.codehaus.org/ http://jackson.codehaus.org/), Swiz for node.js (https://github.com/racker/node-swiz https://github.com/racker/node-swiz)...
- cmelbye 14y ago
  Which IDE do you use with Go?
  - wonderzombie 14y ago
    I use Sublime Text 2 with GoSublime. http://www.sublimetext.com/ http://www.sublimetext.com/ https://github.com/DisposaBoy/GoSublime https://github.com/DisposaBoy/GoSublime
  - irahul 14y ago
    Vim with gocode https://github.com/nsf/gocode https://github.com/nsf/gocode
- Erwin 14y ago
  IntelliJ's Python module (Pycharm) does a as decent job as you might expect based on code and your type annotations (i.e. if your docstring says that foobar is a BlahManager, it will complete foobar methods based on that and warn you if you are calling something foobar doesn't have).
1337p337 14y ago
This is largely spot-on. Of course, the author's assertion (that having all of these things in one place is novel) is incorrect for some programmers, but the sheer boringness of the language is a virtue. Go's features as bullet points are unimpressive; the set of features is the impressive part. Putting in features that are solidly understood, that are desirable, and that don't clash with each other make for a simple, solid, nice language. I've tried without success to dig up an email from Linus Torvalds (on the LKML?) where, responding to an email complaining that a particular implementation of ARM does not breaking any interesting ground, he goes on a mini-tirade about the lack of appreciation for a simple thing done well. I think Go fits the description nicely.
soofaloofa 14y ago
Boring != bad.
- mathgladiator 14y ago
  Boring also probably means "I can build an enterprise level business on it"
- tinyjoe 14y ago
  Boring <> Performance
- ajasmin 14y ago
  I think that's the point the author was trying to make.
- bjz 14y ago
  I think that's a perfect tl;dr. :)
crazygringo 14y ago
Site seems to be down, here's cache: http://webcache.googleusercontent.com/search?q=cache:http://aeronotix.pl/blog/go-is-boring http://webcache.googleusercontent.com/search?q=cache:http://...
hasenj 14y ago
I'd like to point out that I never heard of coroutines before Go. Not even in computer science; and I did take an Operating Systems course. I also never seen any language doing interfaces like Go. Go does it just right. I find that this is pretty impressive as a feature on its own.
- eru 14y ago
  > Not even in computer science; What did you specialize in? It's pretty easy to hit upon co-routines, if you have an interest in Scheme or even Haskell. But I can imagine, it's much harder if you are into, say, the innards of database schemas. (Just a random example.)
  - hasenj 14y ago
    I don't know why I didn't come across it. Maybe if I took Operating System II ..
    - javert 14y ago
      I think you would have had to go deeper into programming languages, not deeper into operating systems. Disclaimer: The above is definitely true for coroutines in general, but I don't know much about Go and whether its coroutines are truly unique.
      - MaxGabriel 14y ago
        I also heard of it in a programming languages course, and also in Udacity CS 212 I think. To add to the list, they're implemented in Python using yield statements
        nas 14y ago
        Python's yield was originally a limited co-routine, something we coined as a "generator" (borrowing the word from Icon, which Tim was quite fond of). It was limited to one frame on the stack and could only return values. Recent enhancements have allowed values to be passed back into the suspended function. That's still not a full co-routine though since Python only lets you go one level down on the stack. As someone else mentioned, you need to get deeper into programming languages, not operating systems. Scheme has call/cc which can be used to build co-routines. Someone needs to clue in the nodejs crazies as well, callbacks are not the way to design a language. ;-)
ozataman 14y ago
I've tried giving Go a try a bunch of times now. My primary choice of language is Haskell and I just can't seem to get excited about Go.
- thebigshane 14y ago
  Would you say your interest in programming languages is largely academic in nature? I get the impression that Haskell mostly (for now at least) fits best with academia, Java/C# for enterprise, python/ruby for smallish web apps, Go/C/C++/Java for industrial applications (like servers, etc). There is a very real possibility that Go is just not the right fit for you with your current requirements. No language is the right fit for every application.
  - DanWaterworth 14y ago
    Haskell isn't just used in academia. It's used a Facebook for example, and no-one would accuse Facebook of being an academic company.
  - cpeterso 14y ago
    And C/C++ is by developers to implement Java, C#, Python, Ruby, Go, C, and C++. :)
    - pjmlp 14y ago
      Actually there are Java and C# compilers implemented on the own language.
  - ozataman 14y ago
    Not at all. In fact about 95% of all Haskell I write - and I write quite a bit - is for commercial stuff, ranging all the way across large-ish (not quite google-scale, yet) scale computation, distributed systems, machine learning, modeling/simulations and web development. More academic feeling stuff like parsing and DSLs are just the cherries on top (though even those were for commercial uses). I'll admit Haskell has a steep learning curve, but once you're there, all this stuff Go is said to do real well feels fairly lackluster compared to what you can find in Haskell-land. What's built into Go can be achieved at the library level in Haskell. As a result, we keep seeing better and better manifestations of key ideas in the library space. Examples include Cloud Haskell, many, many concurrency libraries, STM, Parallel Haskell, many constant-space data streaming libraries (pipes, conduits, enumerators, ...), several excellent parsing libraries (parsec, attoparsec, trifecta, ...), etc. As a side note, I used to do lots of python/ruby - I really can't anymore. They feel simultaneously more burdensome to code (no static type-checking), more verbose (no elegant, long pipelines of computations), less expressive (no real first class functions - you barely use map/reduce/fold/etc. in python) and slower (as in runtime). Having said all that, I do see how Go fills a gap in the market. You need something that's easy to grok and gets just enough of it right that you can produce fast, type-safe-enough and concurrent programs with somewhat less mutable state than what you may be used to in C. A simple mental model and ease of entry are conceivably great for larger, homogeneous teams.
onan_barbarian 14y ago
I reached the same conclusion ("Go is boring") myself, but with a different flavor. After having spent a great deal of time in recent years doing things like GPGPU and a _whole_ lot of SIMD programming (not to mention a lot of use of the STL, BGL, etc), I have to say I'm less impressed by the boringness (aka taking good, solid choices from existing languages) of Go. I understand that not everyone is excited about SIMD or generic programming or writing code for 32768 GPGPU threads... but Go feels like a missed opportunity in these respects, solving the problems of the mid-1990s with aplomb (which is good). It seems more like 'a better Java' - solid, but not genuinely breaking any new ground in a way that creates a single good reason to use it.
- genbattle 14y ago
  To be fair, no programming language has really taken a first-party approach to those specific problems. SIMD and GPGPU both fairly difficult low-level concepts as they stand: I think there would definitely be some valuable postgrad research in looking at how to create higher-level interfaces to graphics acceleration and GPGPU/SIMD that are as simple and effective as Go's goroutines. The main problem is that SIMD and GPGPU (even hardware accelerated graphics, to a lesser extent) are bolt-ons; they're not a core part of every computer, which is why they don't usually form a core part of any programming language. At best languages might choose to integrate this functionality into the standard library, but i don't think it will ever come built-in for a general-purpose language (maybe for a domain-specific language?). I've actually been attempting to write a GPGPU interface between Go and OpenCL[1], so it's certainly not impossible to do GPGPU or SIMD in Go (via cgo), but it would require writing your own 3rd-party libraries or making additions to the go runtime/compiler to develop a novel interface to this functionality like goroutines that can run on the GPU (a dream many people in the Go community share). [1] https://bitbucket.org/genbattle/go-opencl https://bitbucket.org/genbattle/go-opencl
  - beagle3 14y ago
    > To be fair, no programming language has really taken a first-party approach to those specific problems. APL (and it's descendants J and K) has everything needed to do justice to SIMD/GPGPU. And it had them since the early 60s. I am not aware of an APL compiler that actually uses GPU or SIMD instructions, but one is possible, and wouldn't require any change to the base language. Not surprisingly, this is because the idiomatic model is closer to the SIMD mindset than to the "standard" (algol/pascal/c/java/python/go) mindset, which is why it is unlikely to ever become popular.
ak217 14y ago
This sounds really interesting and compelling. As someone new to Go... What would be the advantages of using Go over Python (taking into account the emergence and future ascendancy of pypy)?
- dhconnelly 14y ago
  A few: - Go has language-level support, in the form of goroutines, for multithreaded concurrency. Python is single-OS-thread-only, and PyPy doesn't change that. - Go has enough static typing to help you write safer code, without the verbosity of "bigger" languages like C++ or Java. If you write a lot of tests for your Python app, you might not have variable typos or function argument type mismatches, but in Go the compiler catches these things. - Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. These, together with the fact that many of the niceties of Python are available in Go (lightweight syntax, first-class functions, iterators and list slicing, etc), make it, in my opinion, a compelling alternative to Python.
  - ak217 14y ago
    > Python is single-OS-thread-only, and PyPy doesn't change that. Neither statement is really the whole truth, and Python does have some nice ways to do coroutines and futures now, but I see how Go is better here (those 2 features do need to be in the core of the language) and with your other points, thanks.
  - batista 14y ago
    >- Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. Actually it's slower or comparable that simple Python in most cases. And slower than Java, which also uses a JIT. It being "Machine code" doesn't mean much. The implementation also counts, as do the libs. In Python lots of stuff is delegated to plain old C libs.
  - irahul 14y ago
    > Python is single-OS-thread-only, and PyPy doesn't change that. Python uses native multi-threads, but the GIL restriction means only one thread can run at a time regardless of number of cores or processors you have. > If you write a lot of tests for your Python app, you might not have variable typos or function argument type mismatches, but in Go the compiler catches these things. Use pylint and/or syntastic(for vim). > Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. Go is slower than Java. http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=go&lang2=java http://shootout.alioth.debian.org/u32/benchmark.php?test=all... They removed lua-jit from the benchmarks. lua-jit will smoke go in most scenarios. Here is a comparison between lua-jit and lua. http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html Native code doesn't mean "always faster than JIT/VM". A good JIT can do optimizations which a static compiler can't. For a long running process with hotspots(same code hit multiple times), a JIT can be as good as(or better) than native code.
lazyjones 14y ago
The author makes valid points and some of the reasons why I tested Go recently are named, but when it was ~15x slower than Perl and 10x slower than Java on some simple regexp matching, I gave up on it.
- dhconnelly 14y ago
  There's some history behind this. You can read some of it from Russ Cox, one of the Go authors. https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/6d1maef4jQ8 https://groups.google.com/forum/?fromgroups#!topic/golang-nu... http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/regexp1.html Edit: missed another good one. There's a lot of discussion about this on the mailing list. https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/GNLTUTFNNl0 https://groups.google.com/forum/?fromgroups#!topic/golang-nu...
- jbarham 14y ago
  With other simple regular expressions Perl and Java will be millions of times slower than Go: http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/regexp1.html
olaf 14y ago
I think the purpose of Go is to solve some of Googles very specific problems (e.g. easiness feeling comparable to Python, short compile teams, ease construction of concurrent internet server apps), not to enthuse anybody. If I see it as an unspectacular, better Python, not as a top modern language then it makes some sense to me. It seems they had to sacrifice sth. for short compile times (e.g. generics).
D_Guidi 14y ago
link broken :(
Ziomislaw 14y ago
I view 'boring' as an advantage. Go is so 'boring' that you just can't focus on the language, you focus on your task.
rsaarelm 14y ago
Having simple, established ways for doing most common things makes it easy to write code without thinking about decisions around the programming language, such as how the syntax should be formatted, how the symbols should be named, how should memory management be arranged, what conventions should be used for splitting code into files and modules (with little extra design issues involved in structuring header files and include relations, in case you're doing C/C++), what kind of build system should be used, which unit test framework should be chosen and which third party libraries should be chosen for the very commonly needed stuff that's nevertheless not included in the language's standard library since it was standardized somewhere in the late 80s. Having all this stuff basically solved out of the box makes it very easy to start cranking out actual solutions with Go, even though none of that is particularly interesting from a programming language design standpoint.
StavrosK 14y ago
As a long-time Python programmer, I tried Go recently for something that needed large amounts of concurrency (a hosted version of hubot: http://instabot.stochastictechnologies.com http://instabot.stochastictechnologies.com), and I have to say, I am very pleasantly surprised. The type system was a bit cumbersome, after coming from Python, especially having to wrangle with pointers after not using them ever, but it's nothing you don't get used to. I'm still not sure how much I gain from static typing, but I'm willing to bear it out. Channels and goroutines, however, were an absolute dream to use. The entire IRC frontend runs off one process, which, I am led to believe, will basically never need anything more (it just proxies messages from IRC to the backend and back). Communication with the processes was fantastically easy, creating, launching and reasoning about goroutines is, again, very straightforward, and all this feel very much like a first-class citizens. Python has gevent too, and it suited me very well, but Go feels more integrated and better done.
- slurgfest 14y ago
  I think what you gain from static typing is pretty much that you can compile your programs and run without a fat interpreter. Note - I am not saying that is the only possible benefit of static typing anywhere, e.g. in Haskell - this is more in line with C, you are doing type declarations to cue the compiler rather than to realize some utopian test-free development methodology.
  - StavrosK 14y ago
    Oh, definitely, I'm just not sure it gains that much speed compared to Python. I'd expect Go's speed to be on par with C, but, from what I understand, it's more like PyPy. Of course, this is just from what I hear, I haven't run any benchmarks. Does anyone have more details about this?
KlausTrainer 14y ago
Maybe the website wouldn't be down right now if it'd run on Go.
api 14y ago
C is boring too, in all the right ways. I think Go could be what we've been waiting for: C 2.0.
- ntrel 14y ago
  C's preprocessor means C code can often do interesting tricks, such as the X macro: http://www.drdobbs.com/the-new-c-x-macros/184401387 http://www.drdobbs.com/the-new-c-x-macros/184401387 There are tons of other interesting uses for macros. Obviously I'd rather a language had safer equivalents to a C preprocessor.
charlieflowers 14y ago
The thing that makes me pull back from trying Go is the fact that it has no exceptions and no other feature for handling errors (correct me if I'm wrong). Ugh! I can't imagine going back to the days when I had to call a function, check its return value to see whether there was an error or not, then, if no error, proceed to the next function call, check it for error, and so on. I know exceptions were a source of "complexity", and you could say that Maybe monads or other programming attempts to solve the problem increase complexity too. But to just punt and go back to doing it the ugly, unmaintainable brute force way? I just find that hard to swallow.

137 points by iand 14y ago

I love static typed language. With a proper IDE, code navigation, completion work like magic. I end up doing less typing than the dynamic typed language. Have you ever tried to auto complete the 'init' function in RubyMine? It will ask you which one of the 100 init functions do you mean. :) Not with static typed language. There is only one init function to choose from because the IDE knows the exact type you are working with at all time.

fshen 14y ago
Yes. I can't agree more. One example to backup: Eclipse makes Java fun.
- chadmaughan 14y ago
  Is this sarcasm? =) If you want to know how real auto-complete works, try out IntelliJ. Auto-complete on Eclipse is like slowly being pecked to death by ducks. A more accurate statement in my mind is "Eclipse makes Java palpable, IntelliJ makes Java fun."
  - fshen 14y ago
    I am downloading IntelliJ. I've use Eclipse for years, It works for me. I will give Eclipse a try.
    - trung_pham 14y ago
      IntelliJ is the best IDE out there. It might be pricy, but it will save you so much time in the long run. Since time is money, you will end up saving money too. :)
      - Mr_T_ 14y ago
        The Community Edition is free of cost. The choice depends on what you need: http://www.jetbrains.com/idea/features/editions_comparison_matrix.html http://www.jetbrains.com/idea/features/editions_comparison_m...
        thebluesky 14y ago
        yeah free version supports Java SE, with a really nice Scala plugin for download via the plugin manager.
hasenj 14y ago
I'm also starting to find that a language with static typing and generally an enforced structure is easier to deal with. With dynamic languages, you have to hold a lot in your head. Having an enforced structure offloads some things off your brain so you have more mental space to think clearly and not panic or get burned.
irishcoffee 14y ago
I think the counter-argument here would be that dynamically-typed languages let the person behind the keyboard run the show, as opposed to the IDE.
- eru 14y ago
  Alas, nobody has written a really good IDE for Haskell, yet. So we still have to run the show for that statically typed language manually.
  - protomyth 14y ago
    If I ever develop a program language, the first action I will take is the clang approach and make it a library based architecture. That way, people can build tools for the language including IDE integration without having to reinvent the wheel.
    - pcwalton 14y ago
      Yes, this has been invaluable for us in Rust. One cool thing we've been able to do with this architecture is to write a fuzzer -- a tool that uses the Rust compiler itself to generate random Rust programs to test the compiler's correctness.
    - tikhonj 14y ago
      I think GHC does something like that. At the very least, it exposes an API that lets you do all sorts of fun things. There are projects like Scion[1] that let you integrate that into an editor. [1]: https://github.com/nominolo/scion/ https://github.com/nominolo/scion/ However, there is simply less drive to develop tooling like that for Haskell than there is for Java. Haskell is a much easier language to use given just a moderately intelligent text editor and a REPL than most others. Java, on the other hand, it verbose and annoying even with a very good IDE. So Haskell can have good support, but since it isn't terribly necessary it isn't anything like a top priority.
      - obtu 14y ago
eru 14y ago
Static typing also makes overloading your f.unctions on return type instead of just arguments types possible. Not a lot of languages do this, though. I only know of one, but it's invaluable there.
- mikebike 14y ago
  Perl's a dynamic language, but return type can vary based on context. I once saw this really bite someone where the presence of parentheses on the left-hand side of the expression changed the behavior of the function being called on the right-hand side. Not fun to debug that one.
  - Evbn 14y ago
    Once? That is a daily occurrence in Perl development. Perl is more like a friend than a tool. It does what it wants, not what you say, and usually what it thinks you want, but sometimes it stabs you in the back.
  - trung_pham 14y ago
    Exactly. Duck typing sucks. I don't know why it was invented...
    - batista 14y ago
      The above is not an example of duck typing. Even if it was, one example of a difficult bug in one system does not invalidate a whole concept. And duck typing is almost as old as programming itself...
    - jroesch 14y ago
      It only "sucks"(causes problems rarely, and can be quite useful regardless) in dynamic languages. Languages like Go, Rust, and Haskell provide the same flexibility with static guarantees. All you must do is define type specific implementations to satisfy the interface(or typeclass). For example in Haskell, I can so something like: class Stream s where read :: s -> (a, s) write :: a -> s -> s and extend it to any type: instance Stream [Int] where read s = ... write a s = ... instance Stream File where ... and so on, and I can now pass any type that is a member of Stream, to a function that expects one.
cageface 14y ago
I do too but I'm finding that a lot of the time there are so many untyped inputs to a system that the static typing doesn't buy you that much. There always seems to be a ton of xml configuration data, incoming JSON from web services, databases with different type schemes etc.
- MaxGabriel 14y ago
  I don't know about other environments, but on iOS I just create a class that I store the e.g. JSON data in.
- alexatkeplar 14y ago
  As soon as you receive an untyped input, make it conform to a typed data structure, and throw some kind of error if you can't. That way you catch any issues in your input data long before it bubbles through your app and causes a problem which is super-hard to track down. See e.g. DictShield for Python (https://github.com/j2labs/dictshield https://github.com/j2labs/dictshield), Jackson for JVM (http://jackson.codehaus.org/ http://jackson.codehaus.org/), Swiz for node.js (https://github.com/racker/node-swiz https://github.com/racker/node-swiz)...
cmelbye 14y ago
Which IDE do you use with Go?
- wonderzombie 14y ago
  I use Sublime Text 2 with GoSublime. http://www.sublimetext.com/ http://www.sublimetext.com/ https://github.com/DisposaBoy/GoSublime https://github.com/DisposaBoy/GoSublime
- irahul 14y ago
  Vim with gocode https://github.com/nsf/gocode https://github.com/nsf/gocode
Erwin 14y ago
IntelliJ's Python module (Pycharm) does a as decent job as you might expect based on code and your type annotations (i.e. if your docstring says that foobar is a BlahManager, it will complete foobar methods based on that and warn you if you are calling something foobar doesn't have).

1337p337 14y ago

This is largely spot-on. Of course, the author's assertion (that having all of these things in one place is novel) is incorrect for some programmers, but the sheer boringness of the language is a virtue. Go's features as bullet points are unimpressive; the set of features is the impressive part. Putting in features that are solidly understood, that are desirable, and that don't clash with each other make for a simple, solid, nice language. I've tried without success to dig up an email from Linus Torvalds (on the LKML?) where, responding to an email complaining that a particular implementation of ARM does not breaking any interesting ground, he goes on a mini-tirade about the lack of appreciation for a simple thing done well. I think Go fits the description nicely.

soofaloofa 14y ago

Boring != bad.

mathgladiator 14y ago
Boring also probably means "I can build an enterprise level business on it"
tinyjoe 14y ago
Boring <> Performance
ajasmin 14y ago
I think that's the point the author was trying to make.
bjz 14y ago
I think that's a perfect tl;dr. :)

crazygringo 14y ago

Site seems to be down, here's cache: http://webcache.googleusercontent.com/search?q=cache:http://aeronotix.pl/blog/go-is-boring http://webcache.googleusercontent.com/search?q=cache:http://...

hasenj 14y ago

I'd like to point out that I never heard of coroutines before Go. Not even in computer science; and I did take an Operating Systems course. I also never seen any language doing interfaces like Go. Go does it just right. I find that this is pretty impressive as a feature on its own.

eru 14y ago
> Not even in computer science; What did you specialize in? It's pretty easy to hit upon co-routines, if you have an interest in Scheme or even Haskell. But I can imagine, it's much harder if you are into, say, the innards of database schemas. (Just a random example.)
- hasenj 14y ago
  I don't know why I didn't come across it. Maybe if I took Operating System II ..
  - javert 14y ago
    I think you would have had to go deeper into programming languages, not deeper into operating systems. Disclaimer: The above is definitely true for coroutines in general, but I don't know much about Go and whether its coroutines are truly unique.
    - MaxGabriel 14y ago
      I also heard of it in a programming languages course, and also in Udacity CS 212 I think. To add to the list, they're implemented in Python using yield statements
      - nas 14y ago
        Python's yield was originally a limited co-routine, something we coined as a "generator" (borrowing the word from Icon, which Tim was quite fond of). It was limited to one frame on the stack and could only return values. Recent enhancements have allowed values to be passed back into the suspended function. That's still not a full co-routine though since Python only lets you go one level down on the stack. As someone else mentioned, you need to get deeper into programming languages, not operating systems. Scheme has call/cc which can be used to build co-routines. Someone needs to clue in the nodejs crazies as well, callbacks are not the way to design a language. ;-)

ozataman 14y ago

I've tried giving Go a try a bunch of times now. My primary choice of language is Haskell and I just can't seem to get excited about Go.

thebigshane 14y ago
Would you say your interest in programming languages is largely academic in nature? I get the impression that Haskell mostly (for now at least) fits best with academia, Java/C# for enterprise, python/ruby for smallish web apps, Go/C/C++/Java for industrial applications (like servers, etc). There is a very real possibility that Go is just not the right fit for you with your current requirements. No language is the right fit for every application.
- DanWaterworth 14y ago
  Haskell isn't just used in academia. It's used a Facebook for example, and no-one would accuse Facebook of being an academic company.
- cpeterso 14y ago
  And C/C++ is by developers to implement Java, C#, Python, Ruby, Go, C, and C++. :)
  - pjmlp 14y ago
    Actually there are Java and C# compilers implemented on the own language.
- ozataman 14y ago
  Not at all. In fact about 95% of all Haskell I write - and I write quite a bit - is for commercial stuff, ranging all the way across large-ish (not quite google-scale, yet) scale computation, distributed systems, machine learning, modeling/simulations and web development. More academic feeling stuff like parsing and DSLs are just the cherries on top (though even those were for commercial uses). I'll admit Haskell has a steep learning curve, but once you're there, all this stuff Go is said to do real well feels fairly lackluster compared to what you can find in Haskell-land. What's built into Go can be achieved at the library level in Haskell. As a result, we keep seeing better and better manifestations of key ideas in the library space. Examples include Cloud Haskell, many, many concurrency libraries, STM, Parallel Haskell, many constant-space data streaming libraries (pipes, conduits, enumerators, ...), several excellent parsing libraries (parsec, attoparsec, trifecta, ...), etc. As a side note, I used to do lots of python/ruby - I really can't anymore. They feel simultaneously more burdensome to code (no static type-checking), more verbose (no elegant, long pipelines of computations), less expressive (no real first class functions - you barely use map/reduce/fold/etc. in python) and slower (as in runtime). Having said all that, I do see how Go fills a gap in the market. You need something that's easy to grok and gets just enough of it right that you can produce fast, type-safe-enough and concurrent programs with somewhat less mutable state than what you may be used to in C. A simple mental model and ease of entry are conceivably great for larger, homogeneous teams.

onan_barbarian 14y ago

I reached the same conclusion ("Go is boring") myself, but with a different flavor. After having spent a great deal of time in recent years doing things like GPGPU and a _whole_ lot of SIMD programming (not to mention a lot of use of the STL, BGL, etc), I have to say I'm less impressed by the boringness (aka taking good, solid choices from existing languages) of Go. I understand that not everyone is excited about SIMD or generic programming or writing code for 32768 GPGPU threads... but Go feels like a missed opportunity in these respects, solving the problems of the mid-1990s with aplomb (which is good). It seems more like 'a better Java' - solid, but not genuinely breaking any new ground in a way that creates a single good reason to use it.

genbattle 14y ago
To be fair, no programming language has really taken a first-party approach to those specific problems. SIMD and GPGPU both fairly difficult low-level concepts as they stand: I think there would definitely be some valuable postgrad research in looking at how to create higher-level interfaces to graphics acceleration and GPGPU/SIMD that are as simple and effective as Go's goroutines. The main problem is that SIMD and GPGPU (even hardware accelerated graphics, to a lesser extent) are bolt-ons; they're not a core part of every computer, which is why they don't usually form a core part of any programming language. At best languages might choose to integrate this functionality into the standard library, but i don't think it will ever come built-in for a general-purpose language (maybe for a domain-specific language?). I've actually been attempting to write a GPGPU interface between Go and OpenCL[1], so it's certainly not impossible to do GPGPU or SIMD in Go (via cgo), but it would require writing your own 3rd-party libraries or making additions to the go runtime/compiler to develop a novel interface to this functionality like goroutines that can run on the GPU (a dream many people in the Go community share). [1] https://bitbucket.org/genbattle/go-opencl https://bitbucket.org/genbattle/go-opencl
- beagle3 14y ago
  > To be fair, no programming language has really taken a first-party approach to those specific problems. APL (and it's descendants J and K) has everything needed to do justice to SIMD/GPGPU. And it had them since the early 60s. I am not aware of an APL compiler that actually uses GPU or SIMD instructions, but one is possible, and wouldn't require any change to the base language. Not surprisingly, this is because the idiomatic model is closer to the SIMD mindset than to the "standard" (algol/pascal/c/java/python/go) mindset, which is why it is unlikely to ever become popular.

ak217 14y ago

This sounds really interesting and compelling. As someone new to Go... What would be the advantages of using Go over Python (taking into account the emergence and future ascendancy of pypy)?

dhconnelly 14y ago
A few: - Go has language-level support, in the form of goroutines, for multithreaded concurrency. Python is single-OS-thread-only, and PyPy doesn't change that. - Go has enough static typing to help you write safer code, without the verbosity of "bigger" languages like C++ or Java. If you write a lot of tests for your Python app, you might not have variable typos or function argument type mismatches, but in Go the compiler catches these things. - Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. These, together with the fact that many of the niceties of Python are available in Go (lightweight syntax, first-class functions, iterators and list slicing, etc), make it, in my opinion, a compelling alternative to Python.
- ak217 14y ago
  > Python is single-OS-thread-only, and PyPy doesn't change that. Neither statement is really the whole truth, and Python does have some nice ways to do coroutines and futures now, but I see how Go is better here (those 2 features do need to be in the core of the language) and with your other points, thanks.
- batista 14y ago
  >- Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. Actually it's slower or comparable that simple Python in most cases. And slower than Java, which also uses a JIT. It being "Machine code" doesn't mean much. The implementation also counts, as do the libs. In Python lots of stuff is delegated to plain old C libs.
- irahul 14y ago
  > Python is single-OS-thread-only, and PyPy doesn't change that. Python uses native multi-threads, but the GIL restriction means only one thread can run at a time regardless of number of cores or processors you have. > If you write a lot of tests for your Python app, you might not have variable typos or function argument type mismatches, but in Go the compiler catches these things. Use pylint and/or syntastic(for vim). > Go is compiled to machine code. This means that, barring a miracle in JIT/VM research, Go will probably always be faster than PyPy for most tasks. Go is slower than Java. http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=go&lang2=java http://shootout.alioth.debian.org/u32/benchmark.php?test=all... They removed lua-jit from the benchmarks. lua-jit will smoke go in most scenarios. Here is a comparison between lua-jit and lua. http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html Native code doesn't mean "always faster than JIT/VM". A good JIT can do optimizations which a static compiler can't. For a long running process with hotspots(same code hit multiple times), a JIT can be as good as(or better) than native code.

lazyjones 14y ago

The author makes valid points and some of the reasons why I tested Go recently are named, but when it was ~15x slower than Perl and 10x slower than Java on some simple regexp matching, I gave up on it.

dhconnelly 14y ago
There's some history behind this. You can read some of it from Russ Cox, one of the Go authors. https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/6d1maef4jQ8 https://groups.google.com/forum/?fromgroups#!topic/golang-nu... http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/regexp1.html Edit: missed another good one. There's a lot of discussion about this on the mailing list. https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/GNLTUTFNNl0 https://groups.google.com/forum/?fromgroups#!topic/golang-nu...
jbarham 14y ago
With other simple regular expressions Perl and Java will be millions of times slower than Go: http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/regexp1.html

olaf 14y ago

I think the purpose of Go is to solve some of Googles very specific problems (e.g. easiness feeling comparable to Python, short compile teams, ease construction of concurrent internet server apps), not to enthuse anybody. If I see it as an unspectacular, better Python, not as a top modern language then it makes some sense to me. It seems they had to sacrifice sth. for short compile times (e.g. generics).

D_Guidi 14y ago

link broken :(

Ziomislaw 14y ago

I view 'boring' as an advantage. Go is so 'boring' that you just can't focus on the language, you focus on your task.

rsaarelm 14y ago

Having simple, established ways for doing most common things makes it easy to write code without thinking about decisions around the programming language, such as how the syntax should be formatted, how the symbols should be named, how should memory management be arranged, what conventions should be used for splitting code into files and modules (with little extra design issues involved in structuring header files and include relations, in case you're doing C/C++), what kind of build system should be used, which unit test framework should be chosen and which third party libraries should be chosen for the very commonly needed stuff that's nevertheless not included in the language's standard library since it was standardized somewhere in the late 80s. Having all this stuff basically solved out of the box makes it very easy to start cranking out actual solutions with Go, even though none of that is particularly interesting from a programming language design standpoint.

StavrosK 14y ago

As a long-time Python programmer, I tried Go recently for something that needed large amounts of concurrency (a hosted version of hubot: http://instabot.stochastictechnologies.com http://instabot.stochastictechnologies.com), and I have to say, I am very pleasantly surprised. The type system was a bit cumbersome, after coming from Python, especially having to wrangle with pointers after not using them ever, but it's nothing you don't get used to. I'm still not sure how much I gain from static typing, but I'm willing to bear it out. Channels and goroutines, however, were an absolute dream to use. The entire IRC frontend runs off one process, which, I am led to believe, will basically never need anything more (it just proxies messages from IRC to the backend and back). Communication with the processes was fantastically easy, creating, launching and reasoning about goroutines is, again, very straightforward, and all this feel very much like a first-class citizens. Python has gevent too, and it suited me very well, but Go feels more integrated and better done.

slurgfest 14y ago
I think what you gain from static typing is pretty much that you can compile your programs and run without a fat interpreter. Note - I am not saying that is the only possible benefit of static typing anywhere, e.g. in Haskell - this is more in line with C, you are doing type declarations to cue the compiler rather than to realize some utopian test-free development methodology.
- StavrosK 14y ago
  Oh, definitely, I'm just not sure it gains that much speed compared to Python. I'd expect Go's speed to be on par with C, but, from what I understand, it's more like PyPy. Of course, this is just from what I hear, I haven't run any benchmarks. Does anyone have more details about this?

KlausTrainer 14y ago

Maybe the website wouldn't be down right now if it'd run on Go.

api 14y ago

C is boring too, in all the right ways. I think Go could be what we've been waiting for: C 2.0.

ntrel 14y ago
C's preprocessor means C code can often do interesting tricks, such as the X macro: http://www.drdobbs.com/the-new-c-x-macros/184401387 http://www.drdobbs.com/the-new-c-x-macros/184401387 There are tons of other interesting uses for macros. Obviously I'd rather a language had safer equivalents to a C preprocessor.

charlieflowers 14y ago

The thing that makes me pull back from trying Go is the fact that it has no exceptions and no other feature for handling errors (correct me if I'm wrong). Ugh! I can't imagine going back to the days when I had to call a function, check its return value to see whether there was an error or not, then, if no error, proceed to the next function call, check it for error, and so on. I know exceptions were a source of "complexity", and you could say that Maybe monads or other programming attempts to solve the problem increase complexity too. But to just punt and go back to doing it the ugly, unmaintainable brute force way? I just find that hard to swallow.