29 ms·

Leaving Go

214 points by beNjiox 12y ago

pjmlp 12y ago
I had similar reasons, but on my case the language was still at pre-1.0.
- ewood 12y ago
  May I ask what languages you tend to favour? I've had a few friends tell me lately that they were all giving up on Go after persisting with it since early 2010. They are all people who tend to work in C/C++ so they don't tend to be thrown by a steep learning curve. I'm quite surprised because they were all vocal proponents in the beginning.
  - pjmlp 12y ago
    Java, Clojure, Scala, Haskell, C++, OCaml, C#, F#, D, Rust, Ada.
DAddYE 12y ago
> I’ve been using Go since November and I’ve decided that it’s time to give it up for my hobby projects. I’d still be happy to use it professionally, but I find that programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. I can't leave go, but indeed I think absolutely the same. The thing is that GO was designed to replace c++ thing that absolutely failed. So we have a python/ruby replacement with very old patterns (I think manual checking errors ie.). Indeed I think go is an awesome language but sometimes I really feel like a monkey repeating myself over and over again.
- lmm 12y ago
  Why can't you leave go? Haskell may have a steeper initial learning curve but I can't think of any environment where go is usable and Haskell isn't. (To me OCaml seems like a better replacement for a lot of what people are doing in go, but admittedly it doesn't have the same concurrency support)
  - DAddYE 12y ago
    Because go recently is on hype and thus many companies started to use it (the one where I work included).
- coherentpony 12y ago
  >The thing is that GO was designed to replace c++ thing that absolutely failed. I was so excited for GO to become a nice replacement to C++. GO has awesome build times. C++ has awful build times. This is partly due to all the extra work the C preprocessor has to do make sure all the headers are present. The big lose for me is the fact that GO has absolutely no operator overloading. This is one of the biggest wins in C++, especially since I do lot of high-performance scientific computing. Overloading operators makes code a lot more readable and user friendly, in my opinion (I'm others will disagree, though). I'm aware that you can hack GO to mimic operator overloading but it involves hitting the vtable. And hitting the vtable is completely unacceptable in performance-critical code.
  - StefanKarpinski 12y ago
    I wrote this analysis [1] in the context of Julia vs. C++ about why I think that Go has not been successful as a C++ replacement. The primary issues are performance (the ability to trade off abstraction for performance, really), generics, and operator overloading. We did not intend for Julia to be a C++ replacement, but it turns out that it's quite a good one and a lot of adopters have come from C++ – I think that these features are why. [1] https://groups.google.com/forum/#!msg/julia-users/-SGWPUBJKqo/g1voeUDxCpgJ https://groups.google.com/forum/#!msg/julia-users/-SGWPUBJKq...
  - giovannibajo1 12y ago
    Go is also easy to parse, AFAICT, both syntactically and semantically, and they ship a parser in the standard library. While absolutely not implying that it's a reasonable alternative, someone could try implementing infix operators as a syntactic layer on top of Go (kind of a preprocessor). It might work to fix the use case presented in the OP (math operators being far more readable in their infix form). Infix operators might just be implemented as a syntactic sugar layer after all, at least as a first draft; if you're able to parse a Go source file and its types in a way that when you see a sum expression, you already know whether both arguments implement a Numeric interface and/or Add method, you might be halfway through. To clarify: I love infix operators and I'd love if Go added them, and I consider the above just a hack.
  - 12y ago
- _ak 12y ago
  Go wasn't designed to replace C++, Go was designed to replace C++ at Google. And it totally succeeded at that, given the list of critical infrastructure at Google where Go is used, and in some cases has replaced existing C++ implementations.
  - DAddYE 12y ago
    Not sure if this was the same feel of Rob. > I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
    - _ak 12y ago
      Yes, but he was talking programmers out there, not Google. IIRC, in 2012, they were still _very_ reluctant to talk about any use of Go within Google, with vitess being the only exception.
- dragonwriter 12y ago
  > The thing is that GO was designed to replace c++ thing that absolutely failed. I don't think Go was designed as a general replacement for C++, I think it was designed as a replacement for C++ for the things that Python was almost better than C++ for, but not quite. EDIT: Though, OTOH, I do get the feeling that the people who designed Go largely are the type of people who feel that just-plain-C is a superior choice to C++ for most of the rest of the domain where C++ might be used, so they might view Go as a general replacement for C++, because they start with a smaller view of C++'s useful role than the market at large has.
- moreentropy 12y ago
  > So we have a python/ruby replacement with very old patterns (I think manual checking errors ie.). Before using Go, I have always programmed with "modern" languages that use exceptions for error handling. So the concept of only doing manual error handling was new to me, but after a few months of golang I love it now and exceptions in python started to really annoy me. In Go, I'm forced to do error handling right after every single call that will possibly return an error. While I thought that the resulting code looked ugly and repetitive, the result is a much more focused and intelligent error handling. If i wanted the same granularity and robustness of error handling in python, I'd have to put a catch all try..except block around every single call . Exceptions are a good time saver in stateless request based programs (like HTTP/web stuff) where it's sort of accetable if one request fails. I could just not care so much about detailed error handling, the worst that could happen is that i don't catch some error and the wsgi wrapper will catch it and return error 500 to the client. But building daemons in python is just plain painful. If I don't want my program to crash at some point I have to reckon that anything can raise an exception I didn't think of.
vfclists 12y ago
Try Nimrod. Or Julia. I haven't tried them yet, but it looks like their fun.
- zoowar 12y ago
  Julia is not fun. We expect it to be fun, like python, but it's not.
  - herokusaki 12y ago
    Can you elaborate why?
    - xioxox 12y ago
      I was interested until I discovered Julia doesn't have a useful form of OOP inheritance. Ok, you don't always need it, but for some things it's indispensable (e.g. using widget/window systems).
      - one-more-minute 12y ago
        That's a bit like saying, for example, Python isn't interesting because it doesn't have monads (and they're essential for managing state, or whatever). Different languages have different ways of doing things, and lacking feature X isn't necessarily a deficiency. Julia generally favours composition over inheritance. You might be interested to look at GTK.jl, its widget/window system. https://github.com/JuliaLang/Gtk.jl https://github.com/JuliaLang/Gtk.jl
      - pjmlp 12y ago
        There are lots of ways of doing OOP, the Java/C# world isn't the only way,
  - one-more-minute 12y ago
    That's not really a fair statement – plenty of people (me included) find Julia to be a lot of fun. I'd be interested to hear why you think that, though. If the OP is looking for a C++ alternative and knows Haskell, Rust is also an interesting alternative, although it's at a very early stage of development.
chimeracoder 12y ago
As someone who writes both Lisp and Go (and enjoys both), I find it odd that this article uses Lisp and Haskell as points of comparison. > programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups). In fact, this is almost an intentional "feature" of Go: http://aerokode.com/blog/go-is-boring http://aerokode.com/blog/go-is-boring > The idea is that there’s simply no way that any group of designers could imagine how people will want to use their language so making it easy to extend solves the problem wonderfully. On the other hand, there's no way of making a language so easily extensible while also maintaining relatively uniform idiomatic, design, and style conventions across a language community. Go very heavily favors the latter. > In Lisp, CLOS (Common Lisp Object System) was originally a library. It was a user defined abstraction that was so popular it was ported into the standard. CLOS is actually very similar in some ways to Go's structs. Both emphasize encapsulating data inside an "entity" (object/struct), and separating the notion of behavior from that entity. To quote one of the language authors from GopherCon[0]: "Interfaces separate data from behavior. Classes conflate them." Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness. It's a stronger assertion of the Pythonic motto, "There should be one, and preferably only one, obvious way to do it". [0] https://twitter.com/chimeracoder/status/459827405386162176 https://twitter.com/chimeracoder/status/459827405386162176
- masklinn 12y ago
  > CLOS is actually very similar in some ways to Go's structs. You've completely missed the article's point: users were able to create CLOS before it got integrated in the language.
  - chimeracoder 12y ago
    Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and incorporating the results of that into Go. The fact that users are able to create core language features has its drawbacks when it comes to cohesion in the language community. Lisp itself is a perfect example of this - codebases are immensely fragmented in terms of which libraries they end up using (Quicklisp is, in part, an effort to solve this). Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness. Both are legitimate philosophies for different use cases, but that's why it's kind of silly (IMHO) to compare Go to Lisp - the goals are not only different, but diametrically opposed in most ways.
gdulli 12y ago
The agreeableness of Python is the reason I settled on it after experience with a bunch of other languages. I was starting to find software engineering to be a chore and was losing interest in it until I started using Python. No language is best at everything, and all the ways python isn't the best have been worked around without much bother. Go did not strike me as a language I would enjoy writing, despite the strengths it surely has in some areas. I would just be giving up other strengths I prioritize more highly.
- camus2 12y ago
  Frankly python is good enough for most things. It's not perfect but it's one of these languages you can really use for anything(like java). I'm not fan of the syntax though,I prefer ruby's(ruby is not for "everything" unfortunatly). I've seen insane stuff done in python (3d games,gui apps,complex network tools...) running quite well on my old mac. Go is relevant where you want pretty good performances and concurrency with low memory footprint(unlike java) ,without using C/C++ and threads. But it's clearly not for everything.
lmm 12y ago
Does anyone actually use CLOS? It's always held up as this great example of language extensibility, but my impression is that since it's not part of the core language Lisp folk tend to create their own abstractions instead.
- piokuc 12y ago
  Not sure what you mean by "not part of core language" - CLOS is part of ANSI Common Lisp standard.
  - jimktrains2 12y ago
    It wasn't always that way. It use to be just a lib iirc.
    - piokuc 12y ago
      Well, CLOS became part of ANSI Common Lisp standard 24 years ago...
    - Jtsummers 12y ago
      Beat by a few minutes again, as piokuc says, it's in the standard. But even so, it may still be implemented as "just a library" in some CL implementations. That's the beauty of the language, it's so versatile you can extend it within itself, and it really feels like a language extension and not like you're accessing yet another API. If someone wanted a different object system, they could produce it within CL giving totally different OO semantics.
taylorlapeyre 12y ago
I just wanted to point out that the author of this article is a high school student. http://jozefg.bitbucket.org/about.html http://jozefg.bitbucket.org/about.html
- tdees40 12y ago
  Wow, "writing lots of compilers and type checkers" definitely wasn't on my radar screen when I was in high school.
  - pjmlp 12y ago
    I did an informatics technical degree on high school back in the early 90's in Portugal. We had introduction to parsing and basic language processing.
  - Jtsummers 12y ago
    Me neither, but a classmate was reading over/working through the dragon book our senior year of high school. There's a reason he went to CMU and I didn't. On the other hand, compilers (well, a less than formal version) was the third CS course topic at GT. Definitely approachable, with good faculty/staff, as an early topic of study.
  - zura 12y ago
    I was reading Crenshaw's "Let's Build a Compiler" txt file. Good memories :)
- camus2 12y ago
  How does it make the OP less relevant? i know pretty smart programmers that are still in high school. And tt doesnt matter, the guy obviously knows Go.
  - taylorlapeyre 12y ago
    My implication was that the article was very professional and I was quite impressed that it was written by somebody so young. I think that it makes it more relevant, not less.
pron 12y ago
It's ironic that the "better" the language (for some hazy definition of "better") the less actual work seems to get done with it. So Go can be pretty annoying at times, and so can Java (I've said before that I find the two almost identical, but that's beside the point now); and C is horrible and completely unsafe and downright dangerous. Yet more useful working code has probably been written in Java and C than all other languages combined since the invention of the computer, and more useful code has been written in, what, 5 years of Go(?) than in 20(?) years of Haskell. Here's the thing: I am willing to accept that Haskell is the best programming language ever created. People have been telling me this for over 15 years now. And yet it seems like the most complex code written in Haskell is the Haskell compiler itself (and maybe some tooling around it). If Haskell's clear advantages really make that much of a difference, maybe its (very vocal) supporters should start doing really impressive things with it rather than write compilers. I don't know, write a really safe operating system; a novel database; some crazy Watson-like machine; a never-failing hardware controller. Otherwise, all of this is just talk.
- Dewie 12y ago
  Maybe it turns out that the sociological side of programming trumps the technical side; that languages that forces or fosters a common vocabulary will always "win" over languages where you have so much power that you can easily diverge from the mainstream dialect, and there is not much culture of restraining this freedom. On the other hand, these dialects are embedded DSLs; specialized languages created and hosted by a base language. People seem to balk less at the idea of DSLs compared to the idea of powerful languages.
  - astine 12y ago
    I think that part of the problem is that more 'powerful' languages often more concept heavy than more 'pragmatic' languages and that makes them harder to learn for a lot of programmers. Take Clojure for example. A lot of people including myself like this language a lot, but to be productive in it, you have to get used to the JVM, Lisp s-expressions, a heavily functional programming style with few side effects, a significant break from a normal approach to OOP, and Clojure's distinctive concurrency constructs which are more complex than Go's. It's not that any one of these things is hard, but you have to know all of them. Unless you have Lisp, or Haskell (or similar) experience, the only one you're likely to know is the JVM, and even then, maybe not. This isn't like C++ or Java which are huge languages with a lot to wrap your head around but at core simply reuse concepts that most programmers are familiar with, (OOP, basic types) It's the very things that make the language interesting to begin with that makes it trickier to pick up. Most of this holds for Haskell, Erlang, etc. Then again, real code is written in these languages, but they don't tend to dominate.
Kiro 12y ago
What is the definition of fun when it comes to a programming language?
- DAddYE 12y ago
  It's subjective, for me is DRY (don't repeat yourself) and achieve a "big" result with a small (but readable) effort.
tptacek 12y ago
If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you. Similarly, if you're looking for a language that will read and write like a specification for your problem domain, so that writing your program has the side effect of doing half the work of proving your program correct, Golang is also not a good choice. What's worse, those two approaches to solving programming problems are compatible with each other. Lots of sharp programmers deeply appreciate both of them, and are used to languages that gracefully provide both of those facilities. If that describes you, Golang is a terrible choice; it will feel like writing 1990s Java (even though it really isn't). There are two kinds of programmers for whom Golang will really resonate: Python and Ruby developers who wish they could trade a bit of flexibility, ambiguousness, or dynamicism for better performance or safer code seem to like Golang a lot. Naive Golang code will outperform either Python or Ruby. Golang's approach to concurrency, while not revolutionary, is very well executed; Python and Ruby developers who want to write highly concurrent programs, particularly if they're used to the evented model, will find Golang not only faster but also probably easier to build programs in. Systems C programmers (not C++ programmers; if you're a C++ programmer in 2014, chances are you appreciate a lot of the knobs and dials Golang has deliberately jettisoned) might appreciate Golang for writing a lot like C, while providing 80% of the simplicity and flexibility value of Python. In particular, if you're the kind of programmer that starts projects in Python and then routinely "drops down" to C for the high-performance bits, Golang is kind of a dream. Golang's tooling is also optimized in such a way that C programmers will deeply appreciate it, without getting frustrated by the tools Golang misses that are common to other languages (particularly, REPLs). At the end of the day, Golang is overwhelmingly about pragmatism and refinement. If you're of the belief that programming is stuck in a rut of constructs from the 1980s and 1990s, and that what is needed is better languages that more carefully describe and address the problems of correct and expressive programming, Golang will drive you nuts. If you're the kind of person who sees programming languages as mere tools --- and I think that's a totally legitimate perspective, personally --- you might find Golang very pleasant to use. I don't know that Golang is a great language, but it is an extremely well-designed tool.
- DAddYE 12y ago
sandGorgon 12y ago
>Ok, it’s only a few characters, big deal. Now what does this do? >b.Mul(b).Sub(big.NewInt(4).Mul(a).Mul(c)) >Or in Haskell >b * b - 4 * a * c umm.. correct me if I'm wrong, since I'm not well versed in either Haskell or Go, but doesnt the Golang version read better in terms of scoping. I mean just by reading the Go version, I know what it will evaluate to, but in the Haskell version I dont know the precedence order just by reading.
- Dewie 12y ago
  I'm pretty sure that the precedence is the same as in the usual convention of arithmetics. You can ask for it in GHCi (the REPL): > :i (-) > [...] infixl6 > :i ( * ) > [...] infixl7 So ( * ) has precedence over (-). The expression is then: (b * b) - (4 * a * c) Personally, I don't know if infix syntax is truly overall more readable than purely prefix/postfix syntax, or other such uniform representations. It might be for arithmetic, because it is so ingrained, but the precedence order was never hammered into me to such a degree that I learned it automatically by heart; I used to defensively make more parenthesise than I really needed to, just in case.
- grayclhn 12y ago
  I do, and I don't even know Haskell: (b * b) - (4 * a * c) edit: I don't know go, but I assume the go example is intentionally unreadable. But complaining about infix multiplication and subtraction is... curious.
  - jerf 12y ago
    No, that's pretty much what the Go would look like, for any non-standard numeric type. (Though it does need to be a non-standard type, like a "bigint"... a merely type-wrapped standard type ("type Feet uint32") can still have arithmetic done to it.)In fact the default go fmt rules won't even let you put whitespace in there. However, my general call on that is that if you need your language to provide overloaded arithmetic operators, stick to languages that actually want to give that to you. It comes up a lot in language discussions because it's such an easy example to type out in a couple of lines, but in practice I don't think you see a lot of need for exotic int types being used pervasively throughout your code. Don't use Go for that. Don't use any language that doesn't do operator overloading. But this is far less a common use case than seems to be supposed... a variant of the "look under the streetlight" fallacy, I think. Go's really for heterogeneous concurrent business- or server-like programming. It isn't a language for mathematics, and the burst of libraries I've seen in the last couple of weeks that seem to be focused on that is bizarre to me. Go isn't good at that, isn't meant for that, and probably never will be. Go's nice for the very large niche that "business- and server-like programming" is but it's not so fantastically wonderful in every way that I'd want to work too hard to make it work in a niche it's not really suited for.
Donch 12y ago
The example could have been simplified: func abs(x Top) Top { switch v := x.(type) { case int32: if v < 0 { return -v } case int64: if v < 0 { return -v } case float32: if v < 0 { return -v } case float64: if v < 0 { return -v } } return v }
- bunkat 12y ago
  This code doesn't actually compile. You can't assign v to x.(type) like that.
  - jerf 12y ago
    Are you sure? http://play.golang.org/p/dJC328-rh8 http://play.golang.org/p/dJC328-rh8 I did have to put "return x" as the last statement, though, not return v. And I'm not sure I'm happy about an "abs" that happily returns a string if fed a string, but, well, that's Go. Relevant bit of the spec: http://golang.org/ref/spec#Type_switches http://golang.org/ref/spec#Type_switches
    - Donch 12y ago
      It's horrible method with a horrible signature, that I didn't test :-) But the short variable declaration in the type switch does indeed save the casts the OP was complaining about. Even more correct and horrible: http://play.golang.org/p/ZMQKQhuUQT http://play.golang.org/p/ZMQKQhuUQT
    - bunkat 12y ago
      Yes, the return statement was what I was referring to. You can't use a type switch to do some sort of an implicit conversion that exists outside of the switch statement.
- bsdetector 12y ago
  This isn't simpler, it's smaller. In fact it's more complicated, since instead of 4 completely separate cases you have 4 half-cases and a default. For instance, pass a positive int16 and you get the right answer, but pass a negative int16 and you get a useable but wrong answer instead of nil from the original.
piokuc 12y ago
I think people gave Go a lot of credit just because it was designed at Google. People have high respect for Google engineers and so they assume what Googlers have designed must be flawless. So they take for granted ideas like lack of exceptions or lack of operators' overloading being a good thing, even though I'm quite sure they would be quick to criticize such BS if that was a feature in a language not coming from Google. But, in the long run, the language must defend itself on its own, without the authority of people/organization behind it.
- bookwormAT 12y ago
  I think people gave Go a lot of attention because it was designed by Rob Pike and Ken Thompson.
  - piokuc 12y ago
    I have a feeling that the attention would be much more modest if they happened not to be on Google payroll when they designed the language. Anyway, whether it's because of Ken or Rob, or Google brand, it doesn't change the point I was trying to make.
- rakoo 12y ago
  I think people gave Go a lot of credit just because it gets a lot done, especially comparatively to the time taken to learn it, and the stuff you come up with can very well be used in production because you made it robust thanks to the excellent built-in testing and profiling tools. What's interesting with go is that if you can program, you already know it; all your time is spent building stuff, not learning the language. And when it comes to building stuff, Go is just straightforward.
ChuckMcM 12y ago
This is a great rant. Having recently done the 'golang' tutorial on the site a lot of it resonated with me. I have a slight advantage in that I worked at Google when Go came into existence and followed some of the debates about what problem it was trying to solve. The place it plugged in nicely was between the folks who wrote mostly python but wanted to go faster, and the folks who wrote C++. It was a niche that Java could not fill given its structure. In a weird way, it reminds me of BLISS[1]. BLISS had this relationship to assembler that "made it manageable" while keeping things fast. BLISS was replaced by C pretty much everywhere that C took hold (one theory is that BLISS is the 'B' programming language, Algol is the 'A' language, personally I think BCPL is a better owner the the 'B' moniker). The things that C has issues with, memory management, networking, and multi-threading, Go takes on front and center. It keeps around some of the expressiveness and type checking that makes compiling it half the battle toward correctness. Now that was kind of what the Java team was shooting for as well but with limited success. I feel like between Go and Java we've got some ideas of what the eventual successor language will look like. For me at least that is a step in the right direction. [1] http://en.wikipedia.org/wiki/BLISS http://en.wikipedia.org/wiki/BLISS
Jabbles 12y ago
As much as I want to emphasize that this is not the right way to think about programming in Go, I do want to point out that the example has a lot of extra code that isn't needed. Indeed, it's not really possible to have a bug of the kind the author wrote if written properly: http://play.golang.org/p/puZBEmOVaI http://play.golang.org/p/puZBEmOVaI
- DocSavage 12y ago
  The explicit type switch also lets you streamline handling of uint8, uint16, etc (just return value) and panic or error if given a type you don't expect. But I find it unfortunate that type switches must have single type cases. For example, it's too bad this doesn't work: http://play.golang.org/p/a4j1I6Oug- http://play.golang.org/p/a4j1I6Oug- The OP's complaint would be minor if the compiler would auto-unroll the multi-type case clause.
  - deleted 12y ago
    [deleted]
personZ 12y ago
These sorts of posts are profoundly boring. I know people will up arrow it -- some sort of spiteful "Down with Go!" contrarian thing, when they aren't talking up rust -- but it isn't because the content is interesting or illuminating, but rather as some sort of activist thing. This particular piece (by a high school student, as an aside) starts off trying to create a surrogate for generics in Go. Don't. Here's the thing -- most of these posts are not about people making real code, but people making -toy- code. Where every function is all things to all people. The number of times I've needed a generic abs in my life -- zero. The number of times I've needed a double floating point abs in my life -- every single time. That's the thing about generics and real, actual world code: Your types are generally much less amorphous than you think. They really are. This illusion that everything needs to be everything just does not hold in the real world. But it is always the tiring example used against Go. Boring.
- azth 12y ago
  > The number of times I've needed a generic abs in my life -- zero. What about a generic max() or min() function?
  - cgh 12y ago
    Or a generic list, vector, map...
    - personZ 12y ago
      Go's native synonyms of lists, vectors and maps are already "generic", so I'm not sure what your point is.
      - cgh 12y ago
        Except the containers aren't typed. They are essentially containers of void*. If you believe that to be "generic", then you don't understand the topic.
        12y ago
falconfunction 12y ago
I'm so glad Go can compile everything quickly, it's almost as fast as an incremental compiler from the 80s.
leccine 12y ago
It is so funny to see that somebody else got annoyed by Go the same way as I did. I could not get over the fact that I cant pass any type to a function other than interface{}. When you do that it just delays the problem and I have decided to not have a generic function but have multiple specific one. This violates the DRY principle but at least works. I am still looking for best practices with Go. I think the biggest advantage of that languages is the fact that Goole uses it in production and the libraries are well tested. The community is great too. Clojure has a way smaller community that limits the usage of that environment quite a bit. I agree with the author on Lisp is being more fun than Go, but that is a single dimension of the entire problem.
eridius 12y ago
> I wanted a fast, compiled replacement for stuff I write in C right now. But Go is not that language. You should look into Rust. It sounds like it might be more like what you're looking for.
- djur 12y ago
  Rust is great but it's still frontier territory right now. The documentation for the standard library is very sparse and stuff like HTTP is still in very early stages. I would only adopt it for production work if you're willing to be very actively involved in the nascent Rust community, follow the mailing lists, fix bugs yourself, etc. On the other hand, if that's the kind of thing that excites you, Rust is a really great option right now.
coldcode 12y ago
All languages suck, at some level. Whether this matters to you is a matter of need, willingness to compromise, and benefits to you, for some definition of you. This often leads to people writing their own language if they can which generally only pleases themselves.
jamra 12y ago
I have a problem with his extensibility critique. I don't agree that having generic types are good for the language. The problem in using polymorphism is that your users are going to abuse polymorphism. There will be class hierarchies that will confuse and abstract from the algorithm at hand. You will be mutating and mangling objects rather than dealing with the issues at hand. Reading a go source file is like following a for loop. It's quite technical. Reading a Java source file can be a case of trying to figure out the high level abstractions of the program.
- twic 12y ago
  The genericity that is being talked about here is parametric polymorphism, not subtype polymorphism. Parametric polymorphism doesn't lead to confusing class hierarchies. Parametric polymorphism doesn't involve inheritance, so it doesn't lead to any class hierarchies.
shurcooL 12y ago
Every design decision has trade offs. Since the author only covers the more obvious negative aspects of those 2 features, I'd like to cover the more subtle positives. > Extensibility One really great thing about that is how consistent it is. Every func in Go has a unique identifier: the package import path and the func name pair. This makes it possible to build tools like godoc.org and the `doc` command that let me look up the exact behavior of (unfamiliar) code. In this case, I can go to godoc.org/math/big#NewInt or type `doc big.NewInt` and see: // NewInt allocates and returns a new Int set to x. func NewInt(x int64) *Int In fact, it's so predictable that I don't have to think. As long as it's Go code, if I ever run into an unfamiliar func F of package P, I can always go to godoc.org/P#F or `doc P.F`. No searching, just an instant lookup. If I need to do 30 such lookups to solve a task, it makes a big difference. This applies to _all_ 3rd party Go packages. That is big. On the other hand, something like `x + y` is magic to me. I know that computers work with bytes at low level, and I want to be _able_ to understand what happens on that level. I understand and accept such magic for built in types. But I certainly wouldn't want to be reading a 3rd party Go library code that says `x + y` on its custom types. Where would I go to find out what that custom plus operator does? How does one make an unexported version of a plus operator? There'd be less consistency, more exceptions and rules, more variations in style and less tools that can be built to assist/answer questions about Go code. > The Type System I don't have time to cover this atm, but there are some advantages to the explicitness and verboseness of Go's approach. Can you think of any? I'm not suggesting it's the best it could ever be, just that there are both advantages and disadvantages that should be considered.
deleted 12y ago
[deleted]
- danieldk 12y ago
  So, how do you enumerate every type that exists or will exist in the future?
stcredzero 12y ago
A 16 year old kid decides that Go isn't suitable for writing an embodiment of Principia Mathematica. Surprise: Haskell is a better Haskell than Go. Go is a something like C, but with a few more features plus GC and come neat concurrency facilities. Why would anyone expect that to be anything like Haskell, or even to have a type system even approaching that kind of power?
ilaksh 12y ago
If you guys like Python and are having second thoughts about Go, take a look at Nimrod. Also, I personally look at Nimrod as a faster and slightly cleaner Python with a few extras, and I don't try to break the compiler using all of its cutting edge features. If you use it that way you will be happy.
deleted 12y ago
[deleted]
bfrog 12y ago
Go's strengths are tooling and libraries. Especially when you see the well written libraries all revolving around internet protocols, encodings, and content generation. It makes it extremely easy to write performant web sites and http API endpoints which many people do daily. All that said I hope Go adds D like compile time code generation and static typing or [D,Rust] gains better tooling and HTTP service oriented libraries and APIs that are as well written as the Go standard library packages are. Secondly I hope [D,Rust] sees how awesome having a common automatic format, build, and test tool is. In so few language is the testing package as simple as Go's. In so few languages is the build process as easy as Go's.
cryptos 12y ago
I've the same feelings about Go. After working several month on a side project with Go, I have given up, because I've felt not as productive as with Java (not to mention Scala). There are lots of annoying things: missing generics leading to a lot of uselesse code which could carry bugs. Without generics you can not create an Option datastructure, but have to return nil (the million dollar mistake of Hoare). Without generics you can not write concise object/functional code like someCollection.map(i -> i * i). Go has no good support for immutability. Mocking is awkward, because you have to code your mocks by hand. Unicode handling is a pain. That is why Go attracts mainly people from scripting languages (they get a bit more type safety and better performance) and C (they get a bit more type safety and less errors). Coming from other languages Go is not that attractive. I'm hoping for Rust to succeed.
rio4223 12y ago
Very well put. I tried Go now for a while and I was wondering why it doesn't appeal to me like for some of my friends. By reading through your response I found the reason for my gut feeling. I guess I belong into your first categorie ;).

Leaving Go

214 points by beNjiox 12y ago

pjmlp 12y ago

I had similar reasons, but on my case the language was still at pre-1.0.

ewood 12y ago
May I ask what languages you tend to favour? I've had a few friends tell me lately that they were all giving up on Go after persisting with it since early 2010. They are all people who tend to work in C/C++ so they don't tend to be thrown by a steep learning curve. I'm quite surprised because they were all vocal proponents in the beginning.
- pjmlp 12y ago
  Java, Clojure, Scala, Haskell, C++, OCaml, C#, F#, D, Rust, Ada.

DAddYE 12y ago

> I’ve been using Go since November and I’ve decided that it’s time to give it up for my hobby projects. I’d still be happy to use it professionally, but I find that programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. I can't leave go, but indeed I think absolutely the same. The thing is that GO was designed to replace c++ thing that absolutely failed. So we have a python/ruby replacement with very old patterns (I think manual checking errors ie.). Indeed I think go is an awesome language but sometimes I really feel like a monkey repeating myself over and over again.

lmm 12y ago
Why can't you leave go? Haskell may have a steeper initial learning curve but I can't think of any environment where go is usable and Haskell isn't. (To me OCaml seems like a better replacement for a lot of what people are doing in go, but admittedly it doesn't have the same concurrency support)
- DAddYE 12y ago
  Because go recently is on hype and thus many companies started to use it (the one where I work included).
coherentpony 12y ago
>The thing is that GO was designed to replace c++ thing that absolutely failed. I was so excited for GO to become a nice replacement to C++. GO has awesome build times. C++ has awful build times. This is partly due to all the extra work the C preprocessor has to do make sure all the headers are present. The big lose for me is the fact that GO has absolutely no operator overloading. This is one of the biggest wins in C++, especially since I do lot of high-performance scientific computing. Overloading operators makes code a lot more readable and user friendly, in my opinion (I'm others will disagree, though). I'm aware that you can hack GO to mimic operator overloading but it involves hitting the vtable. And hitting the vtable is completely unacceptable in performance-critical code.
- StefanKarpinski 12y ago
  I wrote this analysis [1] in the context of Julia vs. C++ about why I think that Go has not been successful as a C++ replacement. The primary issues are performance (the ability to trade off abstraction for performance, really), generics, and operator overloading. We did not intend for Julia to be a C++ replacement, but it turns out that it's quite a good one and a lot of adopters have come from C++ – I think that these features are why. [1] https://groups.google.com/forum/#!msg/julia-users/-SGWPUBJKqo/g1voeUDxCpgJ https://groups.google.com/forum/#!msg/julia-users/-SGWPUBJKq...
- giovannibajo1 12y ago
  Go is also easy to parse, AFAICT, both syntactically and semantically, and they ship a parser in the standard library. While absolutely not implying that it's a reasonable alternative, someone could try implementing infix operators as a syntactic layer on top of Go (kind of a preprocessor). It might work to fix the use case presented in the OP (math operators being far more readable in their infix form). Infix operators might just be implemented as a syntactic sugar layer after all, at least as a first draft; if you're able to parse a Go source file and its types in a way that when you see a sum expression, you already know whether both arguments implement a Numeric interface and/or Add method, you might be halfway through. To clarify: I love infix operators and I'd love if Go added them, and I consider the above just a hack.
- 12y ago
_ak 12y ago
Go wasn't designed to replace C++, Go was designed to replace C++ at Google. And it totally succeeded at that, given the list of critical infrastructure at Google where Go is used, and in some cases has replaced existing C++ implementations.
- DAddYE 12y ago
  Not sure if this was the same feel of Rob. > I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
  - _ak 12y ago
    Yes, but he was talking programmers out there, not Google. IIRC, in 2012, they were still _very_ reluctant to talk about any use of Go within Google, with vitess being the only exception.
dragonwriter 12y ago
> The thing is that GO was designed to replace c++ thing that absolutely failed. I don't think Go was designed as a general replacement for C++, I think it was designed as a replacement for C++ for the things that Python was almost better than C++ for, but not quite. EDIT: Though, OTOH, I do get the feeling that the people who designed Go largely are the type of people who feel that just-plain-C is a superior choice to C++ for most of the rest of the domain where C++ might be used, so they might view Go as a general replacement for C++, because they start with a smaller view of C++'s useful role than the market at large has.
moreentropy 12y ago
> So we have a python/ruby replacement with very old patterns (I think manual checking errors ie.). Before using Go, I have always programmed with "modern" languages that use exceptions for error handling. So the concept of only doing manual error handling was new to me, but after a few months of golang I love it now and exceptions in python started to really annoy me. In Go, I'm forced to do error handling right after every single call that will possibly return an error. While I thought that the resulting code looked ugly and repetitive, the result is a much more focused and intelligent error handling. If i wanted the same granularity and robustness of error handling in python, I'd have to put a catch all try..except block around every single call . Exceptions are a good time saver in stateless request based programs (like HTTP/web stuff) where it's sort of accetable if one request fails. I could just not care so much about detailed error handling, the worst that could happen is that i don't catch some error and the wsgi wrapper will catch it and return error 500 to the client. But building daemons in python is just plain painful. If I don't want my program to crash at some point I have to reckon that anything can raise an exception I didn't think of.

vfclists 12y ago

Try Nimrod. Or Julia. I haven't tried them yet, but it looks like their fun.

zoowar 12y ago
Julia is not fun. We expect it to be fun, like python, but it's not.
- herokusaki 12y ago
  Can you elaborate why?
  - xioxox 12y ago
    I was interested until I discovered Julia doesn't have a useful form of OOP inheritance. Ok, you don't always need it, but for some things it's indispensable (e.g. using widget/window systems).
    - one-more-minute 12y ago
      That's a bit like saying, for example, Python isn't interesting because it doesn't have monads (and they're essential for managing state, or whatever). Different languages have different ways of doing things, and lacking feature X isn't necessarily a deficiency. Julia generally favours composition over inheritance. You might be interested to look at GTK.jl, its widget/window system. https://github.com/JuliaLang/Gtk.jl https://github.com/JuliaLang/Gtk.jl
    - pjmlp 12y ago
      There are lots of ways of doing OOP, the Java/C# world isn't the only way,
- one-more-minute 12y ago
  That's not really a fair statement – plenty of people (me included) find Julia to be a lot of fun. I'd be interested to hear why you think that, though. If the OP is looking for a C++ alternative and knows Haskell, Rust is also an interesting alternative, although it's at a very early stage of development.

chimeracoder 12y ago

As someone who writes both Lisp and Go (and enjoys both), I find it odd that this article uses Lisp and Haskell as points of comparison. > programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups). In fact, this is almost an intentional "feature" of Go: http://aerokode.com/blog/go-is-boring http://aerokode.com/blog/go-is-boring > The idea is that there’s simply no way that any group of designers could imagine how people will want to use their language so making it easy to extend solves the problem wonderfully. On the other hand, there's no way of making a language so easily extensible while also maintaining relatively uniform idiomatic, design, and style conventions across a language community. Go very heavily favors the latter. > In Lisp, CLOS (Common Lisp Object System) was originally a library. It was a user defined abstraction that was so popular it was ported into the standard. CLOS is actually very similar in some ways to Go's structs. Both emphasize encapsulating data inside an "entity" (object/struct), and separating the notion of behavior from that entity. To quote one of the language authors from GopherCon[0]: "Interfaces separate data from behavior. Classes conflate them." Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness. It's a stronger assertion of the Pythonic motto, "There should be one, and preferably only one, obvious way to do it". [0] https://twitter.com/chimeracoder/status/459827405386162176 https://twitter.com/chimeracoder/status/459827405386162176

masklinn 12y ago
> CLOS is actually very similar in some ways to Go's structs. You've completely missed the article's point: users were able to create CLOS before it got integrated in the language.
- chimeracoder 12y ago
  Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and incorporating the results of that into Go. The fact that users are able to create core language features has its drawbacks when it comes to cohesion in the language community. Lisp itself is a perfect example of this - codebases are immensely fragmented in terms of which libraries they end up using (Quicklisp is, in part, an effort to solve this). Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness. Both are legitimate philosophies for different use cases, but that's why it's kind of silly (IMHO) to compare Go to Lisp - the goals are not only different, but diametrically opposed in most ways.

gdulli 12y ago

The agreeableness of Python is the reason I settled on it after experience with a bunch of other languages. I was starting to find software engineering to be a chore and was losing interest in it until I started using Python. No language is best at everything, and all the ways python isn't the best have been worked around without much bother. Go did not strike me as a language I would enjoy writing, despite the strengths it surely has in some areas. I would just be giving up other strengths I prioritize more highly.

camus2 12y ago
Frankly python is good enough for most things. It's not perfect but it's one of these languages you can really use for anything(like java). I'm not fan of the syntax though,I prefer ruby's(ruby is not for "everything" unfortunatly). I've seen insane stuff done in python (3d games,gui apps,complex network tools...) running quite well on my old mac. Go is relevant where you want pretty good performances and concurrency with low memory footprint(unlike java) ,without using C/C++ and threads. But it's clearly not for everything.

lmm 12y ago

Does anyone actually use CLOS? It's always held up as this great example of language extensibility, but my impression is that since it's not part of the core language Lisp folk tend to create their own abstractions instead.

piokuc 12y ago
Not sure what you mean by "not part of core language" - CLOS is part of ANSI Common Lisp standard.
- jimktrains2 12y ago
  It wasn't always that way. It use to be just a lib iirc.
  - piokuc 12y ago
    Well, CLOS became part of ANSI Common Lisp standard 24 years ago...
  - Jtsummers 12y ago
    Beat by a few minutes again, as piokuc says, it's in the standard. But even so, it may still be implemented as "just a library" in some CL implementations. That's the beauty of the language, it's so versatile you can extend it within itself, and it really feels like a language extension and not like you're accessing yet another API. If someone wanted a different object system, they could produce it within CL giving totally different OO semantics.

taylorlapeyre 12y ago

I just wanted to point out that the author of this article is a high school student. http://jozefg.bitbucket.org/about.html http://jozefg.bitbucket.org/about.html

tdees40 12y ago
Wow, "writing lots of compilers and type checkers" definitely wasn't on my radar screen when I was in high school.
- pjmlp 12y ago
  I did an informatics technical degree on high school back in the early 90's in Portugal. We had introduction to parsing and basic language processing.
- Jtsummers 12y ago
  Me neither, but a classmate was reading over/working through the dragon book our senior year of high school. There's a reason he went to CMU and I didn't. On the other hand, compilers (well, a less than formal version) was the third CS course topic at GT. Definitely approachable, with good faculty/staff, as an early topic of study.
- zura 12y ago
  I was reading Crenshaw's "Let's Build a Compiler" txt file. Good memories :)
camus2 12y ago
How does it make the OP less relevant? i know pretty smart programmers that are still in high school. And tt doesnt matter, the guy obviously knows Go.
- taylorlapeyre 12y ago
  My implication was that the article was very professional and I was quite impressed that it was written by somebody so young. I think that it makes it more relevant, not less.

pron 12y ago

It's ironic that the "better" the language (for some hazy definition of "better") the less actual work seems to get done with it. So Go can be pretty annoying at times, and so can Java (I've said before that I find the two almost identical, but that's beside the point now); and C is horrible and completely unsafe and downright dangerous. Yet more useful working code has probably been written in Java and C than all other languages combined since the invention of the computer, and more useful code has been written in, what, 5 years of Go(?) than in 20(?) years of Haskell. Here's the thing: I am willing to accept that Haskell is the best programming language ever created. People have been telling me this for over 15 years now. And yet it seems like the most complex code written in Haskell is the Haskell compiler itself (and maybe some tooling around it). If Haskell's clear advantages really make that much of a difference, maybe its (very vocal) supporters should start doing really impressive things with it rather than write compilers. I don't know, write a really safe operating system; a novel database; some crazy Watson-like machine; a never-failing hardware controller. Otherwise, all of this is just talk.

Dewie 12y ago
Maybe it turns out that the sociological side of programming trumps the technical side; that languages that forces or fosters a common vocabulary will always "win" over languages where you have so much power that you can easily diverge from the mainstream dialect, and there is not much culture of restraining this freedom. On the other hand, these dialects are embedded DSLs; specialized languages created and hosted by a base language. People seem to balk less at the idea of DSLs compared to the idea of powerful languages.
- astine 12y ago
  I think that part of the problem is that more 'powerful' languages often more concept heavy than more 'pragmatic' languages and that makes them harder to learn for a lot of programmers. Take Clojure for example. A lot of people including myself like this language a lot, but to be productive in it, you have to get used to the JVM, Lisp s-expressions, a heavily functional programming style with few side effects, a significant break from a normal approach to OOP, and Clojure's distinctive concurrency constructs which are more complex than Go's. It's not that any one of these things is hard, but you have to know all of them. Unless you have Lisp, or Haskell (or similar) experience, the only one you're likely to know is the JVM, and even then, maybe not. This isn't like C++ or Java which are huge languages with a lot to wrap your head around but at core simply reuse concepts that most programmers are familiar with, (OOP, basic types) It's the very things that make the language interesting to begin with that makes it trickier to pick up. Most of this holds for Haskell, Erlang, etc. Then again, real code is written in these languages, but they don't tend to dominate.

Kiro 12y ago

What is the definition of fun when it comes to a programming language?

DAddYE 12y ago
It's subjective, for me is DRY (don't repeat yourself) and achieve a "big" result with a small (but readable) effort.

tptacek 12y ago

If you're looking for a language that will enable "bottom-up development", where you gradually define, in Paul Graham On Lisp style, a language optimized for your problem domain, Golang is not the language for you. Similarly, if you're looking for a language that will read and write like a specification for your problem domain, so that writing your program has the side effect of doing half the work of proving your program correct, Golang is also not a good choice. What's worse, those two approaches to solving programming problems are compatible with each other. Lots of sharp programmers deeply appreciate both of them, and are used to languages that gracefully provide both of those facilities. If that describes you, Golang is a terrible choice; it will feel like writing 1990s Java (even though it really isn't). There are two kinds of programmers for whom Golang will really resonate: Python and Ruby developers who wish they could trade a bit of flexibility, ambiguousness, or dynamicism for better performance or safer code seem to like Golang a lot. Naive Golang code will outperform either Python or Ruby. Golang's approach to concurrency, while not revolutionary, is very well executed; Python and Ruby developers who want to write highly concurrent programs, particularly if they're used to the evented model, will find Golang not only faster but also probably easier to build programs in. Systems C programmers (not C++ programmers; if you're a C++ programmer in 2014, chances are you appreciate a lot of the knobs and dials Golang has deliberately jettisoned) might appreciate Golang for writing a lot like C, while providing 80% of the simplicity and flexibility value of Python. In particular, if you're the kind of programmer that starts projects in Python and then routinely "drops down" to C for the high-performance bits, Golang is kind of a dream. Golang's tooling is also optimized in such a way that C programmers will deeply appreciate it, without getting frustrated by the tools Golang misses that are common to other languages (particularly, REPLs). At the end of the day, Golang is overwhelmingly about pragmatism and refinement. If you're of the belief that programming is stuck in a rut of constructs from the 1980s and 1990s, and that what is needed is better languages that more carefully describe and address the problems of correct and expressive programming, Golang will drive you nuts. If you're the kind of person who sees programming languages as mere tools --- and I think that's a totally legitimate perspective, personally --- you might find Golang very pleasant to use. I don't know that Golang is a great language, but it is an extremely well-designed tool.

DAddYE 12y ago

sandGorgon 12y ago

>Ok, it’s only a few characters, big deal. Now what does this do? >b.Mul(b).Sub(big.NewInt(4).Mul(a).Mul(c)) >Or in Haskell >b * b - 4 * a * c umm.. correct me if I'm wrong, since I'm not well versed in either Haskell or Go, but doesnt the Golang version read better in terms of scoping. I mean just by reading the Go version, I know what it will evaluate to, but in the Haskell version I dont know the precedence order just by reading.

Dewie 12y ago
I'm pretty sure that the precedence is the same as in the usual convention of arithmetics. You can ask for it in GHCi (the REPL): > :i (-) > [...] infixl6 > :i ( * ) > [...] infixl7 So ( * ) has precedence over (-). The expression is then: (b * b) - (4 * a * c) Personally, I don't know if infix syntax is truly overall more readable than purely prefix/postfix syntax, or other such uniform representations. It might be for arithmetic, because it is so ingrained, but the precedence order was never hammered into me to such a degree that I learned it automatically by heart; I used to defensively make more parenthesise than I really needed to, just in case.
grayclhn 12y ago
I do, and I don't even know Haskell: (b * b) - (4 * a * c) edit: I don't know go, but I assume the go example is intentionally unreadable. But complaining about infix multiplication and subtraction is... curious.
- jerf 12y ago
  No, that's pretty much what the Go would look like, for any non-standard numeric type. (Though it does need to be a non-standard type, like a "bigint"... a merely type-wrapped standard type ("type Feet uint32") can still have arithmetic done to it.)In fact the default go fmt rules won't even let you put whitespace in there. However, my general call on that is that if you need your language to provide overloaded arithmetic operators, stick to languages that actually want to give that to you. It comes up a lot in language discussions because it's such an easy example to type out in a couple of lines, but in practice I don't think you see a lot of need for exotic int types being used pervasively throughout your code. Don't use Go for that. Don't use any language that doesn't do operator overloading. But this is far less a common use case than seems to be supposed... a variant of the "look under the streetlight" fallacy, I think. Go's really for heterogeneous concurrent business- or server-like programming. It isn't a language for mathematics, and the burst of libraries I've seen in the last couple of weeks that seem to be focused on that is bizarre to me. Go isn't good at that, isn't meant for that, and probably never will be. Go's nice for the very large niche that "business- and server-like programming" is but it's not so fantastically wonderful in every way that I'd want to work too hard to make it work in a niche it's not really suited for.

Donch 12y ago

The example could have been simplified: func abs(x Top) Top { switch v := x.(type) { case int32: if v < 0 { return -v } case int64: if v < 0 { return -v } case float32: if v < 0 { return -v } case float64: if v < 0 { return -v } } return v }

bunkat 12y ago
This code doesn't actually compile. You can't assign v to x.(type) like that.
- jerf 12y ago
  Are you sure? http://play.golang.org/p/dJC328-rh8 http://play.golang.org/p/dJC328-rh8 I did have to put "return x" as the last statement, though, not return v. And I'm not sure I'm happy about an "abs" that happily returns a string if fed a string, but, well, that's Go. Relevant bit of the spec: http://golang.org/ref/spec#Type_switches http://golang.org/ref/spec#Type_switches
  - Donch 12y ago
    It's horrible method with a horrible signature, that I didn't test :-) But the short variable declaration in the type switch does indeed save the casts the OP was complaining about. Even more correct and horrible: http://play.golang.org/p/ZMQKQhuUQT http://play.golang.org/p/ZMQKQhuUQT
  - bunkat 12y ago
    Yes, the return statement was what I was referring to. You can't use a type switch to do some sort of an implicit conversion that exists outside of the switch statement.
bsdetector 12y ago
This isn't simpler, it's smaller. In fact it's more complicated, since instead of 4 completely separate cases you have 4 half-cases and a default. For instance, pass a positive int16 and you get the right answer, but pass a negative int16 and you get a useable but wrong answer instead of nil from the original.

piokuc 12y ago

I think people gave Go a lot of credit just because it was designed at Google. People have high respect for Google engineers and so they assume what Googlers have designed must be flawless. So they take for granted ideas like lack of exceptions or lack of operators' overloading being a good thing, even though I'm quite sure they would be quick to criticize such BS if that was a feature in a language not coming from Google. But, in the long run, the language must defend itself on its own, without the authority of people/organization behind it.

bookwormAT 12y ago
I think people gave Go a lot of attention because it was designed by Rob Pike and Ken Thompson.
- piokuc 12y ago
  I have a feeling that the attention would be much more modest if they happened not to be on Google payroll when they designed the language. Anyway, whether it's because of Ken or Rob, or Google brand, it doesn't change the point I was trying to make.
rakoo 12y ago
I think people gave Go a lot of credit just because it gets a lot done, especially comparatively to the time taken to learn it, and the stuff you come up with can very well be used in production because you made it robust thanks to the excellent built-in testing and profiling tools. What's interesting with go is that if you can program, you already know it; all your time is spent building stuff, not learning the language. And when it comes to building stuff, Go is just straightforward.

ChuckMcM 12y ago

This is a great rant. Having recently done the 'golang' tutorial on the site a lot of it resonated with me. I have a slight advantage in that I worked at Google when Go came into existence and followed some of the debates about what problem it was trying to solve. The place it plugged in nicely was between the folks who wrote mostly python but wanted to go faster, and the folks who wrote C++. It was a niche that Java could not fill given its structure. In a weird way, it reminds me of BLISS[1]. BLISS had this relationship to assembler that "made it manageable" while keeping things fast. BLISS was replaced by C pretty much everywhere that C took hold (one theory is that BLISS is the 'B' programming language, Algol is the 'A' language, personally I think BCPL is a better owner the the 'B' moniker). The things that C has issues with, memory management, networking, and multi-threading, Go takes on front and center. It keeps around some of the expressiveness and type checking that makes compiling it half the battle toward correctness. Now that was kind of what the Java team was shooting for as well but with limited success. I feel like between Go and Java we've got some ideas of what the eventual successor language will look like. For me at least that is a step in the right direction. [1] http://en.wikipedia.org/wiki/BLISS http://en.wikipedia.org/wiki/BLISS

Jabbles 12y ago

As much as I want to emphasize that this is not the right way to think about programming in Go, I do want to point out that the example has a lot of extra code that isn't needed. Indeed, it's not really possible to have a bug of the kind the author wrote if written properly: http://play.golang.org/p/puZBEmOVaI http://play.golang.org/p/puZBEmOVaI

DocSavage 12y ago
The explicit type switch also lets you streamline handling of uint8, uint16, etc (just return value) and panic or error if given a type you don't expect. But I find it unfortunate that type switches must have single type cases. For example, it's too bad this doesn't work: http://play.golang.org/p/a4j1I6Oug- http://play.golang.org/p/a4j1I6Oug- The OP's complaint would be minor if the compiler would auto-unroll the multi-type case clause.
- deleted 12y ago
  [deleted]

personZ 12y ago

These sorts of posts are profoundly boring. I know people will up arrow it -- some sort of spiteful "Down with Go!" contrarian thing, when they aren't talking up rust -- but it isn't because the content is interesting or illuminating, but rather as some sort of activist thing. This particular piece (by a high school student, as an aside) starts off trying to create a surrogate for generics in Go. Don't. Here's the thing -- most of these posts are not about people making real code, but people making -toy- code. Where every function is all things to all people. The number of times I've needed a generic abs in my life -- zero. The number of times I've needed a double floating point abs in my life -- every single time. That's the thing about generics and real, actual world code: Your types are generally much less amorphous than you think. They really are. This illusion that everything needs to be everything just does not hold in the real world. But it is always the tiring example used against Go. Boring.

azth 12y ago
> The number of times I've needed a generic abs in my life -- zero. What about a generic max() or min() function?
- cgh 12y ago
  Or a generic list, vector, map...
  - personZ 12y ago
    Go's native synonyms of lists, vectors and maps are already "generic", so I'm not sure what your point is.
    - cgh 12y ago
      Except the containers aren't typed. They are essentially containers of void*. If you believe that to be "generic", then you don't understand the topic.
      - 12y ago

falconfunction 12y ago

I'm so glad Go can compile everything quickly, it's almost as fast as an incremental compiler from the 80s.

leccine 12y ago

It is so funny to see that somebody else got annoyed by Go the same way as I did. I could not get over the fact that I cant pass any type to a function other than interface{}. When you do that it just delays the problem and I have decided to not have a generic function but have multiple specific one. This violates the DRY principle but at least works. I am still looking for best practices with Go. I think the biggest advantage of that languages is the fact that Goole uses it in production and the libraries are well tested. The community is great too. Clojure has a way smaller community that limits the usage of that environment quite a bit. I agree with the author on Lisp is being more fun than Go, but that is a single dimension of the entire problem.

eridius 12y ago

> I wanted a fast, compiled replacement for stuff I write in C right now. But Go is not that language. You should look into Rust. It sounds like it might be more like what you're looking for.

djur 12y ago
Rust is great but it's still frontier territory right now. The documentation for the standard library is very sparse and stuff like HTTP is still in very early stages. I would only adopt it for production work if you're willing to be very actively involved in the nascent Rust community, follow the mailing lists, fix bugs yourself, etc. On the other hand, if that's the kind of thing that excites you, Rust is a really great option right now.

coldcode 12y ago

All languages suck, at some level. Whether this matters to you is a matter of need, willingness to compromise, and benefits to you, for some definition of you. This often leads to people writing their own language if they can which generally only pleases themselves.

jamra 12y ago

I have a problem with his extensibility critique. I don't agree that having generic types are good for the language. The problem in using polymorphism is that your users are going to abuse polymorphism. There will be class hierarchies that will confuse and abstract from the algorithm at hand. You will be mutating and mangling objects rather than dealing with the issues at hand. Reading a go source file is like following a for loop. It's quite technical. Reading a Java source file can be a case of trying to figure out the high level abstractions of the program.

twic 12y ago
The genericity that is being talked about here is parametric polymorphism, not subtype polymorphism. Parametric polymorphism doesn't lead to confusing class hierarchies. Parametric polymorphism doesn't involve inheritance, so it doesn't lead to any class hierarchies.

shurcooL 12y ago

Every design decision has trade offs. Since the author only covers the more obvious negative aspects of those 2 features, I'd like to cover the more subtle positives. > Extensibility One really great thing about that is how consistent it is. Every func in Go has a unique identifier: the package import path and the func name pair. This makes it possible to build tools like godoc.org and the `doc` command that let me look up the exact behavior of (unfamiliar) code. In this case, I can go to godoc.org/math/big#NewInt or type `doc big.NewInt` and see: // NewInt allocates and returns a new Int set to x. func NewInt(x int64) *Int In fact, it's so predictable that I don't have to think. As long as it's Go code, if I ever run into an unfamiliar func F of package P, I can always go to godoc.org/P#F or `doc P.F`. No searching, just an instant lookup. If I need to do 30 such lookups to solve a task, it makes a big difference. This applies to _all_ 3rd party Go packages. That is big. On the other hand, something like `x + y` is magic to me. I know that computers work with bytes at low level, and I want to be _able_ to understand what happens on that level. I understand and accept such magic for built in types. But I certainly wouldn't want to be reading a 3rd party Go library code that says `x + y` on its custom types. Where would I go to find out what that custom plus operator does? How does one make an unexported version of a plus operator? There'd be less consistency, more exceptions and rules, more variations in style and less tools that can be built to assist/answer questions about Go code. > The Type System I don't have time to cover this atm, but there are some advantages to the explicitness and verboseness of Go's approach. Can you think of any? I'm not suggesting it's the best it could ever be, just that there are both advantages and disadvantages that should be considered.

deleted 12y ago

[deleted]

danieldk 12y ago
So, how do you enumerate every type that exists or will exist in the future?

stcredzero 12y ago

A 16 year old kid decides that Go isn't suitable for writing an embodiment of Principia Mathematica. Surprise: Haskell is a better Haskell than Go. Go is a something like C, but with a few more features plus GC and come neat concurrency facilities. Why would anyone expect that to be anything like Haskell, or even to have a type system even approaching that kind of power?

ilaksh 12y ago

If you guys like Python and are having second thoughts about Go, take a look at Nimrod. Also, I personally look at Nimrod as a faster and slightly cleaner Python with a few extras, and I don't try to break the compiler using all of its cutting edge features. If you use it that way you will be happy.

deleted 12y ago

[deleted]

bfrog 12y ago

Go's strengths are tooling and libraries. Especially when you see the well written libraries all revolving around internet protocols, encodings, and content generation. It makes it extremely easy to write performant web sites and http API endpoints which many people do daily. All that said I hope Go adds D like compile time code generation and static typing or [D,Rust] gains better tooling and HTTP service oriented libraries and APIs that are as well written as the Go standard library packages are. Secondly I hope [D,Rust] sees how awesome having a common automatic format, build, and test tool is. In so few language is the testing package as simple as Go's. In so few languages is the build process as easy as Go's.

cryptos 12y ago

I've the same feelings about Go. After working several month on a side project with Go, I have given up, because I've felt not as productive as with Java (not to mention Scala). There are lots of annoying things: missing generics leading to a lot of uselesse code which could carry bugs. Without generics you can not create an Option datastructure, but have to return nil (the million dollar mistake of Hoare). Without generics you can not write concise object/functional code like someCollection.map(i -> i * i). Go has no good support for immutability. Mocking is awkward, because you have to code your mocks by hand. Unicode handling is a pain. That is why Go attracts mainly people from scripting languages (they get a bit more type safety and better performance) and C (they get a bit more type safety and less errors). Coming from other languages Go is not that attractive. I'm hoping for Rust to succeed.

rio4223 12y ago

Very well put. I tried Go now for a while and I was wondering why it doesn't appeal to me like for some of my friends. By reading through your response I found the reason for my gut feeling. I guess I belong into your first categorie ;).