20 ms·

Eight years of Go

• noncoml 9y ago
  Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2) and (3). Had just woken up. No idea what I was thinking.
  • deleted 9y ago
    [deleted]
  • nine_k 9y ago
    I wonder how the presence of ADTs and absence of generic functions would mesh together. With ADTs, using a sum type instead of the `result, err = func(...)`, would be an obvious thing to do. But the next thing you'd consider would be `bind` / `>>=`.
    • ori_b 9y ago
      I'm not sure why the next thing you'd consider is bind. It seems like plenty of languages with ADTs and generics still either don't have it available in their libraries, or use it extremely lightly, in spite of being able to implement it.
      • nine_k 9y ago
        I'm referring specifically to the error-handling situation. If you replace the two-value assignment with an `Either`, it feels very natural to also eschew the constant `if (err != nil) return err` lines, and adopt a continuation-passing style, the way you do with Futures in JavaScript. You could even consider some syntactic sugar around it, like the `?` operator of C# and Kotlin, or a full-on Haskell-like do-notation.
        • ori_b 9y ago
          Again, it doesn't seem like this is something that many communities do, in spite of having languages that support it. The '?' operators in the languages you cited, as far as I recall, are specific to null, and don't work on generic option types.
  • solox3 9y ago
    Novice here. Why is having no exceptions a good thing, in your opinion?
    • stcredzero 9y ago
      Exceptions are one of those things which are really nifty when programming in the small. However, they can create outsize problems when programming in the large.
    • nine_k 9y ago
      For exceptional, unforeseen situations you do have exceptions, aka "panic". For signaling error conditions that the caller has to expect and handle, you have the `result, err = func(...)` idiom, and a compiler that would warn you if you forget to use the value of `err`. If Rob Pike's opinion on this is not enough, here's Martin Fowler saying essentially the same thing: https://martinfowler.com/articles/replaceThrowWithNotification.html https://martinfowler.com/articles/replaceThrowWithNotificati... In general: http://wiki.c2.com/?DontUseExceptionsForFlowControl http://wiki.c2.com/?DontUseExceptionsForFlowControl
      • atmosx 9y ago
        I’ve read the first article. It was eye opening, cause I am writing a bot right now and using exceptions to control input flow. Made me think about my design. That said, it does not argue against exceptions. So, I am not sure what your argument is.
        • simon_o 9y ago
          Exceptions are bad outside the "your computer just started burning" cases, but Go has replaced them with something even worse, "multiple return values". So instead of some imagined return of "int or throw Exception" you now have "(int, error)", which basically means that the result of a function call can be any of these four options: - ( value, no error) - (no value, error) - ( value, error) - (no value, no error) And due to the lack of Generics you can't abstract over your error handling. And due to the lack of proper ADTs you can't even properly model "value OR error" manually.
  • tonyedgecombe 9y ago
    Lack of exceptions is the main reason I won't use it.
    • deleted 9y ago
      [deleted]
    • mohaine 9y ago
      I thought this as for a long time. Then I used go for awhile and I think I like the go way better. It solves the issues I had with execptionless languages without all the noise. With exceptions you most often just let them trickle up the call chain, which is the same thing you often do with err, just return it. And the returning the err works much better when doing async. Cross thread exceptions are a PITA and you are basically back to just returning an error obj.
      • dualogy 9y ago
        On the whole I agree that I prefer Go's explicit error returns over other languages implicit "alt-return paradigm" aka exceptions. But you're really well advised here to run a couple of linters occasionally that inform about ignored/unchecked/non-passed-on errors, it can happen all too easily while "rodeo-coding" prototypes/MVPs
      • tonyedgecombe 9y ago
        I thought this as for a long time. I have tried Go and worked with languages without exceptions in the past. The problem is the amount of error handling code I was writing time and time again. It might only be a case of returning an error but that is one more thing you need to think about instead of concentrating on the the domain. Error handling in threads is a pain either way.
    • golangnews 9y ago
      Lack of exceptions (in my code, but more importantly in library code) is one of the main reasons I use go.
  • sigzero 9y ago
    #5 is not a positive thing.
    • noncoml 9y ago
      Depends IMHO. I love exceptions in Python, find them a bit ugly in Java and hate them in Haskell.
  • oconnor663 9y ago
    What's the connection between `defer` and goroutines?
    • shurcooL 9y ago
      Not a strong connection, but both features are managed by the Go runtime.
    • camus2 9y ago
      None, the feature that completely depends on defer is recovering from panics. The order in which defer statements are executed is predictable, unlike goroutines.
    • noncoml 9y ago
      Yeah, none. I wrote this while still in bed. No idea what I was thinking at the time :D
  • wheaties 9y ago
    The best ecosystem out there? Since when? I'd say that Java and Python have huge, wonderful and full ecosystems. Golang doesn't even come close to that, yet. Furthermore, Golang doesn't even have a community standard (or several standards) dependency manager.
    • pmoriarty 9y ago
      Python's packaging is a nightmare of half-baked, incompatible approaches that puts the lie to the famous "Zen of Python" that "There should be one-- and preferably only one --obvious way to do it."
      • Groxx 9y ago
        Agreed on the packaging side, but the python community / existing libs (the entire rest of the ecosystem) is miles ahead of Go's at this point.
      • qaq 9y ago
        and yet Pipenv is miles ahead of what Go has to offer.
      • deleted 9y ago
        [deleted]
      • freyir 9y ago
        Bold choice.
      • Karupan 9y ago
        And yet pip has just worked for me. Can’t say the same about any of the go dep tools.
        • pmoriarty 9y ago
          Try using pip to install multiple versions of the same library at the same time, or the same library running under different versions of Python.
    • 9y ago
  • dualogy 9y ago
    > If Go had ADTs In the process of hacking on my PureScript2Golang "transcompiler", I've realized that under the hood ADTs, also known as "tagged unions", will likely more often than not be represented exactly as just that: a "tag flag" and a data pointer. (Of course if all of an ADT's ctors are nullary, an enumish int will do the trick just as well --- I doubt this gains anything over interface{}-boxed 0-size struct type-defs though in reality.) Now the natural "box"/container for this tag+content pattern in Go is the `interface{}` that can hold as 'content' any of your "constructors" (whether it be a struct or type-alias or prim type), plus your 'tag' pattern-matchings translate to Go's type-assertions. You see this also whenever ADTs are translated to JS or OOP languages, in some manner the "type" tag is carried along to be able to switch-case on. Anyway, you can do poor-man's ADTs as per above today. The catch is that you get fewer compile-time checks (won't check for pattern exhaustiveness in your switch-cases, or illegal/impossible/invalid (as per your custom "dumb" ADT layouts) type assertions). But anyone who's done some linked lists or devised parser ASTs in Go has written "ADTs" in this manner --- whether by intention or inadvertently =) Personally, I don't care about Generics now that I'm aiming to generate low-level Go code for PureScript's parametric polymorphism and higher-kinded types system.. --- expressive beyond the old-school oop/imperative "generics" band-aid ;) > That I can add interfaces implementations to structs I don’t own Wait, did I miss out on some new feature only recently introduced? The way I parse your above statement, it sounds like you could define methods for receiver types imported from other packages, is that what you meant? Or did you simply have classical workarounds in mind, such as type-aliasing or set-the-"method"-as-a-struct's-func-typed-field?
    • codygman 9y ago
      Can you link to your project?
      • dualogy 9y ago
        Current approach: http://github.com/metaleap/gonad-corefn http://github.com/metaleap/gonad-corefn (to be renamed later) --- heavily in-flux, even more slow-going pretty-soon-now (long-term freelance gig coming up), but I'm committed to keep committing =) --- won't be polished in terms of docs/tests/better-commit-msgs etc until reaching a certain stage of completeness. Also about 1/3rd of the code can be ditched at some point, coming from earlier stages --- only will become fully apparent which 1/3 at a later stage of maturity as well though. Earlier first approach, won't currently compile due to deps: http://github.com/metaleap/gonad-coreimp http://github.com/metaleap/gonad-coreimp Auxiliary stuff currently dumped in: http://github.com/golamb http://github.com/golamb For a fun ps2go comparison, side-by-side: https://github.com/golamb/test-pscorefn-src/tree/master/src/Mini https://github.com/golamb/test-pscorefn-src/tree/master/src/... <-> https://github.com/golamb/test-pscorefn2go/tree/master/Mini https://github.com/golamb/test-pscorefn2go/tree/master/Mini --- lots to-do still =)
  • camus2 9y ago
    Go has (inferior) exceptions, they are called panics. error as value is not a feature of the language, it's a convention. > 1. Probably the best ecosystem out there. it will when it gets an acceptable PDF library, better enterprise integration (SOAP and co) and an actual debugger (and no Delve isn't good enough given how it often fails at basic debugging).
  • majewsky 9y ago
    Defer is not enabled by goroutines. C++ has `defer` as well, although it's called "destructors" there.
  • valarauca1 9y ago
    >Actually (5) is one of the few things I don’t like about Haskell. Haskell has exceptions FYI https://wiki.haskell.org/Exception https://wiki.haskell.org/Exception
    • noncoml 9y ago
      Yes, that's what I say I don't like. Sorry for not making myself clear.
  • zkomp 9y ago
    Heh, that is fun: the thing I hate about go is immature very varied stdlib quality, leading to even more varied ecosystem. Rust seems on the right path, go ... well do you even have package management after 8 years? No.. What other systems do you compare it with? Its not the best I guarantee it...
• stablemap 9y ago
  A post earlier this year by Rob Pike, celebrating ten years of Go: https://commandcenter.blogspot.com/2017/09/go-ten-years-and-climbing.html https://commandcenter.blogspot.com/2017/09/go-ten-years-and-...
  • weberc2 9y ago
    This blog post is 8 years since Go was an open source project. Rob's post was probably something like "10 years since we began work on Go".
    • stablemap 9y ago
      Yes, I didn’t mean to imply a contradiction. Just two articles that go well together.
• davidkuhta 9y ago
  way to go, Go! Just to accentuate some of the neat things you can do with Go, watch: 'Can you write an OS Kernel in Go?' from the Golang UK Conf. https://www.youtube.com/watch?v=8T3VxGrrJwc https://www.youtube.com/watch?v=8T3VxGrrJwc
  • bitmapbrother 9y ago
    That was seriously impressive.
• nine_k 9y ago
  Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).
  • pera 9y ago
    Maybe, but even then at the end they decided to pay attention to this "vocal minority" and add go dep.
  • hood_syntax 9y ago
    Are the complaints about lack of generics really a minority thing? Writing separate functions to sort different types just strikes me as ridiculous. EDIT: My original tone was a bit nasty in retrospect. Did a little research and while I still am on the generics side, the current situation seems at least workable for a good number of use cases.
    • ori_b 9y ago
      But you don't need to do that. It's a bit clunkier than generics, but it's usable: https://golang.org/pkg/sort/ https://golang.org/pkg/sort/
      • hood_syntax 9y ago
        I did a little research after I posted my original comment and came across that. It does seem usable even if it's not what I'd prefer
      • pcwalton 9y ago
        You're still writing separate functions (implementations of sort.Interface) to sort different types.
        • dualogy 9y ago
          A little boilerplate hasn't killed anyone. If you're talking about "100s of different Enterprise Business Objects (TM) structs", something is probably off in the overall program design and/or code-gen should probably be introduced regardless of the 'sort' (and related typically-generics use-cases) question, as that sounds like something to be largely derived from pre-existing schemas of some sort..
• hellofunk 9y ago
  I find myself wondering how important the "fun facts" are in this fascinating thread about Go: https://twitter.com/pasiphae_goals/status/923820615022399488 https://twitter.com/pasiphae_goals/status/923820615022399488
  • spraak 9y ago
    Some of those things are true and annoying, while others are exaggerations, and the rest are just wrong. That thread is poor taste.
    • vvanders 9y ago
      Yeah, they are (and the author admits as much) but I found > Fact #38: go is supposedly a garbage collected language, but it has not once deleted itself nor any of my code. pretty hilarious.
      • spraak 9y ago
        Yeah actually that's really funny.
  • weberc2 9y ago
    They're not important. The author admitted she was just shitposting. It was an amusing thread, but rife with misinformation. If someone wanted valid criticisms of Go, I would not send them there.
• mtgx 9y ago
  Can you do something about Golang's performance on Arm servers? It seems to be terrible compared to x86 performance: https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/ This would have a positive impact on Google, too, as the more server chip competition there is, the cheaper it will be for Google to buy those chips for its cloud services.
• kown223 9y ago
  For me Go is amazing, is my first language where I don't need a virtual machine or interpreter to compile to machine code, C++ is OK but not for day to day web. Changing something then having to wait 40 seconds for java to recompile drive me crazy, also same for tests. Yes would love to have a package system, but is coming.
  • MrBuddyCasino 9y ago
    Java has some flaws, but slow compilation is not one of them. Incremental compilers are available and pretty much eliminate pauses.
    • kown223 9y ago
      I did worked with spring boot and intelijava, and I timed for a decent size project it was over 40 seconds, but I believe a lot of it was Intelijava compiling, anyway, in go is instant.
      • pjmlp 9y ago
        InteliJ doesn't have a built-in incremental compiler like Eclipse does.
    • dilap 9y ago
      Really? I've recently been recruited to pitch in on a Java project, they're using maven, and the compiles sure aren't incremental. What should we be using instead?
      • therealdrag0 9y ago
        Eclipse or IntelliJ IDEs will compile while you code (like C#). Depends on the project setup and dependencies. But I've found that this works for most development until I need to produce an artifact. Then I run maven which does a lot more than just compile code and usually is longer than 40s.
• indescions_2017 9y ago
  > every single cloud company has critical components of their cloud infrastructure implemented in Go And this is how the "network effect" propagates. As the customers of cloud services also begin to experiment in Golang. And discover the holistic ecosystem of distributed systems packages. Even Blizzard with its massive C++ codebase is gaining converts https://youtu.be/Az5F4lwSljI?t=23m50s https://youtu.be/Az5F4lwSljI?t=23m50s
  • mrep 9y ago
    That source just mentioned a few popular open source projects and provided no sources citing actual cloud providers using it in their backend infrastructure.
• shkkmo 9y ago
  Go's biggest issues still seems to be the lack of a standard mature dependency management system.
  • tetraodonpuffer 9y ago
    this is being addressed in dep, it's obviously not fully ready yet but works pretty well in my experience https://github.com/golang/dep https://github.com/golang/dep
    • shkkmo 9y ago
      Which is why I added the 'mature' qualifier.
  • majewsky 9y ago
    I don't know why people are so upset about this. Go standardizes enough things about imports and package structure that you can completely solve dependency management in literally a shell script: https://github.com/holocm/golangvend https://github.com/holocm/golangvend (I'm using this productively for the Go apps that I develop at work).
    • _seemethere 9y ago
      the issue becomes that there are so many solutions out there that going from project to project becomes a pain. Large projects use a litany of different tools like glide, dep, godeps, vndr, govendor, etc. that managing all of them is a pain. What makes it worse is that Golang's official solution seems half-baked when compared with other solutions out there.
  • bpicolo 9y ago
    Glide is great - it supported the most important feature I cared about, which was aliasing for forks where I had to fix bugs. "Standard" matters less because there's also no centrally-controlled repository of packages, unlike npm/maven/pip
  • cturner 9y ago
• mfrw 9y ago
  Simplicity is the Ultimate form of sophistication -- Leonardo da Vinci The quote fits perfectly for the design of go.
  • mfrw 9y ago
    I agree with all of you, but when I compare go with C++/Java, go turns out to be very simple.
  • simon_o 9y ago
    Like nil interfaces not being nil. Or using characters from the Canadian Aboriginal Syllabics unicode block to emulate generics.
  • nv-vn 9y ago
    I think it fits better for Scheme or Forth. I would not describe Go as simple at all relative to those languages.
• brian-armstrong 9y ago
  Go is woefully missing some really key features, which you encounter when tuning it for high performance. My list of grievances: - Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works. - Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered. - No easy way to construct arenas/pools. Once you go down this route you have a great headache of releasing in the right places. The GC doesn't cut it, you need pools sometimes - Debugging basically doesn't work on some OSes. No easy way to attach gdb and see what's happening. Doubly so if you use Cgo - Similarly, Go doesnt bother to hide the differences of different OSes. Up to you as the programmer. Again not surprising for Google's all Linux world. If everything is Linux then OS difference doesnt matter. But even Python does a better job here. - Logging is poorly thought out as evidenced by multitude of third-party log packages. Anemic compiler means you can't get verbose logging without paying a performance penalty. - No RAII. Defers are a lazy attempt at this, but they're not even close to being as good as RAII. This is probably the biggest point where you realize Go can't dethrone C++ - Tricky Close() semantics force you to architect entire program around who will close() things at end of their lifetime. Lots of terrible hacks ensue when people build something that works but realize close ownership is ambiguous and rightfully don't want to rebuild it all - Channels don't have a good way to deal with errors. You're forced to come up with an ad hoc solution to deal with your graph of goroutines/channels when one node errors - No supervision tree. Erlang existed far before Go but they didn't learn from this key feature. But it would greatly enhance Go to have it - Hacky reflection semantics that cause subtle runtime bugs when a JSON struct field's name starts with a lowercase letter. And of course, there are no generics, the larger issue here. I was hopeful that Go would fix some of these things before it went 1.0 and locked in its syntax. Sadly that didn't happen as it was likely already locked in at Google. Go is ultimately kind of brain dead, useful for some very particular features but not so compelling that it can replace any other language.
  • Karrot_Kream 9y ago
    I'm not disagreeing with you (I've previously criticized Go here) but I think it's helpful to think of Go as a more "modern" C. A lot of the warts you see here (Cludgey POSIX interfaces, no smart scheduling around channel error handling, bad reflection semantics, etc.) are the same as you'd find in C.
• dogruck 9y ago
  In honor of the exponential, I wish the conclusion was “Thank you, and here’s to sixteen more years!” :-)
• fartfactory 9y ago
  Shame the language looks like c after 8 years of Heroin usage
• fithisux 9y ago
  I use golang since 2010. My only complaint is that they dropped gxui. So I use golang mainly for cli utilities. The other options (I do not like javascript) are ill-maintained. For me it is more important than generics.
• KarlAuer 9y ago
  eight years a-go? :)