15 ms·

A year with Go

237 points by FraaJad 11y ago

Arzh 11y ago
The point isn't about learning something new. It's about trying to apply those things into a language they think is easier to work with.
- eloff 11y ago
  I'd argue the point is the opposite of learning new things. As the Go team themselves say, Go is an engineering project. It's about sticking to well understood, well defined ideas that allow large teams of typical skill to develop and maintain good software. Go is boring compared to some other languages that push the envelope and try new things. But that can be a good thing if you start thinking like the business owner instead of a code monkey.
  - 0xdeadbeefbabe 11y ago
    Most people won't see it this way, but not pushing the envelope is a new thing.
  - masklinn 11y ago
    The problem is that Go doesn't use things which are well understood and well defined now (or were so 6 years ago when Go was released), it stopped its (partial collection) about 40 years ago.
smegel 11y ago
> if I wanted a language built around concurrency I’d use Erlang or Haskell. And if you wanted a concurrent language that wasn't a functional language what would you use?
- eloff 11y ago
  Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.
  - solarexplorer 11y ago
    Other languages like Clojure, Python and even Javascript are catching up to Go and are adding decent support for concurrency too. But I would definitely prefer a functional language for a project that involves a lot of concurrency. "not a functional language" is a weird requirement.
    - istvan__ 11y ago
      Are you talking about Clojure? :) I am not sure what is the fuss about functional vs. imperative, you can do both in Clojure, both ways have a place in the programming toolkit. I think about functional programming as a philosophy. Nobody is going to despite me if I use swap! in Clojure or I use a mutable variable. On the other hand even when I am in an imperative environment I tend to use functions that keep the state in the parameters so the state is explicit and visible rather than a hidden something inside a class.
      - solarexplorer 11y ago
        Yes Clojure, sorry about the typo! The difference is that with Haskell or Erlang you get hard guarantees about side effects, but access to imperative libraries is very difficult. So you are kind of locked in a small ecosystem. With Clojure, Scala or F# you need to be disciplined and don't really get many guarantees, but you can reuse lots of imperative code. It kind of depends what your priorities are, if it's correctness or development speed.
        codygman 11y ago
        > The difference is that with Haskell or Erlang you get hard guarantees about side effects, but access to imperative libraries is very difficult. In my experience creating Haskell bindings to say imperative c libraries is pretty easy. What imperative libraries have been hard to access for you personally?
        istvan__ 11y ago
        > The difference is that with Haskell or Erlang you get hard > guarantees about side effects, but access to imperative > libraries is very difficult. Well yes, I can just live without imperative libraries because it is so natural to have single assignment (in the same scope) that I do it even in other languages. Accessing imperative libraries is possible though, just think about the C libs. What would you implement in Erlang the imperative way or which library do you miss exactly? The ecosystem is definitely smaller, but you can get support, some of the smartest software guys hang out on the mailing lists and IRc as well. I got absolutely amazing help from both when we worked on a Erlang project. > It kind of depends what your priorities are, if > it's correctness or development speed. Yeah and also how much fun you want to have. :) Using Erlang is great but not many devs out there for hire, on the other side you have two seasoned Erlang devs they can do a lot. Contractors FTW! Btw. what about using ASN.1 with Erlang? How does that change the correctness / development speed?
- lxcid 11y ago
  Erlang is probably the only true object-oriented language. http://www.infoq.com/interviews/johnson-armstrong-oop http://www.infoq.com/interviews/johnson-armstrong-oop
  - zak_mc_kracken 11y ago
    > Erlang is probably the only true object-oriented language. And it's true because its creator says so right here, in this link!
    - vezzy-fnord 11y ago
      Or because it does satisfy much of the Kay criteria for OO and encourages such programming styles.
      - zak_mc_kracken 11y ago
        Nobody follows Kay's definition of OOP. And I bet you're going to say "But he coined the term!". Yes. He's still making up his own definition twenty years after the industry gave its own, so whatever he says on the topic is moot.
        vezzy-fnord 11y ago
        Several things to note here. Firstly, I don't know at what exact point did Kay come out in demystifying OO (1998 or so?), but the design principles of Smalltalk and messaging date back to publishing in 1974, with many references to it afterwards. Secondly, the idea that there is one singular definition of OO that the industry has standardized on is absurd. Object models differ semantically from language to language, even if some general motif of "encapsulation/inheritance/polymorphism" is present (though again, important subtleties abound - is encapsulation enforced or merely convention, how structural and nominal subtyping are modeled [mixins], etc.). But would you say that's the definition of OO? In fact, Kristen Nygaard who was the creator of the Simula language, an ALGOL extension, and now considered to be the first OO language (semantically in that it beefed up structs and other procedural nuances) considered object orientation to be a property of any system in general as opposed to language constructs. Thus, Erlang definitely does count as OO under that, too. So what definition do we follow, then? Who do we trust? Apparently this is a difficult problem: http://c2.com/cgi/wiki?DefinitionsForOo http://c2.com/cgi/wiki?DefinitionsForOo But by all means, Erlang embodies many OO design principles by certain important taxonomies - both Nygaard's and Kay's. If you're going to reject both, then you're going down murky waters.
- RyanZAG 11y ago
  Probably Java (or other JVM lang) running something like Disruptor for high performance, or actor based libraries like Akka for general use case. No numbers, but considering how it's used in nearly all the bigger tech and finance companies, I'm guessing it probably has more use as a highly concurrent platform than anything else discussed here.
  - tomphoolery 11y ago
    Another reason for their usage of the JVM could be because a lot of these languages specifically designed for concurrent programming either didn't exist or were in their infancy of real-world usage. Erlang was proprietary until 1998, and Haskell was not created by a large company. In the meantime, Sun was pushing Java everywhere they possibly could. So it makes sense that larger tech and financial firms, especially those who established themselves in the late 1990s (or descendants of such companies), would use the Java platform. There were also a lot more Java developers than Haskell developers, and there still are, and that's a big part of the decision-making process when choosing a platform.
    - pron 11y ago
      Forget familiarity, hot code loading, and the huge library ecosystem (the largest in computing history) compared to one of the tiniest, but Java's runtime monitoring is far, far ahead of anything Haskell (or any other language or platform) can provide, and while Erlang's is pretty impressive (a close second), it is still not on the same level as Java's.
  - smegel 11y ago
    The standard JVM's don't support lightweight threading (like Go's Goroutines)...so yeah while you can do concurrency with callbacks, or "actors" (callbacks with lipstick on), it's not quite the same thing.
    - wtetzner 11y ago
      You can use Quasar, which does bytecode instrumentation. http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/
webkike 11y ago
When I use Rust I am constantly annoyed by how limiting traits are in comparison to interfaces. I much prefer interfaces, which are a single type, as opposed to traits, which are sets of types.
- codingbinary 11y ago
  How do traits limit you? Could you give an example?
- kibwen 11y ago
  What do you mean by "sets of types"? Traits in Rust handle more duties than interfaces do in Go, but in their role as interfaces the only difference is that Rust traits are explicitly implemented whereas Go interfaces are implicitly implemented (i.e. nominal types vs structural types).
  - webkike 11y ago
    Take the following example from Go: type ExInterface interface { ... } type ExStruct { arr []ExInterface } Each element of arr need not be the same type, so long as it implements ExInterface. In Rust, the only thing I can do that is similar is: struct<t: ExTrait> ExStruct { arr: Vec<t>, } Which means that each element of arr not only has to implement ExTrait, but also has to be of consistent type with the rest of the elements. If I want the same level of flexibility the Go gives me, I need to make an enum of each possible type that arr can contain.
    - heinrich5991 11y ago
      You can do that by storing `Box<ExTrait>` in your vector. In fact, that's the equivalent of what Go does in your example.
      - webkike 11y ago
        That's fantastic to know. I might just switch back to rust because of this.
fishnchips 11y ago
> Good languages help evolve your approach to programming Go certainly taught me quite a bit about closures and programming to an interface.
mikeokner 11y ago
I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "teaching" language, nor would anyone call it "mature" at this point, but it does fill a niche and fills it pretty well. http://blog.disqus.com/post/51155103801/trying-out-this-go-thing http://blog.disqus.com/post/51155103801/trying-out-this-go-t...
- zak_mc_kracken 11y ago
  In my experience, Go is a lot more attractive as an upgrade from Ruby or Python. It's a very steep downgrade from Java on all points imaginable: type system, exceptions, genericity, garbage collector and runtime, tooling, IDE's, etc...
  - nostrademons 11y ago
    It's an upgrade in terms of compile times, deployment simplicity, conciseness, concurrency, etc. Some people care about such things.
    - threeseed 11y ago
      Compile times are largely irrelevant if you use something like JRebel, Play, Tomcat or the many other frameworks that support hot reloading. And Java is far broader and more flexible at concurrency than Go with libraries like Quasar, LMAX Disruptor and the many HFT contributed ones. Let's also not forget that Java is significantly faster, has every library under the sun, has a dependency system that actually makes sense and you have seamless interop between multiple languages e.g. Ruby, Python, Scala, Clojure. Anyone who thinks Go is an upgrade to Java is woefully misinformed.
      - caoilte 11y ago
dvt 11y ago
Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it almost at all for the past couple of years :(
- baudehlo 11y ago
  HN was the same about Node too. In a year we will see the same articles about Rust.
  - sanderjd 11y ago
    See also: AngularJS, Rails, etc. A lot of this is just because things that a technology makes convenient fade into the background after awhile because you know longer feel the pain you felt before you had them, but you are actively reminded of the things that annoy you about a technology multiple times a day. For example, with Go, fast static compilation and "just works" deployment fade, while the copy-paste-tweak pattern for generic behavior continues to bite. For Angular, you start to forget how much easier it made defining modular view components and having up-to-date data everywhere, while actively finding complexity and performance frustrating. I'm sure you're right about Rust, and that people will be down on lifetime annotation burden, painful compilation times, painful data structure nesting, the complexity of unsafe code, and other things, while forgetting all the times things are actually easier, more performant, and safer due to all that language support. I see it as a natural damping curve: at first things seem peachier than they really are, then they seem much more frustrating than they need to be, then you come to terms with their unique trade-off of strengths and weaknesses. What I would like to know – if anyone here has discovered such a thing – is a way to skip to the last step more quickly.
    - baudehlo 11y ago
      The thing you want is called "getting old". You realize the benefits of certain things and know about the weaknesses before they are even brought up. Sadly this can't easily be taught - it is just slowly learned. And yet us old farts continue to be shunned in many parts of the industry (perhaps because we are grumpy old curmudgeons who have seen it all before).
deleted 11y ago
[deleted]
- mdcox 11y ago
  I totally agree (except for the new-grad conspiracy.) I use Go whenever I need to do something small that requires a simple server or API interaction. Especially if it requires alot of concurrency. It's still a joy to use when I need to get something churned out quickly. The biggest thing it gave me though, was something new but accessible that wasn't Ruby, Python or JS. It made me think about pointers, and gave me insight to just how complicated strings and growable arrays are under the hood instead of just being givens like in Ruby. It simplified concurrency and parallelization enough that I was able to dive in and learn the concepts which I was then able to use to dig deeper with other languages that don't have the nice channels/select built in. I've come to realize that, in my learning at least, there are thresholds of information that people get stuck at, but once they cross you get a flood of improvement. Go allowed me to stop thinking only within the code context, but also in the machine context. Now a large amount of my side projects are in C or Rust, and even my day job writing higher level languages has benefited greatly from the new ability to understand the moving parts. It's not going to give you a compsci education, but it'll give you that intermediate step you need to wade into that territory.
4ad 11y ago
> I also, apparently, don’t understand Go’s pointers (C pointers I understand fine). I’ve literally had cases where just dropping a * in front of something has made it magically work (but it compiled without one). Why the heck is Go making me care about pointers at all if it is a GC’d language? Well, sorry, but if that's your level of understanding after one year of Go, I'm furious I wasted time to read your article up to that point.
- baby 11y ago
  As I understand it, GO makes it so you can use both a pointer or the object itself to access it methods. And when you define an object method (or I don't know how it's called when you do this:) func (*string) uppercase(){ // make uppercase } Then by saying you use a pointer means you will modify the value when you do this: mystring.uppercase() So it's not really pointers, it's more an idea of pointers.
  - xrstf 11y ago
    Things get ugly when your code grows. I had cases where I started with passing pointers to structs around directly, but at some decided that having dedicated interfaces would be better. But as soon as you're talking interface, pointers don't work as expected anymore, because Go (at least that's how I'm explaining it in my head) passes magic interface values to functions. So you can't just change `func foo(s MyStruct)` to `func foo(s MyInterface)`, but rather you probably want `func foo(s MyInterface)`. Even though you are still explicitely passing a pointer when calling foo() and whatever you're doing with s inside of foo() is working on a pointer -- which your own function declaration doesn't even tell you anymore. This is one of the things that confuses the hell out of me when using Go.
    - twic 11y ago
      One of the most unhelpful things about Go's pointer syntax is that it collides with HN's italics syntax. Hence, in your second paragraph, i see declarations which differ only in the slope of the type. Really, does nobody think of this when designing a language?
nemothekid 11y ago
>Adding proper mutexes to some of our code in production slowed things down so much it was actually better to just run the service under daemontools and let the service crash/restart. Can the author explain this bit some more? If adding mutexes slows down your code to the point where you would rather just deal with data corruption/races it seems to me that there are issues with your code, not the language.
- pcwalton 11y ago
  Yeah, that seems weird. A properly implemented mutex is one atomic instruction in the uncontended path to lock and one more to unlock. And if you remove the mutex, you're turning "the contended path" into "the path that blows up your program". Atomic instructions can be painful on, for example, ARM (where they turn into load linked/store conditional loop + memory barrier) but they shouldn't be too bad on x86 servers. (I have no idea how Go implements mutexes, though.)
  - seanmcdirmid 11y ago
    It is not unprecedented, e.g. see: http://en.wikipedia.org/wiki/Crash-only_software http://en.wikipedia.org/wiki/Crash-only_software Martin Rinard at MIT has done a lot of work in this area. It can be safe if you can rollback to a good state to avoid data corruption. Glitch, my current project, does not bother with reader locks for multi-core execution; instead it can rollback and retry when a write-after-read is detected effects are logged (dependencies are traced so write-after-reads can be detected). It has performance benefits if you can amortize the book keeping overhead, and we need to do it anyways to support live programming (see: http://research.microsoft.com/en-us/people/smcdirm/managedtime.aspx http://research.microsoft.com/en-us/people/smcdirm/managedti...).
    - nemothekid 11y ago
      I'm aware of crash only software (isn't this how Erlang/OTP does things?), however this doesn't seem to be what the OP intended. Running your code without caring about data races means your data can be corrupted and program might not crash.
nickysielicki 11y ago
> "I just don’t understand the point of Go. If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell." Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay. I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is stupid easy to pick up for anyone who has worked with C/C++/C#/Java/Python/Ruby, which, by no exaggeration, probably encompasses every programmer alive. Meanwhile, Haskell and Erlang look like gibberish to most programmers. And I'll admit, that's a lacking argument. Functional languages cannot be said to be bad just because most people don't understand the functional paradigm. But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go. And given the lack of flair in go, it's the langauge that lends itself to being maintainable. You won't see anything like in python or perl where you're almost expected to abuse the langauge internals (see this awesome example in python [0]). That's completely by design. [1][2] (scroll up to see the quote by Rob Pike) If you have a team of a dozen guys working on a project with thousands of lines, your priority is not just performance (Go is quick enough [3]). It's probably not elegance either. It's software that documents itself. I used to work as a systems administrator for my schools engineering department. We would deal with fixing perl scripts dating back to the 90's. As students came and went, the result was hack jobs on top of hack jobs by students who are now in their 30's. I hated it. I would commonly have to rewrite scripts because over the years the basic flow of the program became completely asinine. That's exactly where go does well. Go is a langauge for people who don't want to have to deal with abuses of the language that their coworkers put in place. Go is a language that understands that for programmers, maintaining code means fixing bugs and fixing bugs tends to boil down to hacky solutions. Go ensures that those quick fixes aren't hacks. > "The only place I can see Go shining is for stuff like portable command line utilities where you want to ship a static binary that Just Works(tm). For interactive tasks I think it would be fine, I just don’t think it is particularly well suited to long-running servery things." I really don't understand why he feels that way. I don't see the distinction. > "It also probably looks attractive to Ruby/Python/Java developers, which is where I think a lot of Go programmers come from. Speaking of Java, I wouldn’t be surprised to see Go end up as the ‘new Java’ given the easier deploy story and the similar sort of vibe I get from the language. If you’re just looking for a ‘better’ Ruby/Python/Java, Go might be for you, but I would encourage you to look further afield." This reminds me of The Story of Mel [4]. If you're someone who enjoys programming and are writing the code for fun, I agree. Find the most unique language and do it in the most elegant way. Programming is almost an art, and if you're trying to be artistic, unique langauges are great for it. But not all software is artistic. > "Good languages help evolve your approach to programming; LISP shows you the idea of code as data, C teaches you about working with the machine at a lower level, Ruby teaches you about message passing & lambdas, Erlang teaches you about concurrency and fault tolerance, Haskell teaches you about real type systems and purity, Rust presumably teaches you about sharing memory in a concurrent environment. I just don’t think I got much from learning Go." I don't think that all langauges need to be learning experiences. Sometimes you just need to get shit done. [0]: https://benkurtovic.com/2014/06/01/obfuscating-hello-world.html https://benkurtovic.com/2014/06/01/obfuscating-hello-world.h... [1]: https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article [2]: http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/#fn-601-1 http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in... [3]: https://benchmarksgame.alioth.debian.org/u64q/go.html https://benchmarksgame.alioth.debian.org/u64q/go.html [4]: http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html
namelezz 11y ago
I always find it's difficult to navigate Go repositories on GitHub. Because there can be several source files under a package it's difficult to look for an implementation of a function or method. For Java, I can easily guess where the methods are by looking at import statements.
- misframer 11y ago
  godoc is very helpful for this. You can click on the name of a type or function and it will take you to the definition.
- kjksf 11y ago
  I friend of mine wrote a tool to fix that. See http://gotools.org/github.com/kjk/fofou http://gotools.org/github.com/kjk/fofou for example (just prepend http://gotools.org/ http://gotools.org/ to any Go import path). Then you can use Ctrl-f (Cmd-F on mac) search built-in browser to look for things. It doesn't work for large repositories but most of them aren't.
rkapsoro 11y ago
Go is great and all, but I'm really only using it until Rust is ready.
- jaytaylor 11y ago
  What are your criteria for "ready"?
- artursapek 11y ago
  Rust 1.0 came out recently. What are you waiting for?
  - fsaintjacques 11y ago
    Complete, stable and mature standard lib.
ffn 11y ago
If backend programming was epic fiction, then right now, the world is divided into the following countries: The Kingdom of Java, The United Languages of .Net, and the Confederacy of the Scripting Tongue (where racial tensions are crackle under the temporary truce between Ruby, Python, Javascript, Lua, etc.). For the past decade, these three kingdoms constantly struggled against each other for the most precious resource of all: developer mind-share. But what they didn't know and couldn't prevent, was that their world would soon become (neigh, has already become) the battle ground of 3 ultra-advanced warring alien species: Go, Rust, and Elixir. Backed by unimaginably powerful forces (except Elixir, which is just open-source by Poland's own Jose Valim), the upstart alien languages threaten to herald in a terrifying future for the current 3 powerhouses. OP's article, and the fact that lots of people are agreeing, is a sign that one of the invading aliens is weakening.
- ericdschmidt 11y ago
  I want to watch this movie. What about Pony?
- ericdschmidt 11y ago
  I want to watch this movie. What about Pony?
fixxer 11y ago
Today, I got a request for a secure message passing service from our CTO. My group, which is a small team of 2 *nix geeks in a company with ~20 mostly c# developers, has become a bit of a skunkworks operation as we have been responding to external constraints and forced to move quickly. I was able to implement the service per the provided spec in 179 lines of Go in about ~2 hours. Stress tests passed. The job is done. We march on. Could I have written this service in C++? Absolutely, but it would have taken me 20 hours to get to the same level of confidence. Maybe some could do it on 2 hours; I'm admittedly not a great C++ developer or frequent user. Could I have written it in Python? Sure, but I would have had to scale and put it behind a load balancer, adding complexity to get equivalent performance. From what I've seen of Rust, I like it and plan to give it more time now that it is stable. I haven't spent time with D. I played with Erlang. I don't care for Haskell for anything remotely related to "work", but I don't dispute that it has a place in computer science. In my 2 years with Go, this is not my first positive experience. I have found that Go works well for cranking out high fidelity, snappy services like this. I think this is the result of the language's constraints enforcing simple patterns. Unlike C++ and Python, there are not a huge number of ways to accomplish tasks (at least not ways that feel natural). Take it or leave it, but I like Go (for certain things).
- nly 11y ago
  > Could I have written this service in C++? Probably. C++ productivity really relies on knowing good libraries, and having the freedom to use them. Without details, I'd wager you could have done it in 300-400 lines. If you gave a brief overview of what you needed, I'd describe my first instinct for doing it in C++.
- istvan__ 11y ago
  Yes, correctly exposed concurrency is a pretty amazing thing. CSP ftw! You could as easily do it in Clojure, Erlang or any language that supports that.
- threeseed 11y ago
  I don't understand what I am supposed to take away from this though. If you were a strong C, C++, Java, Scala, Clojure etc developer you could equally deliver a highly scalable solution in 2 hours. I haven't seen anything yet to show why Go is fundamentally easier to deliver solutions except for single binary development which isn't really an issue for server side development.
tptacek 11y ago
I could be wrong, but I feel like when people talk about how great the Golang tooling is, what they're really saying is "the compiles are instantaneous". I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous. Write a better one! Golang is not an especially impressive programming language --- as a language. But it seems to me like it is an undeniably impressive programming tool.
- jballanc 11y ago
  I completely agree. Some languages are written to adhere to an ideal (everything is lists), and make sacrifices in order to stick to that ideal. Some are written to be close to the metal, or to be as abstract and flowery as possible, and make different sacrifices. Every language has some primary goal, and all the rest must bend to accommodate that goal. Go's primary goal is: excellent tooling.
  - serge2k 11y ago
    except for, apparently, poor code coverage tools?
    - NateDad 11y ago
      The coverage tool is fine. He didn't really explain the problem well. Coverage is per package, and only counts coverage from tests in that package. This makes sense because packages are independent and you can't count on another package to test yours.
  - waps 11y ago
    But Go's tools suck ... Debuggers - http://blog.securitymouse.com/2014/10/golang-debugging-turning-pennies-into-gs.html http://blog.securitymouse.com/2014/10/golang-debugging-turni... Code analysis tools - aside from "go fmt" ... don't know any. There's certainly nothing compared to the C++ tooling. Versioning - nonexistent Editors, IDEs - nonexistent
- deleted 11y ago
  [deleted]
coldtea 11y ago
It's amazing how Go caught on. It's not well designed -- lots of special cases reserved just for the compiler, some bizarro decisions, etc. It's not modern (with the possitive associates of modern, not fadish, and modern being "the last 30 years of experience" which is still like a millenium in IT years). It's implementation is not great either. Not a very good compiler, not a very good GC, not good tooling. My theory is it caught on for 4 reasons: 1) It came from Google, and with some famous names to top. This got it initial publicity in programming sites and media, and Google then coughed for conferences, a spot on I/O etc -- so it caught lots of eyeballs, something independent languages don't have a chance to do. 2) It produces static binaries and this was a real need for lots of use cases. 3) It's easy to get started with, and made converts from scripting languages feel empowered, as if they were "real programmers" writing C, what with "pointers" and static types. 4) It makes writing parallel code for some uses cases easy, which is a good fit for some infrastructure/services apps. (I don't think most teams outside of Google and some C++ or Scala shops have had any beef with "long compile times" for that to have been a major factor. Though it played to the hype of it being "just like a scripting language").
- djhworld 11y ago
  > It's easy to get started with, and made converts from scripting languages feel empowered, as if they were "real programmers" writing C, what with "pointers" and static types. What is wrong with this? Exposing people to pointers and static types might give them confidence when writing or reading in "real programmers" code in C I find the level of sneery nose turning in this thread quite abhorrent to be honest.
  - nulltype 11y ago
    There seems to be an idea that some ways of telling your computer what to do are too foppish and that if you are serious about it you use a language from 40 years ago. Of course that's probably what the assembly programmers said about C and there aren't many of those left anymore.
  - pcwalton 11y ago
    > What is wrong with this? Exposing people to pointers and static types might give them confidence when writing or reading in "real programmers" code in C I don't see it as sneery nose-turning. Rather I see it as an acknowledgement that the real difficulty of C isn't pointers but rather is manual memory management, which Golang doesn't prepare you for.
jtwebman 11y ago
Sweet, I'll stick to learning Elixir with some (Erlang)!
samora 11y ago
I think a lot of us miss the Go point. There is nothing special about Go. It's simple and just works. Every time I used Go for a project it just worked. No fuss. With very little effort. And that's the point.
- gambiter 11y ago
  But that doesn't answer any of the (very valid) points raised in the article? Go is interesting as a replacement for a scripting language, perhaps. But it seems very lacking in many other areas. All of the points in the article, plus what libraries are available. I think some of it could be explained by it being a young language, but if that's the case, why is it getting the adoption it has so far? Just because it came from Google?
  - rakoo 11y ago
    Because it has allowed so many of us to significantly raise the ratio "Amount of time I care about my project"/"Amount of time I care about something other than my project (typically, the language itself)". Go is the poster child for Worse is Better. It's ugly, inconsistent, feels naughty at times (all those copy-pastes ! It's so un-DRY !) but it gets shit done.
tapirl 11y ago
> Why the heck is Go making me care about pointers at all if it is a GC’d language? Apparently, the author doesn't understand how pointers work in Golang. He should read this article: http://openmymind.net/Things-I-Wish-Someone-Had-Told-Me-About-Go/ http://openmymind.net/Things-I-Wish-Someone-Had-Told-Me-Abou... . In short, golang pointer is neither c pointer nor java reference.
tmsh 11y ago
What's confusing about Go, in comparing it to other languages, is that it's a minimum orthogonal refactor of a language. It was born out smart engineers observing the web and other languages for decades and thinking that they needed something low level but high level enough. It's built staring precisely at the past two decades. C, C++, Java, Python, and an appreciation of formal specs over frameworks form Go. Most languages to perform professionally in you have to know what not to do (not use C++ templates too much, not give into verbosity in hierarchies in Java, not use the GIL, etc.). In Go, because it is a relatively clean refactor, you don't have to worry about this. But you do have to invent your own smaller libraries for what you want to do sometimes. Because it's a younger language. This is good though if you like programming and stacking lego pieces on you way to stacking paper.
larryweya 11y ago
I've had a keen interest in go but haven't used it for anything serious. My impression of it is that its a great replacement for languages like Python and is great at getting things running fast but I have to agree that it doesn't feel like the kind language I wouldn't want to write a large code base in. My huge interest in it is around the single binary deployment and its concurrency model. The language itself I find a bit quirky in some places (some data structures are passed by ref while other by value) and I like my languages concise and elegant. This post got me to have a second look at Elixir and I spent the whole day going though its documentation and prototyping an idea I wanted to implement in go, specifically because of go's concurrency model. And frankly ELixir is exactly the right fit for me, not only for this case but generally as a language with the kind of elegance and expressiveness I'm drawn to.

237 points by FraaJad 11y ago

Arzh 11y ago

The point isn't about learning something new. It's about trying to apply those things into a language they think is easier to work with.

eloff 11y ago
I'd argue the point is the opposite of learning new things. As the Go team themselves say, Go is an engineering project. It's about sticking to well understood, well defined ideas that allow large teams of typical skill to develop and maintain good software. Go is boring compared to some other languages that push the envelope and try new things. But that can be a good thing if you start thinking like the business owner instead of a code monkey.
- 0xdeadbeefbabe 11y ago
  Most people won't see it this way, but not pushing the envelope is a new thing.
- masklinn 11y ago
  The problem is that Go doesn't use things which are well understood and well defined now (or were so 6 years ago when Go was released), it stopped its (partial collection) about 40 years ago.

smegel 11y ago

> if I wanted a language built around concurrency I’d use Erlang or Haskell. And if you wanted a concurrent language that wasn't a functional language what would you use?

eloff 11y ago
Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.
- solarexplorer 11y ago
  Other languages like Clojure, Python and even Javascript are catching up to Go and are adding decent support for concurrency too. But I would definitely prefer a functional language for a project that involves a lot of concurrency. "not a functional language" is a weird requirement.
  - istvan__ 11y ago
    Are you talking about Clojure? :) I am not sure what is the fuss about functional vs. imperative, you can do both in Clojure, both ways have a place in the programming toolkit. I think about functional programming as a philosophy. Nobody is going to despite me if I use swap! in Clojure or I use a mutable variable. On the other hand even when I am in an imperative environment I tend to use functions that keep the state in the parameters so the state is explicit and visible rather than a hidden something inside a class.
    - solarexplorer 11y ago
      Yes Clojure, sorry about the typo! The difference is that with Haskell or Erlang you get hard guarantees about side effects, but access to imperative libraries is very difficult. So you are kind of locked in a small ecosystem. With Clojure, Scala or F# you need to be disciplined and don't really get many guarantees, but you can reuse lots of imperative code. It kind of depends what your priorities are, if it's correctness or development speed.
      - codygman 11y ago
        > The difference is that with Haskell or Erlang you get hard guarantees about side effects, but access to imperative libraries is very difficult. In my experience creating Haskell bindings to say imperative c libraries is pretty easy. What imperative libraries have been hard to access for you personally?
      - istvan__ 11y ago
        > The difference is that with Haskell or Erlang you get hard > guarantees about side effects, but access to imperative > libraries is very difficult. Well yes, I can just live without imperative libraries because it is so natural to have single assignment (in the same scope) that I do it even in other languages. Accessing imperative libraries is possible though, just think about the C libs. What would you implement in Erlang the imperative way or which library do you miss exactly? The ecosystem is definitely smaller, but you can get support, some of the smartest software guys hang out on the mailing lists and IRc as well. I got absolutely amazing help from both when we worked on a Erlang project. > It kind of depends what your priorities are, if > it's correctness or development speed. Yeah and also how much fun you want to have. :) Using Erlang is great but not many devs out there for hire, on the other side you have two seasoned Erlang devs they can do a lot. Contractors FTW! Btw. what about using ASN.1 with Erlang? How does that change the correctness / development speed?
lxcid 11y ago
Erlang is probably the only true object-oriented language. http://www.infoq.com/interviews/johnson-armstrong-oop http://www.infoq.com/interviews/johnson-armstrong-oop
- zak_mc_kracken 11y ago
  > Erlang is probably the only true object-oriented language. And it's true because its creator says so right here, in this link!
  - vezzy-fnord 11y ago
    Or because it does satisfy much of the Kay criteria for OO and encourages such programming styles.
    - zak_mc_kracken 11y ago
      Nobody follows Kay's definition of OOP. And I bet you're going to say "But he coined the term!". Yes. He's still making up his own definition twenty years after the industry gave its own, so whatever he says on the topic is moot.
      - vezzy-fnord 11y ago
        Several things to note here. Firstly, I don't know at what exact point did Kay come out in demystifying OO (1998 or so?), but the design principles of Smalltalk and messaging date back to publishing in 1974, with many references to it afterwards. Secondly, the idea that there is one singular definition of OO that the industry has standardized on is absurd. Object models differ semantically from language to language, even if some general motif of "encapsulation/inheritance/polymorphism" is present (though again, important subtleties abound - is encapsulation enforced or merely convention, how structural and nominal subtyping are modeled [mixins], etc.). But would you say that's the definition of OO? In fact, Kristen Nygaard who was the creator of the Simula language, an ALGOL extension, and now considered to be the first OO language (semantically in that it beefed up structs and other procedural nuances) considered object orientation to be a property of any system in general as opposed to language constructs. Thus, Erlang definitely does count as OO under that, too. So what definition do we follow, then? Who do we trust? Apparently this is a difficult problem: http://c2.com/cgi/wiki?DefinitionsForOo http://c2.com/cgi/wiki?DefinitionsForOo But by all means, Erlang embodies many OO design principles by certain important taxonomies - both Nygaard's and Kay's. If you're going to reject both, then you're going down murky waters.
RyanZAG 11y ago
Probably Java (or other JVM lang) running something like Disruptor for high performance, or actor based libraries like Akka for general use case. No numbers, but considering how it's used in nearly all the bigger tech and finance companies, I'm guessing it probably has more use as a highly concurrent platform than anything else discussed here.
- tomphoolery 11y ago
  Another reason for their usage of the JVM could be because a lot of these languages specifically designed for concurrent programming either didn't exist or were in their infancy of real-world usage. Erlang was proprietary until 1998, and Haskell was not created by a large company. In the meantime, Sun was pushing Java everywhere they possibly could. So it makes sense that larger tech and financial firms, especially those who established themselves in the late 1990s (or descendants of such companies), would use the Java platform. There were also a lot more Java developers than Haskell developers, and there still are, and that's a big part of the decision-making process when choosing a platform.
  - pron 11y ago
    Forget familiarity, hot code loading, and the huge library ecosystem (the largest in computing history) compared to one of the tiniest, but Java's runtime monitoring is far, far ahead of anything Haskell (or any other language or platform) can provide, and while Erlang's is pretty impressive (a close second), it is still not on the same level as Java's.
- smegel 11y ago
  The standard JVM's don't support lightweight threading (like Go's Goroutines)...so yeah while you can do concurrency with callbacks, or "actors" (callbacks with lipstick on), it's not quite the same thing.
  - wtetzner 11y ago
    You can use Quasar, which does bytecode instrumentation. http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/

webkike 11y ago

When I use Rust I am constantly annoyed by how limiting traits are in comparison to interfaces. I much prefer interfaces, which are a single type, as opposed to traits, which are sets of types.

codingbinary 11y ago
How do traits limit you? Could you give an example?
kibwen 11y ago
What do you mean by "sets of types"? Traits in Rust handle more duties than interfaces do in Go, but in their role as interfaces the only difference is that Rust traits are explicitly implemented whereas Go interfaces are implicitly implemented (i.e. nominal types vs structural types).
- webkike 11y ago
  Take the following example from Go: type ExInterface interface { ... } type ExStruct { arr []ExInterface } Each element of arr need not be the same type, so long as it implements ExInterface. In Rust, the only thing I can do that is similar is: struct<t: ExTrait> ExStruct { arr: Vec<t>, } Which means that each element of arr not only has to implement ExTrait, but also has to be of consistent type with the rest of the elements. If I want the same level of flexibility the Go gives me, I need to make an enum of each possible type that arr can contain.
  - heinrich5991 11y ago
    You can do that by storing `Box<ExTrait>` in your vector. In fact, that's the equivalent of what Go does in your example.
    - webkike 11y ago
      That's fantastic to know. I might just switch back to rust because of this.

fishnchips 11y ago

> Good languages help evolve your approach to programming Go certainly taught me quite a bit about closures and programming to an interface.

mikeokner 11y ago

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "teaching" language, nor would anyone call it "mature" at this point, but it does fill a niche and fills it pretty well. http://blog.disqus.com/post/51155103801/trying-out-this-go-thing http://blog.disqus.com/post/51155103801/trying-out-this-go-t...

zak_mc_kracken 11y ago
In my experience, Go is a lot more attractive as an upgrade from Ruby or Python. It's a very steep downgrade from Java on all points imaginable: type system, exceptions, genericity, garbage collector and runtime, tooling, IDE's, etc...
- nostrademons 11y ago
  It's an upgrade in terms of compile times, deployment simplicity, conciseness, concurrency, etc. Some people care about such things.
  - threeseed 11y ago
    Compile times are largely irrelevant if you use something like JRebel, Play, Tomcat or the many other frameworks that support hot reloading. And Java is far broader and more flexible at concurrency than Go with libraries like Quasar, LMAX Disruptor and the many HFT contributed ones. Let's also not forget that Java is significantly faster, has every library under the sun, has a dependency system that actually makes sense and you have seamless interop between multiple languages e.g. Ruby, Python, Scala, Clojure. Anyone who thinks Go is an upgrade to Java is woefully misinformed.
    - caoilte 11y ago

dvt 11y ago

Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it almost at all for the past couple of years :(

baudehlo 11y ago
HN was the same about Node too. In a year we will see the same articles about Rust.
- sanderjd 11y ago
  See also: AngularJS, Rails, etc. A lot of this is just because things that a technology makes convenient fade into the background after awhile because you know longer feel the pain you felt before you had them, but you are actively reminded of the things that annoy you about a technology multiple times a day. For example, with Go, fast static compilation and "just works" deployment fade, while the copy-paste-tweak pattern for generic behavior continues to bite. For Angular, you start to forget how much easier it made defining modular view components and having up-to-date data everywhere, while actively finding complexity and performance frustrating. I'm sure you're right about Rust, and that people will be down on lifetime annotation burden, painful compilation times, painful data structure nesting, the complexity of unsafe code, and other things, while forgetting all the times things are actually easier, more performant, and safer due to all that language support. I see it as a natural damping curve: at first things seem peachier than they really are, then they seem much more frustrating than they need to be, then you come to terms with their unique trade-off of strengths and weaknesses. What I would like to know – if anyone here has discovered such a thing – is a way to skip to the last step more quickly.
  - baudehlo 11y ago
    The thing you want is called "getting old". You realize the benefits of certain things and know about the weaknesses before they are even brought up. Sadly this can't easily be taught - it is just slowly learned. And yet us old farts continue to be shunned in many parts of the industry (perhaps because we are grumpy old curmudgeons who have seen it all before).

deleted 11y ago

[deleted]

mdcox 11y ago
I totally agree (except for the new-grad conspiracy.) I use Go whenever I need to do something small that requires a simple server or API interaction. Especially if it requires alot of concurrency. It's still a joy to use when I need to get something churned out quickly. The biggest thing it gave me though, was something new but accessible that wasn't Ruby, Python or JS. It made me think about pointers, and gave me insight to just how complicated strings and growable arrays are under the hood instead of just being givens like in Ruby. It simplified concurrency and parallelization enough that I was able to dive in and learn the concepts which I was then able to use to dig deeper with other languages that don't have the nice channels/select built in. I've come to realize that, in my learning at least, there are thresholds of information that people get stuck at, but once they cross you get a flood of improvement. Go allowed me to stop thinking only within the code context, but also in the machine context. Now a large amount of my side projects are in C or Rust, and even my day job writing higher level languages has benefited greatly from the new ability to understand the moving parts. It's not going to give you a compsci education, but it'll give you that intermediate step you need to wade into that territory.

4ad 11y ago

> I also, apparently, don’t understand Go’s pointers (C pointers I understand fine). I’ve literally had cases where just dropping a * in front of something has made it magically work (but it compiled without one). Why the heck is Go making me care about pointers at all if it is a GC’d language? Well, sorry, but if that's your level of understanding after one year of Go, I'm furious I wasted time to read your article up to that point.

baby 11y ago
As I understand it, GO makes it so you can use both a pointer or the object itself to access it methods. And when you define an object method (or I don't know how it's called when you do this:) func (*string) uppercase(){ // make uppercase } Then by saying you use a pointer means you will modify the value when you do this: mystring.uppercase() So it's not really pointers, it's more an idea of pointers.
- xrstf 11y ago
  Things get ugly when your code grows. I had cases where I started with passing pointers to structs around directly, but at some decided that having dedicated interfaces would be better. But as soon as you're talking interface, pointers don't work as expected anymore, because Go (at least that's how I'm explaining it in my head) passes magic interface values to functions. So you can't just change `func foo(s MyStruct)` to `func foo(s MyInterface)`, but rather you probably want `func foo(s MyInterface)`. Even though you are still explicitely passing a pointer when calling foo() and whatever you're doing with s inside of foo() is working on a pointer -- which your own function declaration doesn't even tell you anymore. This is one of the things that confuses the hell out of me when using Go.
  - twic 11y ago
    One of the most unhelpful things about Go's pointer syntax is that it collides with HN's italics syntax. Hence, in your second paragraph, i see declarations which differ only in the slope of the type. Really, does nobody think of this when designing a language?

nemothekid 11y ago

>Adding proper mutexes to some of our code in production slowed things down so much it was actually better to just run the service under daemontools and let the service crash/restart. Can the author explain this bit some more? If adding mutexes slows down your code to the point where you would rather just deal with data corruption/races it seems to me that there are issues with your code, not the language.

pcwalton 11y ago
Yeah, that seems weird. A properly implemented mutex is one atomic instruction in the uncontended path to lock and one more to unlock. And if you remove the mutex, you're turning "the contended path" into "the path that blows up your program". Atomic instructions can be painful on, for example, ARM (where they turn into load linked/store conditional loop + memory barrier) but they shouldn't be too bad on x86 servers. (I have no idea how Go implements mutexes, though.)
- seanmcdirmid 11y ago
  It is not unprecedented, e.g. see: http://en.wikipedia.org/wiki/Crash-only_software http://en.wikipedia.org/wiki/Crash-only_software Martin Rinard at MIT has done a lot of work in this area. It can be safe if you can rollback to a good state to avoid data corruption. Glitch, my current project, does not bother with reader locks for multi-core execution; instead it can rollback and retry when a write-after-read is detected effects are logged (dependencies are traced so write-after-reads can be detected). It has performance benefits if you can amortize the book keeping overhead, and we need to do it anyways to support live programming (see: http://research.microsoft.com/en-us/people/smcdirm/managedtime.aspx http://research.microsoft.com/en-us/people/smcdirm/managedti...).
  - nemothekid 11y ago
    I'm aware of crash only software (isn't this how Erlang/OTP does things?), however this doesn't seem to be what the OP intended. Running your code without caring about data races means your data can be corrupted and program might not crash.

nickysielicki 11y ago

> "I just don’t understand the point of Go. If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell." Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay. I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is stupid easy to pick up for anyone who has worked with C/C++/C#/Java/Python/Ruby, which, by no exaggeration, probably encompasses every programmer alive. Meanwhile, Haskell and Erlang look like gibberish to most programmers. And I'll admit, that's a lacking argument. Functional languages cannot be said to be bad just because most people don't understand the functional paradigm. But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go. And given the lack of flair in go, it's the langauge that lends itself to being maintainable. You won't see anything like in python or perl where you're almost expected to abuse the langauge internals (see this awesome example in python [0]). That's completely by design. [1][2] (scroll up to see the quote by Rob Pike) If you have a team of a dozen guys working on a project with thousands of lines, your priority is not just performance (Go is quick enough [3]). It's probably not elegance either. It's software that documents itself. I used to work as a systems administrator for my schools engineering department. We would deal with fixing perl scripts dating back to the 90's. As students came and went, the result was hack jobs on top of hack jobs by students who are now in their 30's. I hated it. I would commonly have to rewrite scripts because over the years the basic flow of the program became completely asinine. That's exactly where go does well. Go is a langauge for people who don't want to have to deal with abuses of the language that their coworkers put in place. Go is a language that understands that for programmers, maintaining code means fixing bugs and fixing bugs tends to boil down to hacky solutions. Go ensures that those quick fixes aren't hacks. > "The only place I can see Go shining is for stuff like portable command line utilities where you want to ship a static binary that Just Works(tm). For interactive tasks I think it would be fine, I just don’t think it is particularly well suited to long-running servery things." I really don't understand why he feels that way. I don't see the distinction. > "It also probably looks attractive to Ruby/Python/Java developers, which is where I think a lot of Go programmers come from. Speaking of Java, I wouldn’t be surprised to see Go end up as the ‘new Java’ given the easier deploy story and the similar sort of vibe I get from the language. If you’re just looking for a ‘better’ Ruby/Python/Java, Go might be for you, but I would encourage you to look further afield." This reminds me of The Story of Mel [4]. If you're someone who enjoys programming and are writing the code for fun, I agree. Find the most unique language and do it in the most elegant way. Programming is almost an art, and if you're trying to be artistic, unique langauges are great for it. But not all software is artistic. > "Good languages help evolve your approach to programming; LISP shows you the idea of code as data, C teaches you about working with the machine at a lower level, Ruby teaches you about message passing & lambdas, Erlang teaches you about concurrency and fault tolerance, Haskell teaches you about real type systems and purity, Rust presumably teaches you about sharing memory in a concurrent environment. I just don’t think I got much from learning Go." I don't think that all langauges need to be learning experiences. Sometimes you just need to get shit done. [0]: https://benkurtovic.com/2014/06/01/obfuscating-hello-world.html https://benkurtovic.com/2014/06/01/obfuscating-hello-world.h... [1]: https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article [2]: http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/#fn-601-1 http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in... [3]: https://benchmarksgame.alioth.debian.org/u64q/go.html https://benchmarksgame.alioth.debian.org/u64q/go.html [4]: http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html

namelezz 11y ago

I always find it's difficult to navigate Go repositories on GitHub. Because there can be several source files under a package it's difficult to look for an implementation of a function or method. For Java, I can easily guess where the methods are by looking at import statements.

misframer 11y ago
godoc is very helpful for this. You can click on the name of a type or function and it will take you to the definition.
kjksf 11y ago
I friend of mine wrote a tool to fix that. See http://gotools.org/github.com/kjk/fofou http://gotools.org/github.com/kjk/fofou for example (just prepend http://gotools.org/ http://gotools.org/ to any Go import path). Then you can use Ctrl-f (Cmd-F on mac) search built-in browser to look for things. It doesn't work for large repositories but most of them aren't.

rkapsoro 11y ago

Go is great and all, but I'm really only using it until Rust is ready.

jaytaylor 11y ago
What are your criteria for "ready"?
artursapek 11y ago
Rust 1.0 came out recently. What are you waiting for?
- fsaintjacques 11y ago
  Complete, stable and mature standard lib.

ffn 11y ago

If backend programming was epic fiction, then right now, the world is divided into the following countries: The Kingdom of Java, The United Languages of .Net, and the Confederacy of the Scripting Tongue (where racial tensions are crackle under the temporary truce between Ruby, Python, Javascript, Lua, etc.). For the past decade, these three kingdoms constantly struggled against each other for the most precious resource of all: developer mind-share. But what they didn't know and couldn't prevent, was that their world would soon become (neigh, has already become) the battle ground of 3 ultra-advanced warring alien species: Go, Rust, and Elixir. Backed by unimaginably powerful forces (except Elixir, which is just open-source by Poland's own Jose Valim), the upstart alien languages threaten to herald in a terrifying future for the current 3 powerhouses. OP's article, and the fact that lots of people are agreeing, is a sign that one of the invading aliens is weakening.

ericdschmidt 11y ago
I want to watch this movie. What about Pony?
ericdschmidt 11y ago
I want to watch this movie. What about Pony?

fixxer 11y ago

Today, I got a request for a secure message passing service from our CTO. My group, which is a small team of 2 *nix geeks in a company with ~20 mostly c# developers, has become a bit of a skunkworks operation as we have been responding to external constraints and forced to move quickly. I was able to implement the service per the provided spec in 179 lines of Go in about ~2 hours. Stress tests passed. The job is done. We march on. Could I have written this service in C++? Absolutely, but it would have taken me 20 hours to get to the same level of confidence. Maybe some could do it on 2 hours; I'm admittedly not a great C++ developer or frequent user. Could I have written it in Python? Sure, but I would have had to scale and put it behind a load balancer, adding complexity to get equivalent performance. From what I've seen of Rust, I like it and plan to give it more time now that it is stable. I haven't spent time with D. I played with Erlang. I don't care for Haskell for anything remotely related to "work", but I don't dispute that it has a place in computer science. In my 2 years with Go, this is not my first positive experience. I have found that Go works well for cranking out high fidelity, snappy services like this. I think this is the result of the language's constraints enforcing simple patterns. Unlike C++ and Python, there are not a huge number of ways to accomplish tasks (at least not ways that feel natural). Take it or leave it, but I like Go (for certain things).

nly 11y ago
> Could I have written this service in C++? Probably. C++ productivity really relies on knowing good libraries, and having the freedom to use them. Without details, I'd wager you could have done it in 300-400 lines. If you gave a brief overview of what you needed, I'd describe my first instinct for doing it in C++.
istvan__ 11y ago
Yes, correctly exposed concurrency is a pretty amazing thing. CSP ftw! You could as easily do it in Clojure, Erlang or any language that supports that.
threeseed 11y ago
I don't understand what I am supposed to take away from this though. If you were a strong C, C++, Java, Scala, Clojure etc developer you could equally deliver a highly scalable solution in 2 hours. I haven't seen anything yet to show why Go is fundamentally easier to deliver solutions except for single binary development which isn't really an issue for server side development.

tptacek 11y ago

I could be wrong, but I feel like when people talk about how great the Golang tooling is, what they're really saying is "the compiles are instantaneous". I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous. Write a better one! Golang is not an especially impressive programming language --- as a language. But it seems to me like it is an undeniably impressive programming tool.

jballanc 11y ago
I completely agree. Some languages are written to adhere to an ideal (everything is lists), and make sacrifices in order to stick to that ideal. Some are written to be close to the metal, or to be as abstract and flowery as possible, and make different sacrifices. Every language has some primary goal, and all the rest must bend to accommodate that goal. Go's primary goal is: excellent tooling.
- serge2k 11y ago
  except for, apparently, poor code coverage tools?
  - NateDad 11y ago
    The coverage tool is fine. He didn't really explain the problem well. Coverage is per package, and only counts coverage from tests in that package. This makes sense because packages are independent and you can't count on another package to test yours.
- waps 11y ago
  But Go's tools suck ... Debuggers - http://blog.securitymouse.com/2014/10/golang-debugging-turning-pennies-into-gs.html http://blog.securitymouse.com/2014/10/golang-debugging-turni... Code analysis tools - aside from "go fmt" ... don't know any. There's certainly nothing compared to the C++ tooling. Versioning - nonexistent Editors, IDEs - nonexistent
deleted 11y ago
[deleted]

coldtea 11y ago

It's amazing how Go caught on. It's not well designed -- lots of special cases reserved just for the compiler, some bizarro decisions, etc. It's not modern (with the possitive associates of modern, not fadish, and modern being "the last 30 years of experience" which is still like a millenium in IT years). It's implementation is not great either. Not a very good compiler, not a very good GC, not good tooling. My theory is it caught on for 4 reasons: 1) It came from Google, and with some famous names to top. This got it initial publicity in programming sites and media, and Google then coughed for conferences, a spot on I/O etc -- so it caught lots of eyeballs, something independent languages don't have a chance to do. 2) It produces static binaries and this was a real need for lots of use cases. 3) It's easy to get started with, and made converts from scripting languages feel empowered, as if they were "real programmers" writing C, what with "pointers" and static types. 4) It makes writing parallel code for some uses cases easy, which is a good fit for some infrastructure/services apps. (I don't think most teams outside of Google and some C++ or Scala shops have had any beef with "long compile times" for that to have been a major factor. Though it played to the hype of it being "just like a scripting language").

djhworld 11y ago
> It's easy to get started with, and made converts from scripting languages feel empowered, as if they were "real programmers" writing C, what with "pointers" and static types. What is wrong with this? Exposing people to pointers and static types might give them confidence when writing or reading in "real programmers" code in C I find the level of sneery nose turning in this thread quite abhorrent to be honest.
- nulltype 11y ago
  There seems to be an idea that some ways of telling your computer what to do are too foppish and that if you are serious about it you use a language from 40 years ago. Of course that's probably what the assembly programmers said about C and there aren't many of those left anymore.
- pcwalton 11y ago
  > What is wrong with this? Exposing people to pointers and static types might give them confidence when writing or reading in "real programmers" code in C I don't see it as sneery nose-turning. Rather I see it as an acknowledgement that the real difficulty of C isn't pointers but rather is manual memory management, which Golang doesn't prepare you for.

jtwebman 11y ago

Sweet, I'll stick to learning Elixir with some (Erlang)!

samora 11y ago

I think a lot of us miss the Go point. There is nothing special about Go. It's simple and just works. Every time I used Go for a project it just worked. No fuss. With very little effort. And that's the point.

gambiter 11y ago
But that doesn't answer any of the (very valid) points raised in the article? Go is interesting as a replacement for a scripting language, perhaps. But it seems very lacking in many other areas. All of the points in the article, plus what libraries are available. I think some of it could be explained by it being a young language, but if that's the case, why is it getting the adoption it has so far? Just because it came from Google?
- rakoo 11y ago
  Because it has allowed so many of us to significantly raise the ratio "Amount of time I care about my project"/"Amount of time I care about something other than my project (typically, the language itself)". Go is the poster child for Worse is Better. It's ugly, inconsistent, feels naughty at times (all those copy-pastes ! It's so un-DRY !) but it gets shit done.

tapirl 11y ago

> Why the heck is Go making me care about pointers at all if it is a GC’d language? Apparently, the author doesn't understand how pointers work in Golang. He should read this article: http://openmymind.net/Things-I-Wish-Someone-Had-Told-Me-About-Go/ http://openmymind.net/Things-I-Wish-Someone-Had-Told-Me-Abou... . In short, golang pointer is neither c pointer nor java reference.

tmsh 11y ago

What's confusing about Go, in comparing it to other languages, is that it's a minimum orthogonal refactor of a language. It was born out smart engineers observing the web and other languages for decades and thinking that they needed something low level but high level enough. It's built staring precisely at the past two decades. C, C++, Java, Python, and an appreciation of formal specs over frameworks form Go. Most languages to perform professionally in you have to know what not to do (not use C++ templates too much, not give into verbosity in hierarchies in Java, not use the GIL, etc.). In Go, because it is a relatively clean refactor, you don't have to worry about this. But you do have to invent your own smaller libraries for what you want to do sometimes. Because it's a younger language. This is good though if you like programming and stacking lego pieces on you way to stacking paper.

larryweya 11y ago

I've had a keen interest in go but haven't used it for anything serious. My impression of it is that its a great replacement for languages like Python and is great at getting things running fast but I have to agree that it doesn't feel like the kind language I wouldn't want to write a large code base in. My huge interest in it is around the single binary deployment and its concurrency model. The language itself I find a bit quirky in some places (some data structures are passed by ref while other by value) and I like my languages concise and elegant. This post got me to have a second look at Elixir and I spent the whole day going though its documentation and prototyping an idea I wanted to implement in go, specifically because of go's concurrency model. And frankly ELixir is exactly the right fit for me, not only for this case but generally as a language with the kind of elegance and expressiveness I'm drawn to.