9 ms·
Why Go Is An Excellent Modern Programming Language
- dustingetz 13y agoquick summary: * no coding style flamewars * it has familiar syntax * builtin concurrency model * it has gc * it is fast * static types that don't get in the way If you compare this list to popular up-and-coming ecosystems from the 90s (java, python, C, C++, Ruby), okay, concurrency is a big win and everything else, maybe go is a little bit better. If you compare to other popular up-and-coming ecosystems in 2013 that have a similar sized following as Go (Scala, Clojure, Haskell, Node, Rust)... Well, at least Go beats Node. and Haskell appeared in 1990.
- enneff 13y agoIf you're going to summarize, don't leave out the entire section on the tool chain. Jeeze.
- blackprawn 13y agoDude I know Bill and Ted told me it was..DUH!
- harrytuttle 13y agoPretty much my view on the subject. One thing I'd really like to see for go is a UI toolkit which is native to it. Not Qt, Gtk, Wx ports, but a proper high level UI framework like WPF (but not!). I reckon that would take it into the financial and business sectors in no time at all. That and dynamic loading at runtime.
- frozenport 13y agoFinancial has been largely moving to Java (looking at Goldman Sachs), so I don't see them switching anytime soon. Qt is a fine framework and I see little reason to reinvent the wheel.
- cliveowen 13y agoGo is an interesting and promising language and I look at it as the spiritual successor of the C programming language. That said, I don't find it all that easy to pick up. At all. Despite having some experience writing in ANSI C (C89) I find getting started with Go pretty painful, not for the syntax (it's simpler and more readable/declarative) but for everything else, starting from the library. It's not straightforward or intuitive how to perform even the basic tasks (as basic as reading/writing from files/sockets) and even the online documentation isn't that good: it's just a bunch of prototypes. There are many new concepts/constructs that you may first think as a useful addition but that are actually a pretty fundamental part of the language (e.g. slices). I'm sure that with time and the right mindset one could actually enjoy writing software in Go.
- thirsteh 13y agoWeird. I had the exact opposite experience. Extremely easy to pick up, especially if you are familiar with both C and Python, since Python lists are fairly similar to slices. Also, the documentation is far better than e.g. that for Java and C#: http://golang.org/pkg/io/ http://golang.org/pkg/io/ / http://golang.org/pkg/io/ioutil http://golang.org/pkg/io/ioutil Reading a file into memory is as simple as: data, err := ioutil.ReadFile("filename")
- mattmanser 13y agoIn what crazy world is that documentation better than C#? There are no examples, the lifeblood of documentation, nor any notes about gotchas? It's early days in the language so that's not at all bad, but claiming the documentation is better when it's clearly not is odd. http://msdn.microsoft.com/en-us/library/b9skfh7s.aspx http://msdn.microsoft.com/en-us/library/b9skfh7s.aspx Also C# and java are going to have tons of examples on SO, so the amount of examples and extra documentation available is incomparable.
- thirsteh 13y agoThere are many examples in the Go docs, e.g. http://golang.org/pkg/net/http/#pkg-examples http://golang.org/pkg/net/http/#pkg-examples (runnable and editable too!) But I agree that there aren't enough, and that's probably the worst thing about Go documentation, especially when dealing with the lower-level libraries. Just to be clear, I don't think verbosity means that documentation is better. Documentation is better when it gives you the information you need, and nothing more. That being said, I mostly think Go's documentation is better than Java's, and on par if not slightly better than C#'s. Here's a better example of what I mean, e.g. http://docs.oracle.com/javase/6/docs/api/allclasses-noframe.html http://docs.oracle.com/javase/6/docs/api/allclasses-noframe.... vs. http://golang.org/pkg/ http://golang.org/pkg/ Granted, if you have no experience at all with the language--e.g. you haven't even taken the tour at http://tour.golang.org/--the http://tour.golang.org/--the documentation may be hard to read (what does "[]" mean, for example), but that's not the fault of API documentation, which rightly is clear and concise. Rather, that's the job for a comprehensive tutorial, which Go has: http://tour.golang.org/ http://tour.golang.org/
- khyryk 13y agoGo is interesting and I use it from time to time, but I'd hesitate to call it excellent without runtime constants and generics. Also, the "and not used" errors can get annoying.
- gnuvince 13y agoI like Go, but I feel that it only addresses one of the urgent problems in computer programming, concurrency. Another very important problem IMO is correctness and I find Go lacking in that area; the onus is squarely on the shoulder of the programmer. Languages like ML, Haskell, or Rust offer facilities to make correct code easier to write (or incorrect code harder to write, depends on your view point).
- bsg75 13y ago> facilities to make correct code easier to write I have read a bit about this for Haskell. What in Rust facilitates the same, that is absent from Go (or C, C++) ?
- samnardoni 13y agoType parameterisation, lifetimes, mutability qualifiers. Algebraic data types can be used to avoid null pointers via an Option/Maybe type.
- masklinn 13y agoNon-nullable pointers, a type system which is not full of holes, inability to cast. C and C++ obviously add (remove?) such things as complete lack of memory safety, unchecked out-of-bounds accesses or lifetime management. And Go's inability to assert any immutability is also a strike against correctness (at least C++ has consts, though they're complex beasts)
- PommeDeTerre 13y agoOne thing to consider about C++, though, is that it's powerful enough to already allow you to duplicate or very closely approximate the functionality you listed. This is the essence of what some people call "Modern C++". C++ functionality like references and smart pointers make pointer nullability and memory safety irrelevant, or at least much, much less of an issue than in C or older C++ code. RAII significantly helps with lifetime management of all sorts of resources, from memory to database connections to files. There are various collection libraries for C++ that make out-of-bounds accesses a non-issue, at a very minimal cost. Likewise, it's quite easy in almost all cases to avoid using unsafe casts and other behavior that may cause problems, when taking a more modern approach to C++. With a small amount of discipline, C++ of today can be much different than C++ of the 1980s or 1990s. Many of the pitfalls of that era can be avoided with remarkably little effort, especially when using C++11 and modern implementations. Yet it still easily gives you access to very powerful functionality for those rare cases when it is needed. This is much harder to do in many other, more modern languages.
- norswap 13y agoFor me, no exceptions is a show-stopper. I know people sometimes say it's actually advantage, and I believe in some situation, it can be. In a typical scenario, I might be working on an utility that does some IO. In case of error, I just want to do some cleanup then exit. With exceptions, the control flow will jump right up to the places were cleanup has to be performed. With return values, I need to check return values at each step of the call stack, which is tedious and ugly. Return values have to be modified to account for error code. Admittedly, Go handles this last point well with multiple return values.
- deleted 13y ago[deleted]
- mediocregopher 13y agoGo's version of 'finally' is called 'defer', and it can be used in any situation, not just error management (I often use it for releasing locks in the statement immediately after I've locked them). >I need to check return values at each step of the call stack, which is tedious and ugly. I see it more as explicit. You HAVE to decide what you're going to do in case of an error. Usually it's as simple returning that error, but sometimes you want to do more, and having the question constantly being asked means you think about it for all cases.
- pcwalton 13y ago> You HAVE to decide what you're going to do in case of an error. This is not true in all cases: func f() error { ... } func main() { f() // OK fmt.Println("Uh-oh") }
- deleted 13y ago[deleted]
- epidemian 13y ago> I see it more as explicit. You HAVE to decide what you're going to do in case of an error. I've often read this argument, but i don't see how that is an advantage over using exceptions. With exceptions you don't have to decide what to do in every function call that might raise an error. You just have to know that they can raise one, and code accordingly. For example: f = File.open(...) foo(f) bar(f) f.close() Is buggy if foo or bar could raise exceptions (the file would not be closed if an exception is raised there). Fixing it could imply adding a `finally` block around f.close() so the file always gets closed (same as Go's defer) or using a higher order function that already does that for us: File.open(...) do |f| foo(f) bar(f) end The thing is, this code didn't need to worry about which of foo or bar was raising an error; it just needed to worry about closing the file if anything went wrong. And i could add a new baz(f) call in there, or maybe refactor the foo(f) and bar(f) calls into a foobar(f) function that does just that and the code will still be as linear. There'd be no need to add extra `if`s there nor in the refactored foobar(f) function. > Usually it's as simple returning that error... I'd say that it's rather "most of the time" than "usually". And exceptions give you exactly that default behaviour of propagating the error up the stack. Without having to obfuscate the logic of some intermediate code (that doesn't care about what error could happen, as long as they are propagated to the caller) with superfluous `if`s and `return`s.
- samnardoni 13y agoWhen programming for fun in my spare time, I've noticed that I use Go differently from certain other languages (Haskell, Rust). When writing Haskell, I spend a lot of time thinking about how I can express the problem using the different language constructs, and how elegant the code is. With Go, because the language is so simple, I just focus on solving the problem; I almost feel that I solve the problem in spite of the language.
- neya 13y agoIf you come from a Scala background, you will find Go pretty 'Meh' feature-wise (No offense). It's a great language, but still it has a long way to go. With that said, I personally want Go to succeed as I love it's syntax (compared to Scala's slightly hair-pulling syntax). Also, the lack of robust battle-tested web-frameworks is right now a show stopper for me.
- PommeDeTerre 13y agoOne interesting thing to consider about the increase in Go's popularity is that it has been driven, to some extent, by programmers who really only had experience with PHP, Ruby, or JavaScript. These are the kind of developers who have by now been burned by the inherent dangers and drawbacks of dynamic languages. They know enough to know that there must be a better way to develop safer, more reliable and better-performing software. They just aren't familiar enough with existing statically-typed compiled languages to know what's already possible. Go may just be in the right place at the right time. It is simpler than languages like C, C++, Haskell, SML, and even Scala, for example. And it is getting a lot of hype just when these dynamic language refugees need something better, and are actively looking for it. While it's good that Go offers a much better environment and infrastructure than many of these developers are accustomed to, this may also be harmful in some ways. It may be just "good enough", at least compared to the alternatives that they're familiar with, that they don't feel the need to explore more established languages which do offer much more. Even if they don't move past Go any time soon, at least it's encouraging to see them using a more responsible language for larger-scale software projects.
- steveklabnik 13y agoThis defiantly jives with some of my experiences. I've been saying that "Go makes me feel like an old man," because other than a _fantastic_ development experience, I don't actually see anything about Go that's particularly interesting and/or worthwhile. I also remind fellow Rubyists who say "Go is boring, it's supposed to be that way!" that when they talk shit on Java, that was one of its rallying cries as well. It's all just a bunch of cycles, what's trendy comes and goes, is boring and then interesting again...
- gutsy 13y agoI'm a Java guy and I've been learning Go on the side just for fun and so far I like it. I've found the documentation fairly easy to get through (the fact that there are examples right in the documentation makes me like it better than Java). I don't think the language is perfect, but I think it's well on it's way to getting there.