16 ms·

Impressions of Go

187 points by icey 13y ago

rwmj 13y ago
I thought it was a pretty poor language, obviously written by people who'd either never heard of functional languages or never "got" the point of them. More here: https://rwmj.wordpress.com/2013/07/03/golang-bindings-for-libguestfs/#content https://rwmj.wordpress.com/2013/07/03/golang-bindings-for-li... There's still room out there for the C replacement language. Something with ML/OCaml-level of expressiveness but with a replaceable garbage collector might be the sweet spot.
- swdunlop 13y ago
  Your blog post has some assertions that are either overbroad ("No type inference.") or just unsupported ("The whole design of GOROOT/GOPATH is completely broken".) Everyone is welcome to their opinion, but it'd be nice if they actually supported it with some explanation if they want to bandy it about in public.
  - rwmj 13y ago
    Well you can't call 'var' type inference (Edit ':=' .. it's still laughable compared to real type inference). But I'll explain the GOROOT stuff in a bit more detail ... Basically the way it's set up prevents golang modules from being packaged up for Linux distros. There are two main problems. Firstly the 'go' utility tries to recompile installed modules, which isn't going to work as those modules are in files and directories owned by root and 'go' is not running as root. By very carefully setting up timestamps it's usually possible to avoid this, but it's fragile. Secondly if you do install a golang package, you can't compile an alternative copy in GOPATH, because the one in the (root-owned) GOROOT overrides it. Which is dumb and backwards.
    - burntsushi 13y ago
      There are a myriad of possibilities that await you on the Archwiki. [1] Also, you should not be installing third party packages in `GOROOT`. If you do, then yes, you're going to be in some trouble. [1] - https://wiki.archlinux.org/index.php/Go_Package_Guidelines https://wiki.archlinux.org/index.php/Go_Package_Guidelines
      - rwmj 13y ago
        That web page summarises how we package golang libraries so far, and it's (a) fragile and (b) doesn't let people install their own development copies of libraries, as I said in the gp post.
        burntsushi 13y ago
        > doesn't let people install their own development copies of libraries Then maintain two different and distinct `GOPATH` directories. One for development libraries and one for other stuff.
    - mseepgood 13y ago
      > Well you can't call 'var' type inference 'var' is not the type inference, ':=' is the type inference.
      - pcwalton 13y ago
        It's not HM-style type inference, which is presumably what the parent comment was referring to.
- harrytuttle 13y ago
  Perhaps you don't "get" Go?
- burntsushi 13y ago
  > No type inference. Because obviously it’s 2013 and I want to write types everywhere. The `:=` does a fair bit for the programmer in cutting back on writing types. For me, the most needed place for type inference would be for writing anonymous closures (like what Rust has). In most other places, I am quite content with writing the types, particularly at the top level. > Like what’s the point of all the odd rules around := vs = The former is short-hand for variable declaration with assignment and type deduction, while the latter is just regular assignment. The primary benefit here is type deduction, which partially relieves the lack of type inference. > and what types you can and can’t assign and pass to functions Huh? > And why do you have to declare imports, when the compiler could work them out for you (it’ll even moan if you import something which is not used!) The compiler absolutely cannot work them out for you. If you have a package `github.com/PeepA/wat` and a package `github.com/PeepB/wat`, how will the Go compiler know which `wat` package to import? The Go compiler merely moans if an import (or its alias) hasn't been used in the source file that it was imported in. I like this feature, even if it is a mild bother while debugging. > Hello, world is about 8 lines of code. Camel case! Java rang, wants its boilerplate back. It's two lines. [1] > No breakthrough on error handling. Breakthrough? I'm not sure what you were expecting, but I think the error handling is pretty sane and at least far better than error handling conventions established in C. It could be adjusted if sum types were added to the language, but that has its own trade offs. If you desperately want exception-style error handling, then you can use panic/defer/recover, but it's frowned upon to overuse it. > The whole design of GOROOT/GOPATH is completely broken. It’s actually worse than Java’s broken CLASSPATH crap which is some kind of achievement, I guess. I have the exact opposite opinion. Did you know that you probably shouldn't be setting `GOROOT`? [2] After Go is installed, you just need to set `GOPATH` and add `$GOPATH/bin` to your `PATH`. That's it. > It’s not even enforced error checking, so bad programmers will still be able to write bad code. That is true, but Go's compiler forces you to address errors returned by functions that also return another value. You either need to explicitly ignore it or use the variable the error is stored in. (Lest you get an "unused variable" compiler error.) This doesn't cover all cases---like completely ignoring the return value(s) of a function---but don't throw the baby out with the bath water! [1] - http://play.golang.org/p/ihEoJ0yL9I http://play.golang.org/p/ihEoJ0yL9I [2] - http://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really http://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroo...
- acuozzo 13y ago
  Go was neither designed to replace nor compete with existing functional languages. Even if it were demonstrably true that functional programming languages are a "better" (leaving this loosely-defined for now) choice than Go in 100% of the circumstances in which one would choose to use Go, your argument still wouldn't hold water, as it neglects other important characteristics of a programming language that are neither quantifiable nor useful in the context of comparing programming languages, such as perceived simplicity and the ability to hold the entire programming language in one's head. What's the value in denouncing a programming language because it isn't designed with your favorite programming paradigm in mind? That's just dick. Also, are you really going to call-out Rob Pike and Russ Cox on whether or not they truly understand Functional Programming like you do? Really? Really?
  - rwmj 13y ago
    I didn't say Go was designed to replace or complete with functional languages. I said it would be good if Go's designers understood functional languages, but whatever their history or how internet-famous they are, they don't.
    - jbooth 13y ago
      Go was designed to write systems-y back-end services. Functional languages are a terrible mismatch for this. 'No side effects' is great for certain types of coding, and terrible for systems integration where side effects are the whole point of what you're doing. Could you please explain what you mean when you say they don't understand functional languages as well as you? The lack of eval() and code-as-data in Go? Something else?
      - pcwalton 13y ago
        Functional languages are not about having no side effects.
        jbooth 13y ago
        It's a major characteristic, often cited as a positive. I included a reference to eval(), as well. Please enlighten me as to what they're really about, then?
- RogerL 13y ago
  I kind of think Rob Pike knows about functional programming. Go was written at Google to solve very specific problems Google had. Looming large was the need for a C family language that implemented concurrency, fast compiles, and so on. The C family requirement is quite simple: most google engineers are young and don't know functional programming, have experience with Google's existing C/C++ code base, and they will be using Go to replace and extend existing systems already in C/C++. A new functional paradigm, nice as it is, would just get in their way. I'm not enamored by many features of the language, but I'm really hard pressed to say that those features do not solve Google's problems.
  - mseepgood 13y ago
    The first Go program was a LISP S-expression parser: http://blog.golang.org/first-go-program http://blog.golang.org/first-go-program Stephen Wolfram writes about the birth of Mathematica: "Macsyma was written in LISP, and lots of people said LISP was the only possibility. But a young physics graduate student named Rob Pike convinced me that C was the “language of the future”, and the right choice." http://blog.wolfram.com/2013/06/06/there-was-a-time-before-mathematica/ http://blog.wolfram.com/2013/06/06/there-was-a-time-before-m...
    - pjmlp 13y ago
      Yeah, now we have to live the "present of buffer overflows".
- tptacek 13y ago
  Yes, what a dummy Rob Pike is, to have jettisoned all the functional goodness of C.
- masklinn 13y ago
  > Something with ML/OCaml-level of expressiveness but with a replaceable garbage collector might be the sweet spot. That's Rust: http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/ http://pcwalton.github.io/blog/2013/06/02/removing-garbage-c...
  - TylerE 13y ago
    Kind of a shame that the Rust crew doesn't seem to "get it" the way the Go team does. The Rust stdlib is TERRIBLE. Even basic stuff like file IO isn't implemented sanely. A shame as the language itself is pretty good, other than the idiotic semi-colon decision.
    - pcwalton 13y ago
      It's a work in progress. We have not hit 1.0 yet. Regarding the semicolon rules, you won't like this observation, but in my 3 years of writing Rust the semicolon rule has literally has never led to a single bug.
      - marshray 13y ago
        I get the feeling that your knowledge of the rules is not necessarily representative of typical post-1.0 developers. :-) However, I don't recall it being a problem in my experimentation with Rust either.
        TylerE 13y ago
        In my case, it's not a problem with understanding them, it's a burning desire that they not exist.
        klibertp 13y ago
        You realize that it's a matter of aesthetics at best? You could set your editor of choice to substitute character ; with <pink elephant> when displaying code and back when saving it to disk. Have you tried this approach? (It's not an original idea - there is a plugin for Emacs which does exactly this for CamelCase - it displays parts of camel cased words as separate words. Helpful if you have looong camel cased name and are irritated because <back by word> and <forward by word> doesn't take you where you should be)
- deleted 13y ago
  [deleted]
- coldtea 13y ago
  >I thought it was a pretty poor language, obviously written by people who'd either never heard of functional languages or never "got" the point of them. Or "got it" and didn't find it any that good, for the types of problems they work on.
rdudekul 13y ago
Good pros and cons of Go language. There is some information around why Go and not say C++/Java/Ruby etc. The statement "I see Rails as the emperor with no clothes on" seems to be made in haste, since Rails is awesome for basic forms based apps.
- slaxman 13y ago
  I know a lot of friends of mine who have C/C++/PHP background struggle with rails at the start, primarily because of the magic of convention over configuration that happens (they aren't used to it). It takes a while to understand it. But once you understand it, it's a breeze. Disclaimer: I am a Rails developer. My views are therefore biased.
  - tracker1 13y ago
    I think that, as with any automagic framework that the edge cases become exponentially more difficult to implement. I'm very comfortable with MV* frameworks on client and server, and still not big on rails. It's also likely that TFA's author was frustrated with performance under load, where Ruby (and Python) generally do not shine.
  - Jd 13y ago
    In many ways the problems people have with RoR are the same problems people have with ORMs. They abstract away a lot of the clutter, but then, just as you become totally dependent on the abstraction, you find you need something that you can't get in the abstracted layer. When this thing is a substantial increase in speed, sometimes you are totally f*ed, since to get it you need to toss away a lot of the detritus. For an ORM you can gradually phase away parts of it, but for a web framework generally you can't architect away the box into which your app is placed. I'm unaware of any RoR that has successfully scaled, except by removing Ruby (Twitter). Github is probably the largest existing Rails app (at least that I use), and there are Unicorns aplenty (the new fail whale), or weird caching issues that seem to arise regularly.
    - grey-area 13y ago
bsaul 13y ago
Best sum up of the language i've ever seen (plus it seems completely coherent with what i've supposed so far about that language, both pros and cons). About the "no generic / you have to cast ,recast / the make issue" , could anyone here with a bit of experience gives an example of what that would look like in real code ?
- pkulak 13y ago
  You pretty much can't write your own container without significant pain. That said, with the built in objects you have a map, list, set (map of bools, which is actually very nice since maps return default types - false - for missing entries), and concurrent blocking or non-blocking queue (chan). Stacks get a bit cludgy, but can be done without too much pain. Apart from those, I've really never had to roll my own collection class. Someday I may, but it is surely not something you need to do very often.
  - tptacek 13y ago
    On the contrary, I found it significantly easier to write a custom container (a trie in my case) in Golang than in Ruby (which let's stipulate is pin-compatible with Python). In particular, Golang provides fine-grained control over memory layout, and is even expressive enough to implement allocators, both of which are practically impossible in Ruby. It's true that Golang grants a very useful power to its builtin maps, which makes it rankle that you have to cast in and out of interface{} to make your own general-purpose container. But apart from the fact that interface{} is a stupid name, I don't find it much more painful to write general purpose containers in Golang than I found it to write templated containers in C++.
    - pcwalton 13y ago
      Go does not provide fine-grained control over memory layout when you use interface{}.
  - nickpresta 13y ago
    You should actually be using a `struct{}` as the value, as it takes no space (opposed to a bool). http://play.golang.org/p/KK1ymLzd_e http://play.golang.org/p/KK1ymLzd_e
fbomb 13y ago
For me, no templates + no exceptions = DOA.
- deleted 13y ago
  [deleted]
- jeremiep 13y ago
  Exceptions I can easily live without; Haskell's monads provide a much better mechanism for error handling (Maybe, Either, IO, etc).
  - klibertp 13y ago
    You have generics^2 if you're using Haskell, so it's no wonder they are able to replace exceptions ;)
- masklinn 13y ago
  Go has exceptions (panic/recover). They're pretty bad, you shouldn't use them (just as you generally shouldn't use exceptions in Erlang) and some in the Go community downright refuse to accept that they exist, but they're there.
- TylerE 13y ago
  Templates are a sad hack in place of true hygenic compiler macros.
  - marshray 13y ago
    Macros are the sad hack. Templates can express compile time assertions.
    - TylerE 13y ago
      I believe you misunderstand me. I'm not talking about preprocessor macros, but TRUE compiler macros ala Lisp or Clojure, which can bring the full expressiveness of the language to bear on the task at hand, and generate program code as a return value. Consider the following example, from Clojure, which implements a C-style for-loop (defmacro for-loop [[sym init check change :as params] & steps] (cond (not (vector? params)) (throw (Error. "Binding form must be a vector for for-loop")) (not= 4 (count params)) (throw (Error. "Binding form must have exactly 4 arguments in for-loop")) :default `(loop [~sym ~init value# nil] (if ~check (let [new-value# (do ~@steps)] (recur ~change new-value#)) value#)))) Syntax primer: The code runs at compile time, forms (nested parenthized groups) that are prefixed with ` are the output, ~var means to substitute the _value_ var from the macro invocation, and var# means create a new anonymous variable var, guaranteed not to clobber or shadow any existing variable. For instance, given out macro defined above, say we make the following call: (for-loop [i 0, (< i 10), (inc i)] (println i)) The code generated by the compiler for that invocation is: (loop* [i 0 value__95__auto__ nil] (if (< i 10) (clojure.core/let [new-value__96__auto__ (do (println i))] (recur (inc i) new-value__96__auto__)) value__95__auto__)) You can see how A: all the error checking is done at compile time and comes at no runtime cost B: how the `-quoted code in the original macro gets "filled in". C: How the arguments to the macro are not evaluated by the macro call or the substition until they are actually used. Point C is quite powerful since it means that macros can be used to create arbitrary control structures that are fully as powerful and general as anything in the core or stdlib - and in fact many of those are implemented as macros.
bayesianhorse 13y ago
OH: "Any tips for getting started with Go?" Answer: "Yes, try Python."
coldtea 13y ago
Imagine if the Go team listened all those that want Generics in Go. It would be more consistent and closer to perfect language. As it is, it's a PITA 20% of the time. (Sure, some say they use it and don't feel a need of generics. Most do however, and it's a constant in every review, even by people using it for core infrastructure).
- tptacek 13y ago
  What kinds of things have you written in Go, where the language has been a PITA to you?
  - jff 13y ago
    "Well I would write things in Go, but I keep hearing about this generics thing so I'm just going to complain about it instead"
    - coldtea 13y ago
      Yes, because nobody both uses a language AND has a legitimate complain against it. Well, I for one have both. As lots of people. And in fact, it's quite common. Anyone that used a language should be able to tell you several pain points about it. Except if he is in his idiotic "oh, this is so much better than the blub that I used to use, it's perfect" stage. Have you even read TFA? The guy evaluated the language, done a project with it, and still wants generics.
  - Djehngo 13y ago
    Data structures usually, If you want to write a linkedhashmap or a dictionary where the keys are autogenerated from the values or any kind of structure not built into the language you are forced to either roll a new structure for each set of types or cast everything to and from (empty)interfaces. While it's still possible with the casting, it doesn't feel as nice as the rest of the language does. The other case seems to be any kind of generic pattern with channels, it's possible to build a channel-pair which acts as a single channel with a buffer only bounded by memory, but you can only do it for a single type. All of these are avoidable or maybe even inadvisable, but it still feels like a hole in the language when you go to do something which is common, useful and trivial in C++/java/C# and you have to use ugly hacks or deal with heavily reduced functionality, especially when the rest of the language is so nice.
jlarocco 13y ago
Articles on Go are getting a little boring. The majority are written by people who've spent an afternoon looking at Go and decide to rehash the same 5 bullet points. In the time it takes to read their "article" I could learn the same stuff, better, by reading the official Go tutorial. Some in depth reviews based on actually using it for an extended period of time on a large project would be nice...
- tptacek 13y ago
  I agree about the articles themselves but vote them up because I tend to learn things on the resulting threads.
  - frou_dh 13y ago
    Go threads aren't as fun to read without uriel scolding non-believers for their bad taste.
    - pjmlp 13y ago
      As non-believer I miss my discussions with him.
      - happy_dino 13y ago
        I still wonder why Go is so prone to religious fanboys, though.
- zeeboo 13y ago
  The problem is that even those are boring. I've used Go for an extended period of time on a large project and there's nothing to report. It works just like what everyone else already says.
  - Arnor 13y ago
    That's what's awesome about it! Everybody who uses it gets the same impressions of it (EDIT: and those impressions are 95% good). What other language has that going for it?
dvt 13y ago
This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository" -- is unfounded. Even though there may be some good reasons why one might use Go instead of C/C++, I find it hard to justify using Go instead of Python/Ruby/JS/Java (the only criticism of Java - that it's verbose and hard to tune - is questionable as well). I've said this before. I like Go. I contributed to Go. I've used Go and I still use it from time to time. But much like D, I don't think it has a niche. There are magnitudes more libraries and resources available for Python/Ruby/JS/Java -- thus far, it's been more than enough to sway me into using those languages (mostly JS/Java) instead of Go.
- pron 13y ago
  I share the sentiment. People often mention that Go is less verbose than Java like they were talking about Clojure or something. Go is just a little less verbose than Java (other than in a hello world example), and targets the same conceptual "level" (same order of abstractions, same "distance" from the metal, although Java can get closer to metal than Go). So, sure, it feels a little more modern in some respects (and less modern in others), but when considering both languages carefully, I find I really need a magnifying to tell the two apart. If Go had offered everything that Java does, I still wouldn't have had a compelling reason to switch because the differences are just too small. But Go doesn't offer everything Java does. Like you said, Java's ecosystem dwarfs Go's. Java has dynamic linking, runtime code instrumentation, unparalleled tooling, and better performance than Go. The only advantage I see Go has over Java is a shorter startup time, which makes it a reasonable choice for writing command-line programs. As for concurrency constructs, Java is far more flexible than Go, and because goroutines and channels are easy, I've ported them to Java[1] (and Clojure). Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM. In reality, it's just a recent, beginner-friendly Java without the awesomeness of the JVM. (P.S. I'm not sure Java's often mocked factory-factories aren't simply a result of the huge number of multi-million LOC programs that have been written in Java. It's just experience, and Go sure doesn't have the necessary abstractions to make engineering large systems any easier. Other recent languages -- sure -- but not Go) [1] https://github.com/puniverse/quasar https://github.com/puniverse/quasar
codezero 13y ago
I agree with most of this post, but I actually found online resources (especially golang-nuts and various SO pages) to be very helpful with debugging.
VeejayRampay 13y ago
I see it's become trendy to poke fun at Rails and the hurdles it puts on your way to "scale". Not only have many companies been able to do so using Rails, but it also completely overshadows the ease it provides to get started in the initial phase of a project. That being said, Go really seems like an awesome language, I've dabbled some and I can't wait to get back to it.
oakaz 13y ago
"The standard library is missing x" What you are looking for is actually a productive community with a good module manager. This what Golang is missing. (Golang fans: don't get me wrong, I use and love Go.)
dakimov 13y ago
Another dumb and unconvincing ad of Go. Go must go. There is enough shit languages already, and Go being one of the worst modern languages. It doesn't even feel modern. It is so poorly designed that it feels like some talentless experimenting from 70's.
stcredzero 13y ago
> C++: too much rope, hard to maintain, painful to introduce at a company with no prior C++ footprint, frightens junior devs who no longer absorb relevant memory management idioms in school So, are we now in an era when there are lots of people in the job market who couldn't write a doubly-linked list to save their life? When I was in my 20's, I noted that there were lots of programmers around who basically treated compilers as "magic" and hadn't the tiniest inkling about how they worked. Now that I'm in my 40's, I've noted "so what" attitudes in languages that require manual memory management. (iOS and Objective-C. ARC goes a long way, but it still doesn't take care of everything for you.)
- tropicalmug 13y ago
  I am one of those programmers: I have no real idea how a compiler goes about its business, my university does not offer an accessible compiler class (only for grad students and very irregularly), and I have no idea where to start besides trying to force my way through the purple dragon book. What are things I should know about compilers that I probably don't? What is suggested reading on compilers?
  - xtracto 13y ago
    I am not an expert in compilers, but in my undergrad compiler's class one of the things I remember the most are parsers (such as LALR). I remember having a great time implementing different types of parsers: http://en.wikipedia.org/wiki/Category:Parsing_algorithms http://en.wikipedia.org/wiki/Category:Parsing_algorithms I think the dragon book is the absolute reference for learning compilers: http://www.amazon.com/Compilers-Principles-Techniques-Alfred-Aho/dp/0201100886 http://www.amazon.com/Compilers-Principles-Techniques-Alfred...
  - stcredzero 13y ago
    As xtracto mentioned, parsing and enough automata theory to understand what context free grammars are and where they fall should be part of your basic toolkit, but how they generate code is even more useful to C programmers. (One study done decades ago found that the average C statement resulted in 2.7 CICS assembly language commands.) The Dragon Book is not the best teaching tool out there. Maybe try The Elements of Computing Systems Chapters 10 & 11? You might need to peek at the earlier chapters to get a grounding in the particular assembly language they use.
electrotype 13y ago
"Java: too verbose, too many FactoryFactories, painful to tune" Paintful to tune... Maybe. But I don't understand why so many people say patterns like FactoryFactoryFactories are inherent to Java! I can write Java code with NO factories at all. Writing shitty and unflexible code is really easy. When you understand why a factory is used in a particular piece of code, you start to appreciate it! It's also very possible to write C++ or Python code with too many overengineered components. Also, I like a language to be verbose, I don't think it is an issue. As long as the code is clear and easy to read... And it's often the case with Java programs. For my eyes, Java is way more readable than, let's say, Perl, Scala or Clojure. I couldn't care less about the number of lines required to achieve the same result! I'm getting tired of this Java bashing... The only thing that really sucks about Java is Oracle!
- pron 13y ago
  Even Java bashers would concede that Java is a brilliant language, certainly for its time. And the JVM is the most impressive programming environment to this day. But the language has become a little dated. Oh, you don't need to go as far as Scala to fix it (to me Scala feels like a deranged, haphazard combination of javascript and Haskell), but something like Kotlin could really be a "better Java" (it also happens to be a better Scala, but that's a different point).
- sarnowski 13y ago
  In fact, since go does not have explicit constructors, it encourages the factory pattern all over the place. You'll find static factories everywhere in the go library. http://golang.org/doc/effective_go.html#composite_literals http://golang.org/doc/effective_go.html#composite_literals
  - deleted 13y ago
    [deleted]
- tomp 13y ago
  In modern languages, you don't need to write a class when all you need is a first-class function.
dvirsky 13y ago
I know it's not a popular view, but being pretty much in love with Go, what I find most difficult about it is the lack of any real IDE. And by real IDE I basically mean: a rich editor, stable code completion, jump-to-declaration etc; and tight debugger integration. Unless I'm really unaware of an IDE that has all of them, all the IDEs that support Go fall short: 1. IntelliJ plugin - excellent editor, a lot of the intellij goodies; but I've managed to break the code completion, and it's tricky to configure with respect to GOROOT and GOPATH. and most importantly, no GDB integration whatsoever. 2. GoClipse - reasonable (although buggy) debugger integration, very good code completion, no jump to declaration which is a pain, plus a wonky build system - the build can fail and you see no message, and the program just runs from the previous build. 3. Sublime with GoSublime and SublimeGDB: the build system is buggy, code completion is great (managed to break that too on complex projects), no jump to errors, don't remember re jump to source. I had to do a lot of voodoo to get SublimeGDB to work half decently, and even that was not very robust because SublimeGDB is buggy on its own. 4. LiteIDE - has everything in theory, but just feels a bit clunky and hard to configure. I didn't like it as an editor and haven't spent much time with it. But it's constantly improving so I hope it will get there some day. The rest are Windows only so out of the question, less complete/mature than those 4, or vim with plugins. I don't like vim, I like graphical IDEs, shoot me. :) Again, I really really love Go, I hope it will allow me never to write C++ again in my life. This is not a "Go is not ready yet" gripe. It's just what I find most difficult about it.
- TylerE 13y ago
  Just curious, but what issues did you have with GoSublime builds? It's using the `go` tool under the covers.
  - dvirsky 13y ago
    A few are just UX quirks - ctrl+b tries to build from the current package, not the project root, leaving you tabbing to main.go for each recompile, which is annoying; cursor "runs away" from the prompt not affecting anything. but mostly, the output is buffered. I wrote a toy MapReduce framework that yielded tons of output. It crashed Sublime because it buffered the entire output into the console instead of printing it into some sort of FIFO buffer like IntelliJ or Eclipse do. Again, running from a terminal is ok, but the whole point of an IDE is to save you from fiddling with lots of windows and terminals.
rubiquity 13y ago
I'm getting sick of all these Go goroutines... err threads.
- pjmlp 13y ago
  You mean Modula-2 co-routines. :)
st3fan 13y ago
How is "deploying modern Java applications, which is a minor nightmare IMO" true? Dropping a .war file in a directory is hard? Or am I missing something about 'modern' Java apps?
mwcampbell 13y ago
I agree with the point about statically-linked binaries. However, I wish there were a compile-time facility for including the contents of a file as a read-only byte array in the binary. Then web application servers with HTML templates, and even images and other assets, could be truly self-contained.
lectrick 13y ago
The more I learn about other langs, the more I appreciate the language design of Ruby, even though Ruby is slow as shit.

187 points by icey 13y ago

rwmj 13y ago

I thought it was a pretty poor language, obviously written by people who'd either never heard of functional languages or never "got" the point of them. More here: https://rwmj.wordpress.com/2013/07/03/golang-bindings-for-libguestfs/#content https://rwmj.wordpress.com/2013/07/03/golang-bindings-for-li... There's still room out there for the C replacement language. Something with ML/OCaml-level of expressiveness but with a replaceable garbage collector might be the sweet spot.

swdunlop 13y ago
Your blog post has some assertions that are either overbroad ("No type inference.") or just unsupported ("The whole design of GOROOT/GOPATH is completely broken".) Everyone is welcome to their opinion, but it'd be nice if they actually supported it with some explanation if they want to bandy it about in public.
- rwmj 13y ago
  Well you can't call 'var' type inference (Edit ':=' .. it's still laughable compared to real type inference). But I'll explain the GOROOT stuff in a bit more detail ... Basically the way it's set up prevents golang modules from being packaged up for Linux distros. There are two main problems. Firstly the 'go' utility tries to recompile installed modules, which isn't going to work as those modules are in files and directories owned by root and 'go' is not running as root. By very carefully setting up timestamps it's usually possible to avoid this, but it's fragile. Secondly if you do install a golang package, you can't compile an alternative copy in GOPATH, because the one in the (root-owned) GOROOT overrides it. Which is dumb and backwards.
  - burntsushi 13y ago
    There are a myriad of possibilities that await you on the Archwiki. [1] Also, you should not be installing third party packages in `GOROOT`. If you do, then yes, you're going to be in some trouble. [1] - https://wiki.archlinux.org/index.php/Go_Package_Guidelines https://wiki.archlinux.org/index.php/Go_Package_Guidelines
    - rwmj 13y ago
      That web page summarises how we package golang libraries so far, and it's (a) fragile and (b) doesn't let people install their own development copies of libraries, as I said in the gp post.
      - burntsushi 13y ago
        > doesn't let people install their own development copies of libraries Then maintain two different and distinct `GOPATH` directories. One for development libraries and one for other stuff.
  - mseepgood 13y ago
    > Well you can't call 'var' type inference 'var' is not the type inference, ':=' is the type inference.
    - pcwalton 13y ago
      It's not HM-style type inference, which is presumably what the parent comment was referring to.
harrytuttle 13y ago
Perhaps you don't "get" Go?
burntsushi 13y ago
> No type inference. Because obviously it’s 2013 and I want to write types everywhere. The `:=` does a fair bit for the programmer in cutting back on writing types. For me, the most needed place for type inference would be for writing anonymous closures (like what Rust has). In most other places, I am quite content with writing the types, particularly at the top level. > Like what’s the point of all the odd rules around := vs = The former is short-hand for variable declaration with assignment and type deduction, while the latter is just regular assignment. The primary benefit here is type deduction, which partially relieves the lack of type inference. > and what types you can and can’t assign and pass to functions Huh? > And why do you have to declare imports, when the compiler could work them out for you (it’ll even moan if you import something which is not used!) The compiler absolutely cannot work them out for you. If you have a package `github.com/PeepA/wat` and a package `github.com/PeepB/wat`, how will the Go compiler know which `wat` package to import? The Go compiler merely moans if an import (or its alias) hasn't been used in the source file that it was imported in. I like this feature, even if it is a mild bother while debugging. > Hello, world is about 8 lines of code. Camel case! Java rang, wants its boilerplate back. It's two lines. [1] > No breakthrough on error handling. Breakthrough? I'm not sure what you were expecting, but I think the error handling is pretty sane and at least far better than error handling conventions established in C. It could be adjusted if sum types were added to the language, but that has its own trade offs. If you desperately want exception-style error handling, then you can use panic/defer/recover, but it's frowned upon to overuse it. > The whole design of GOROOT/GOPATH is completely broken. It’s actually worse than Java’s broken CLASSPATH crap which is some kind of achievement, I guess. I have the exact opposite opinion. Did you know that you probably shouldn't be setting `GOROOT`? [2] After Go is installed, you just need to set `GOPATH` and add `$GOPATH/bin` to your `PATH`. That's it. > It’s not even enforced error checking, so bad programmers will still be able to write bad code. That is true, but Go's compiler forces you to address errors returned by functions that also return another value. You either need to explicitly ignore it or use the variable the error is stored in. (Lest you get an "unused variable" compiler error.) This doesn't cover all cases---like completely ignoring the return value(s) of a function---but don't throw the baby out with the bath water! [1] - http://play.golang.org/p/ihEoJ0yL9I http://play.golang.org/p/ihEoJ0yL9I [2] - http://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really http://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroo...
acuozzo 13y ago
Go was neither designed to replace nor compete with existing functional languages. Even if it were demonstrably true that functional programming languages are a "better" (leaving this loosely-defined for now) choice than Go in 100% of the circumstances in which one would choose to use Go, your argument still wouldn't hold water, as it neglects other important characteristics of a programming language that are neither quantifiable nor useful in the context of comparing programming languages, such as perceived simplicity and the ability to hold the entire programming language in one's head. What's the value in denouncing a programming language because it isn't designed with your favorite programming paradigm in mind? That's just dick. Also, are you really going to call-out Rob Pike and Russ Cox on whether or not they truly understand Functional Programming like you do? Really? Really?
- rwmj 13y ago
  I didn't say Go was designed to replace or complete with functional languages. I said it would be good if Go's designers understood functional languages, but whatever their history or how internet-famous they are, they don't.
  - jbooth 13y ago
    Go was designed to write systems-y back-end services. Functional languages are a terrible mismatch for this. 'No side effects' is great for certain types of coding, and terrible for systems integration where side effects are the whole point of what you're doing. Could you please explain what you mean when you say they don't understand functional languages as well as you? The lack of eval() and code-as-data in Go? Something else?
    - pcwalton 13y ago
      Functional languages are not about having no side effects.
      - jbooth 13y ago
        It's a major characteristic, often cited as a positive. I included a reference to eval(), as well. Please enlighten me as to what they're really about, then?
RogerL 13y ago
I kind of think Rob Pike knows about functional programming. Go was written at Google to solve very specific problems Google had. Looming large was the need for a C family language that implemented concurrency, fast compiles, and so on. The C family requirement is quite simple: most google engineers are young and don't know functional programming, have experience with Google's existing C/C++ code base, and they will be using Go to replace and extend existing systems already in C/C++. A new functional paradigm, nice as it is, would just get in their way. I'm not enamored by many features of the language, but I'm really hard pressed to say that those features do not solve Google's problems.
- mseepgood 13y ago
  The first Go program was a LISP S-expression parser: http://blog.golang.org/first-go-program http://blog.golang.org/first-go-program Stephen Wolfram writes about the birth of Mathematica: "Macsyma was written in LISP, and lots of people said LISP was the only possibility. But a young physics graduate student named Rob Pike convinced me that C was the “language of the future”, and the right choice." http://blog.wolfram.com/2013/06/06/there-was-a-time-before-mathematica/ http://blog.wolfram.com/2013/06/06/there-was-a-time-before-m...
  - pjmlp 13y ago
    Yeah, now we have to live the "present of buffer overflows".
tptacek 13y ago
Yes, what a dummy Rob Pike is, to have jettisoned all the functional goodness of C.
masklinn 13y ago
> Something with ML/OCaml-level of expressiveness but with a replaceable garbage collector might be the sweet spot. That's Rust: http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/ http://pcwalton.github.io/blog/2013/06/02/removing-garbage-c...
- TylerE 13y ago
  Kind of a shame that the Rust crew doesn't seem to "get it" the way the Go team does. The Rust stdlib is TERRIBLE. Even basic stuff like file IO isn't implemented sanely. A shame as the language itself is pretty good, other than the idiotic semi-colon decision.
  - pcwalton 13y ago
    It's a work in progress. We have not hit 1.0 yet. Regarding the semicolon rules, you won't like this observation, but in my 3 years of writing Rust the semicolon rule has literally has never led to a single bug.
    - marshray 13y ago
      I get the feeling that your knowledge of the rules is not necessarily representative of typical post-1.0 developers. :-) However, I don't recall it being a problem in my experimentation with Rust either.
      - TylerE 13y ago
        In my case, it's not a problem with understanding them, it's a burning desire that they not exist.
        klibertp 13y ago
        You realize that it's a matter of aesthetics at best? You could set your editor of choice to substitute character ; with <pink elephant> when displaying code and back when saving it to disk. Have you tried this approach? (It's not an original idea - there is a plugin for Emacs which does exactly this for CamelCase - it displays parts of camel cased words as separate words. Helpful if you have looong camel cased name and are irritated because <back by word> and <forward by word> doesn't take you where you should be)
deleted 13y ago
[deleted]
coldtea 13y ago
>I thought it was a pretty poor language, obviously written by people who'd either never heard of functional languages or never "got" the point of them. Or "got it" and didn't find it any that good, for the types of problems they work on.

rdudekul 13y ago

Good pros and cons of Go language. There is some information around why Go and not say C++/Java/Ruby etc. The statement "I see Rails as the emperor with no clothes on" seems to be made in haste, since Rails is awesome for basic forms based apps.

slaxman 13y ago
I know a lot of friends of mine who have C/C++/PHP background struggle with rails at the start, primarily because of the magic of convention over configuration that happens (they aren't used to it). It takes a while to understand it. But once you understand it, it's a breeze. Disclaimer: I am a Rails developer. My views are therefore biased.
- tracker1 13y ago
  I think that, as with any automagic framework that the edge cases become exponentially more difficult to implement. I'm very comfortable with MV* frameworks on client and server, and still not big on rails. It's also likely that TFA's author was frustrated with performance under load, where Ruby (and Python) generally do not shine.
- Jd 13y ago
  In many ways the problems people have with RoR are the same problems people have with ORMs. They abstract away a lot of the clutter, but then, just as you become totally dependent on the abstraction, you find you need something that you can't get in the abstracted layer. When this thing is a substantial increase in speed, sometimes you are totally f*ed, since to get it you need to toss away a lot of the detritus. For an ORM you can gradually phase away parts of it, but for a web framework generally you can't architect away the box into which your app is placed. I'm unaware of any RoR that has successfully scaled, except by removing Ruby (Twitter). Github is probably the largest existing Rails app (at least that I use), and there are Unicorns aplenty (the new fail whale), or weird caching issues that seem to arise regularly.
  - grey-area 13y ago

bsaul 13y ago

Best sum up of the language i've ever seen (plus it seems completely coherent with what i've supposed so far about that language, both pros and cons). About the "no generic / you have to cast ,recast / the make issue" , could anyone here with a bit of experience gives an example of what that would look like in real code ?

pkulak 13y ago
You pretty much can't write your own container without significant pain. That said, with the built in objects you have a map, list, set (map of bools, which is actually very nice since maps return default types - false - for missing entries), and concurrent blocking or non-blocking queue (chan). Stacks get a bit cludgy, but can be done without too much pain. Apart from those, I've really never had to roll my own collection class. Someday I may, but it is surely not something you need to do very often.
- tptacek 13y ago
  On the contrary, I found it significantly easier to write a custom container (a trie in my case) in Golang than in Ruby (which let's stipulate is pin-compatible with Python). In particular, Golang provides fine-grained control over memory layout, and is even expressive enough to implement allocators, both of which are practically impossible in Ruby. It's true that Golang grants a very useful power to its builtin maps, which makes it rankle that you have to cast in and out of interface{} to make your own general-purpose container. But apart from the fact that interface{} is a stupid name, I don't find it much more painful to write general purpose containers in Golang than I found it to write templated containers in C++.
  - pcwalton 13y ago
    Go does not provide fine-grained control over memory layout when you use interface{}.
- nickpresta 13y ago
  You should actually be using a `struct{}` as the value, as it takes no space (opposed to a bool). http://play.golang.org/p/KK1ymLzd_e http://play.golang.org/p/KK1ymLzd_e

fbomb 13y ago

For me, no templates + no exceptions = DOA.

deleted 13y ago
[deleted]
jeremiep 13y ago
Exceptions I can easily live without; Haskell's monads provide a much better mechanism for error handling (Maybe, Either, IO, etc).
- klibertp 13y ago
  You have generics^2 if you're using Haskell, so it's no wonder they are able to replace exceptions ;)
masklinn 13y ago
Go has exceptions (panic/recover). They're pretty bad, you shouldn't use them (just as you generally shouldn't use exceptions in Erlang) and some in the Go community downright refuse to accept that they exist, but they're there.
TylerE 13y ago
Templates are a sad hack in place of true hygenic compiler macros.
- marshray 13y ago
  Macros are the sad hack. Templates can express compile time assertions.
  - TylerE 13y ago
    I believe you misunderstand me. I'm not talking about preprocessor macros, but TRUE compiler macros ala Lisp or Clojure, which can bring the full expressiveness of the language to bear on the task at hand, and generate program code as a return value. Consider the following example, from Clojure, which implements a C-style for-loop (defmacro for-loop [[sym init check change :as params] & steps] (cond (not (vector? params)) (throw (Error. "Binding form must be a vector for for-loop")) (not= 4 (count params)) (throw (Error. "Binding form must have exactly 4 arguments in for-loop")) :default `(loop [~sym ~init value# nil] (if ~check (let [new-value# (do ~@steps)] (recur ~change new-value#)) value#)))) Syntax primer: The code runs at compile time, forms (nested parenthized groups) that are prefixed with ` are the output, ~var means to substitute the _value_ var from the macro invocation, and var# means create a new anonymous variable var, guaranteed not to clobber or shadow any existing variable. For instance, given out macro defined above, say we make the following call: (for-loop [i 0, (< i 10), (inc i)] (println i)) The code generated by the compiler for that invocation is: (loop* [i 0 value__95__auto__ nil] (if (< i 10) (clojure.core/let [new-value__96__auto__ (do (println i))] (recur (inc i) new-value__96__auto__)) value__95__auto__)) You can see how A: all the error checking is done at compile time and comes at no runtime cost B: how the `-quoted code in the original macro gets "filled in". C: How the arguments to the macro are not evaluated by the macro call or the substition until they are actually used. Point C is quite powerful since it means that macros can be used to create arbitrary control structures that are fully as powerful and general as anything in the core or stdlib - and in fact many of those are implemented as macros.

bayesianhorse 13y ago

OH: "Any tips for getting started with Go?" Answer: "Yes, try Python."

coldtea 13y ago

Imagine if the Go team listened all those that want Generics in Go. It would be more consistent and closer to perfect language. As it is, it's a PITA 20% of the time. (Sure, some say they use it and don't feel a need of generics. Most do however, and it's a constant in every review, even by people using it for core infrastructure).

tptacek 13y ago
What kinds of things have you written in Go, where the language has been a PITA to you?
- jff 13y ago
  "Well I would write things in Go, but I keep hearing about this generics thing so I'm just going to complain about it instead"
  - coldtea 13y ago
    Yes, because nobody both uses a language AND has a legitimate complain against it. Well, I for one have both. As lots of people. And in fact, it's quite common. Anyone that used a language should be able to tell you several pain points about it. Except if he is in his idiotic "oh, this is so much better than the blub that I used to use, it's perfect" stage. Have you even read TFA? The guy evaluated the language, done a project with it, and still wants generics.
- Djehngo 13y ago
  Data structures usually, If you want to write a linkedhashmap or a dictionary where the keys are autogenerated from the values or any kind of structure not built into the language you are forced to either roll a new structure for each set of types or cast everything to and from (empty)interfaces. While it's still possible with the casting, it doesn't feel as nice as the rest of the language does. The other case seems to be any kind of generic pattern with channels, it's possible to build a channel-pair which acts as a single channel with a buffer only bounded by memory, but you can only do it for a single type. All of these are avoidable or maybe even inadvisable, but it still feels like a hole in the language when you go to do something which is common, useful and trivial in C++/java/C# and you have to use ugly hacks or deal with heavily reduced functionality, especially when the rest of the language is so nice.

jlarocco 13y ago

Articles on Go are getting a little boring. The majority are written by people who've spent an afternoon looking at Go and decide to rehash the same 5 bullet points. In the time it takes to read their "article" I could learn the same stuff, better, by reading the official Go tutorial. Some in depth reviews based on actually using it for an extended period of time on a large project would be nice...

tptacek 13y ago
I agree about the articles themselves but vote them up because I tend to learn things on the resulting threads.
- frou_dh 13y ago
  Go threads aren't as fun to read without uriel scolding non-believers for their bad taste.
  - pjmlp 13y ago
    As non-believer I miss my discussions with him.
    - happy_dino 13y ago
      I still wonder why Go is so prone to religious fanboys, though.
zeeboo 13y ago
The problem is that even those are boring. I've used Go for an extended period of time on a large project and there's nothing to report. It works just like what everyone else already says.
- Arnor 13y ago
  That's what's awesome about it! Everybody who uses it gets the same impressions of it (EDIT: and those impressions are 95% good). What other language has that going for it?

dvt 13y ago

This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository" -- is unfounded. Even though there may be some good reasons why one might use Go instead of C/C++, I find it hard to justify using Go instead of Python/Ruby/JS/Java (the only criticism of Java - that it's verbose and hard to tune - is questionable as well). I've said this before. I like Go. I contributed to Go. I've used Go and I still use it from time to time. But much like D, I don't think it has a niche. There are magnitudes more libraries and resources available for Python/Ruby/JS/Java -- thus far, it's been more than enough to sway me into using those languages (mostly JS/Java) instead of Go.

pron 13y ago
I share the sentiment. People often mention that Go is less verbose than Java like they were talking about Clojure or something. Go is just a little less verbose than Java (other than in a hello world example), and targets the same conceptual "level" (same order of abstractions, same "distance" from the metal, although Java can get closer to metal than Go). So, sure, it feels a little more modern in some respects (and less modern in others), but when considering both languages carefully, I find I really need a magnifying to tell the two apart. If Go had offered everything that Java does, I still wouldn't have had a compelling reason to switch because the differences are just too small. But Go doesn't offer everything Java does. Like you said, Java's ecosystem dwarfs Go's. Java has dynamic linking, runtime code instrumentation, unparalleled tooling, and better performance than Go. The only advantage I see Go has over Java is a shorter startup time, which makes it a reasonable choice for writing command-line programs. As for concurrency constructs, Java is far more flexible than Go, and because goroutines and channels are easy, I've ported them to Java[1] (and Clojure). Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM. In reality, it's just a recent, beginner-friendly Java without the awesomeness of the JVM. (P.S. I'm not sure Java's often mocked factory-factories aren't simply a result of the huge number of multi-million LOC programs that have been written in Java. It's just experience, and Go sure doesn't have the necessary abstractions to make engineering large systems any easier. Other recent languages -- sure -- but not Go) [1] https://github.com/puniverse/quasar https://github.com/puniverse/quasar

codezero 13y ago

I agree with most of this post, but I actually found online resources (especially golang-nuts and various SO pages) to be very helpful with debugging.

VeejayRampay 13y ago

I see it's become trendy to poke fun at Rails and the hurdles it puts on your way to "scale". Not only have many companies been able to do so using Rails, but it also completely overshadows the ease it provides to get started in the initial phase of a project. That being said, Go really seems like an awesome language, I've dabbled some and I can't wait to get back to it.

oakaz 13y ago

"The standard library is missing x" What you are looking for is actually a productive community with a good module manager. This what Golang is missing. (Golang fans: don't get me wrong, I use and love Go.)

dakimov 13y ago

Another dumb and unconvincing ad of Go. Go must go. There is enough shit languages already, and Go being one of the worst modern languages. It doesn't even feel modern. It is so poorly designed that it feels like some talentless experimenting from 70's.

stcredzero 13y ago

> C++: too much rope, hard to maintain, painful to introduce at a company with no prior C++ footprint, frightens junior devs who no longer absorb relevant memory management idioms in school So, are we now in an era when there are lots of people in the job market who couldn't write a doubly-linked list to save their life? When I was in my 20's, I noted that there were lots of programmers around who basically treated compilers as "magic" and hadn't the tiniest inkling about how they worked. Now that I'm in my 40's, I've noted "so what" attitudes in languages that require manual memory management. (iOS and Objective-C. ARC goes a long way, but it still doesn't take care of everything for you.)

tropicalmug 13y ago
I am one of those programmers: I have no real idea how a compiler goes about its business, my university does not offer an accessible compiler class (only for grad students and very irregularly), and I have no idea where to start besides trying to force my way through the purple dragon book. What are things I should know about compilers that I probably don't? What is suggested reading on compilers?
- xtracto 13y ago
  I am not an expert in compilers, but in my undergrad compiler's class one of the things I remember the most are parsers (such as LALR). I remember having a great time implementing different types of parsers: http://en.wikipedia.org/wiki/Category:Parsing_algorithms http://en.wikipedia.org/wiki/Category:Parsing_algorithms I think the dragon book is the absolute reference for learning compilers: http://www.amazon.com/Compilers-Principles-Techniques-Alfred-Aho/dp/0201100886 http://www.amazon.com/Compilers-Principles-Techniques-Alfred...
- stcredzero 13y ago
  As xtracto mentioned, parsing and enough automata theory to understand what context free grammars are and where they fall should be part of your basic toolkit, but how they generate code is even more useful to C programmers. (One study done decades ago found that the average C statement resulted in 2.7 CICS assembly language commands.) The Dragon Book is not the best teaching tool out there. Maybe try The Elements of Computing Systems Chapters 10 & 11? You might need to peek at the earlier chapters to get a grounding in the particular assembly language they use.

electrotype 13y ago

"Java: too verbose, too many FactoryFactories, painful to tune" Paintful to tune... Maybe. But I don't understand why so many people say patterns like FactoryFactoryFactories are inherent to Java! I can write Java code with NO factories at all. Writing shitty and unflexible code is really easy. When you understand why a factory is used in a particular piece of code, you start to appreciate it! It's also very possible to write C++ or Python code with too many overengineered components. Also, I like a language to be verbose, I don't think it is an issue. As long as the code is clear and easy to read... And it's often the case with Java programs. For my eyes, Java is way more readable than, let's say, Perl, Scala or Clojure. I couldn't care less about the number of lines required to achieve the same result! I'm getting tired of this Java bashing... The only thing that really sucks about Java is Oracle!

pron 13y ago
Even Java bashers would concede that Java is a brilliant language, certainly for its time. And the JVM is the most impressive programming environment to this day. But the language has become a little dated. Oh, you don't need to go as far as Scala to fix it (to me Scala feels like a deranged, haphazard combination of javascript and Haskell), but something like Kotlin could really be a "better Java" (it also happens to be a better Scala, but that's a different point).
sarnowski 13y ago
In fact, since go does not have explicit constructors, it encourages the factory pattern all over the place. You'll find static factories everywhere in the go library. http://golang.org/doc/effective_go.html#composite_literals http://golang.org/doc/effective_go.html#composite_literals
- deleted 13y ago
  [deleted]
tomp 13y ago
In modern languages, you don't need to write a class when all you need is a first-class function.

dvirsky 13y ago

I know it's not a popular view, but being pretty much in love with Go, what I find most difficult about it is the lack of any real IDE. And by real IDE I basically mean: a rich editor, stable code completion, jump-to-declaration etc; and tight debugger integration. Unless I'm really unaware of an IDE that has all of them, all the IDEs that support Go fall short: 1. IntelliJ plugin - excellent editor, a lot of the intellij goodies; but I've managed to break the code completion, and it's tricky to configure with respect to GOROOT and GOPATH. and most importantly, no GDB integration whatsoever. 2. GoClipse - reasonable (although buggy) debugger integration, very good code completion, no jump to declaration which is a pain, plus a wonky build system - the build can fail and you see no message, and the program just runs from the previous build. 3. Sublime with GoSublime and SublimeGDB: the build system is buggy, code completion is great (managed to break that too on complex projects), no jump to errors, don't remember re jump to source. I had to do a lot of voodoo to get SublimeGDB to work half decently, and even that was not very robust because SublimeGDB is buggy on its own. 4. LiteIDE - has everything in theory, but just feels a bit clunky and hard to configure. I didn't like it as an editor and haven't spent much time with it. But it's constantly improving so I hope it will get there some day. The rest are Windows only so out of the question, less complete/mature than those 4, or vim with plugins. I don't like vim, I like graphical IDEs, shoot me. :) Again, I really really love Go, I hope it will allow me never to write C++ again in my life. This is not a "Go is not ready yet" gripe. It's just what I find most difficult about it.

TylerE 13y ago
Just curious, but what issues did you have with GoSublime builds? It's using the `go` tool under the covers.
- dvirsky 13y ago
  A few are just UX quirks - ctrl+b tries to build from the current package, not the project root, leaving you tabbing to main.go for each recompile, which is annoying; cursor "runs away" from the prompt not affecting anything. but mostly, the output is buffered. I wrote a toy MapReduce framework that yielded tons of output. It crashed Sublime because it buffered the entire output into the console instead of printing it into some sort of FIFO buffer like IntelliJ or Eclipse do. Again, running from a terminal is ok, but the whole point of an IDE is to save you from fiddling with lots of windows and terminals.

rubiquity 13y ago

I'm getting sick of all these Go goroutines... err threads.

pjmlp 13y ago
You mean Modula-2 co-routines. :)

st3fan 13y ago

How is "deploying modern Java applications, which is a minor nightmare IMO" true? Dropping a .war file in a directory is hard? Or am I missing something about 'modern' Java apps?

mwcampbell 13y ago

I agree with the point about statically-linked binaries. However, I wish there were a compile-time facility for including the contents of a file as a read-only byte array in the binary. Then web application servers with HTML templates, and even images and other assets, could be truly self-contained.

lectrick 13y ago

The more I learn about other langs, the more I appreciate the language design of Ruby, even though Ruby is slow as shit.