20 ms·

Fourteen Years of Go

• _8j50 3y ago
  I hereby predict the creation of " go script". Or gscript. Scripts that JIT compile and can use native golang libraries.
  • cookiengineer 3y ago
    Already somewhat existing with yaegi [1] [1] https://github.com/traefik/yaegi https://github.com/traefik/yaegi
    • _8j50 3y ago
      TIL! Thanks.
• kunley 3y ago
  Someone could also write a much more bitter article "N Years of Go Hate", as Go bashing became a very popular trend, also unfortunately here. In my estimates N = 6, more less
  • eloisant 3y ago
    Language bashing is a sign that this language is popular. People don't bash languages they don't care about, only languages they have to work with when they would have picked a different one if they made the call.
    • Yasuraka 3y ago
      I took every opportunitiy to hate on Java before I even had to work with it. I then had to do CI/CD and release management with all the bells and whistles for a lot of Java projects. Now I also actively hate on its ecosystem.
      • demi56 3y ago
        Basically proves his point, I hate JavaScript but am pretty sure my children is gonna write some code in JavaScript
    • kunley 3y ago
      Naah, in my observation it is kind of bashing which is almost always around the fact that Go is not Rust, which amazes me each time why certain individuals do that instead of simply coding in Rust or writing more about Rust. (Funny that it applies almost exclusively to Rust folks; I never saw any negativity towards Go from Zig folks, for example). These individuals will of course downvote this comment as well as my previous comment, because they are so deeply emotionally tied to their choice of language that they hate even mentioning the mechanism; but I don't care about my points here, instead I care much more about the truth and honesty
      • rami3l 3y ago
        Rust dev here. I really love the fact that most of the time people from the Golang community would like to say "look what I've made with Golang!" That's the sign of success: the users (here I mean general devs) should not care too much about the language per se, they still have applications to ship! Rustaceans tend to talk more about cool new language features. They are critical to what Rust does, but maybe they have also got too much attention.
      • eloisant 3y ago
        > Go is not Rust, which amazes me each time why certain individuals do that instead of simply coding in Rust or writing more about Rust. As I said: typically those devs want to use Rust but their team or employer decided to go with Go instead. So they keep writing Go wishing they were writing Rust instead (and maybe secretly hoping to convince their colleagues and bosses to switch to Rust). So it happens precisely because Go is popular and get selected for those projects.
        • erik_seaberg 3y ago
          This. I’m interested in Rust for safety, but I really just want to be allowed to use a language aimed at empowering experts rather than novices.
  • usrbinbash 3y ago
    "There are only two kinds of languages: the ones people complain about and the ones nobody uses." ― Bjarne Stroustrup, The C++ Programming Language
• stabbles 3y ago
  It's funny how languages like Go and Julia are typically still seen as "new", even though they are more than a decade old. It's similar to "modern C++" referring to C++11 and above. Sometimes you even read about "modern languages like python" which is more than three decades old.
  • viraptor 3y ago
    Depends on what people mean by modern. Modern doesn't have to mean recent. Python for all its problems is keeping up to date with lots of modern ideas: optional typing, decent packages ecosystem, async support, refreshed format strings, etc. It's a different kind of modern than C++11 aka "default compilers in LTS releases finally support it, so we can set it as the used standard" kind of modern.
  • eloisant 3y ago
    If you look at the most popular langages, Go is still one of the most recent. Java, Python, C#, Javascript, PHP, C, C++, Ruby, are all from the previous century. There is Swift that is roughly as old as Go and Rust that is more recent, but they're not nearly as popular as Go.
  • moelf 3y ago
    Go hit 1.0 in 2012, Julia hit 1.0 in 2018
    • zozbot234 3y ago
      Rust hit 1.0 in 2015, but everyone knows that the real stably usable release was in late 2018.
  • ivars 3y ago
    And OpenGL 3.3 is still called "modern"
• trustingtrust 3y ago
  I have always felt there has been a learning curve for Go and Rust when it comes to syntax for me. I have used C C++ Java and Python and PHP for a long time but whenever I start Go or Rust, over time I lose interest thinking this is too complicated and difficult for me (no idea why). Is there anyone in the same boat and are there ideas how I can make myself get good with at least one of these trending languages ?
  • mplewis 3y ago
    Good news! If you’re familiar with Python, Go is at its heart not that different. It has fewer features and the syntax is similar, which makes it easy to learn. Try the interactive Go Tour, and review the Learn X in Y Minutes page for Go to get familiar with the new features. Then try building a fun toy project in it. Go makes it easy to build web servers, so maybe a REST service is a place you could start.
  • denysvitali 3y ago
    Go and Rust have certainly a different learning curve. Go is supposed to be incredibly easy. Rust's learning curve is waaay steeper than that
  • mft_ 3y ago
    Hah, you’re describing almost exactly my feelings the few times I’ve tried to learn Swift…
  • dewey 3y ago
    For me Go is one of the easiest languages to learn (even if there are some low level bits like closing bodies etc.) just because you always know what goes in and comes out of a function. When doing Ruby after only using Go for years it was (and still is) very tricky for me to deal with error handling and figuring out what kind of object I'm dealing with.
  • SkiFire13 3y ago
    > when it comes to syntax for me If your issue is that the syntax is too complex then you've got a problem since semantics are usually way more complex to grasp than syntax.
• mplewis 3y ago
  I love how this language gets so much faster every year. Here’s to fourteen more, Go!
• preommr 3y ago
  I've come to accept that Golang, as bad as it is, is probably the best that we're going to get in the near future. It takes so long for a language to rise to prominence that newer languages like nim or zig are probably a decade away from even gaining a threshold. I really wish there was a better alternative to golang because it comes so close to greatness: fast compile times, small binaries, GC, great concurrency ergnomics, great for networking (My God! you can just use net/http for so much - it's insane), an attempt at simple code (yea checking err is boilerplate, but it makes error handling clear), a community focused on having few dependencies where it's possible to build something and have it work for years. But then there's complete bullshit like the nil handling, a lot of the interface design, the horrible enum equivalent, using casing to indicate accessibility, how tacked on generics are, how long it took to get decent package management when there was so much existing knowledge to learn from, etc. There's also some features like sum types that would be really nice to have.
  • troupo 3y ago
    > great concurrency ergnomics Erlang/Elixir would like to have a word ;)
    • zapnuk 3y ago
      ...to congratulate Go as another language where concurrency ergonomics is baked into the language. While Go has another philosophy in mind, it works for many people. Together they opened the door to make concurrency a more important language feature and undoubtedly influenced other popular languages like java.
      • zozbot234 3y ago
        I wouldn't describe Golang as "concurrency ergonomics" You can inadvertently share mutable data across Goroutines (Golang's term for userspace threads or fibers) in a memory unsafe way.
      • SEMW 3y ago
        I'm a reasonably new go programmer, I've only been doing it full-time for a few months. But "great concurrency ergonomics" has.. not been my experience. What I've been finding is that primitives it gives you are easy to use, but extremely hard to use _correctly_. My first major PR in go had a week of back and forths as more experienced go programmers on my team pointed out the many, many places where my concurrent code was buggy -- places where I was receiving without selecting over the context being cancelled or some close-channel, places where I was sending from a goroutine that had to have a nonblocking basic loop without guarding with a default clause, places where I was using an unbuffered channel where pathological goroutine scheduling could result in a deadlock, places where I was using non-thread-safe data structures in places that could theoretically be mutated by multiple goroutines and without spamming mutexes everywhere, etc. etc. And sure, I'm relatively new to go. I'll learn these things and get better. But the contrast to some previous work I'd done in Elixir was striking. In Erlang/elixir, _the obvious first thing you try is generally actually correct_. And it gives you standard ways of working built on top of the primitives (genserver calls etc.), so you don't have to buggily reinvent the wheel every time you want to send a message from one goroutine to another with a reply, or need to tear down a bunch of goroutines simultaneously. I have a highly-concurrent elixir service I wrote several years ago, by myself (early stage company, no code review), still in production. It pretty much never has problems and basically just worked from the start. If I'd tried that with go, without a bunch of experienced go programmers to point out all the subtle race conditions, I'd probably still be dealing with a long tail of data races and deadlocks years later.
• rollulus 3y ago
  Got into Go more than a decade ago, because it was HN’s darling back then. It has become out of fashion now here, replaced with that other great statically typed performant language (don’t want to start a flame war). Which on its turn will be out of fashion a decade from now, because we love new things. And I love Go. It’s not perfect at all. But I get things done with it, there are tons of high quality modules to depend on, the tooling is great, concurrency / async programming is a breeze. Thanks, authors and community.
  • leosanchez 3y ago
    > It has become out of fashion now here Are you sure ? I don't get that feeling from HN at all.
    • citrin_ru 3y ago
      My impression that Rust nowadays gets more attention/upvotes than Go. But Go is still very fashionable compare to C/C++/Perl/PHP.
      • zozbot234 3y ago
        It's also very fashionable compared to other garbage-collected languages, which is arguably a more sensible comparison. Though one could argue that ReasonML (an Ocaml frontend with vaguely Go-ish syntax) has the better overall design.
        • scns 3y ago
          > ReasonML (an Ocaml frontend with vaguely Go-ish syntax) Sorry to be a pedant, but ReasonML was developed to make OCaml accessible to developers with JavaScript experience.
    • iLoveOncall 3y ago
      I think it has become out of fashion everywhere to be fair. Not in the sense that it's a bad language, but just that it's not used much anymore. https://trends.google.com/trends/explore?date=all&q=%2Fm%2F09gbxjr&hl=en https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0... (Funnily enough, it still absolutely dwarfs Rust in Google Trends, which highlights how much HN, Reddit and such are echo-chambers)
• beltsazar 3y ago
  There are a few surprises of Go, but one thing that surprised me the most is the fact that an unrecovered panic in any goroutine will crash the whole program. To make things worse, you can only recover a panic in a goroutine that you spawn. So, you can't do anything to prevent a panic in a goroutine spawned by a third-party library crashing your whole program. The best you can do is to set up a supervisor to restart your program after crash.
  • galangalalgol 3y ago
    Rust made the same call. Panic isn't supposed to be "I'm not sure what to do now, maybe my caller will know?". That is an error not a panic amd you return it. A panic is for "I just realized I or someone else did something really bad and the invariants of everything are now in question, hit the breakers, lets try this again". If your dependency library, like so many, panicked rather than take the time and effort to check the conditions that would cause an out of bounds access, then they are bad and they should feel bad, fork and merge the fix and don't say anything, they will feel the shame.
    • quickthrower2 3y ago
      Running off forks is no fun though.
      • hackerbrother 3y ago
        So the question is: should there exist a method that means “bring down the whole ship”. (Or, should that method be something more severe than “panic”, and panic should be redefined with a more limited scope.)
        • quickthrower2 3y ago
          I agree. I like C# where you can expect libraries to play nice. In theory it is possible for C# library to crash your app but it is definitely not on the trodden path. But I do prefer return values over exceptions! I have not used Go and I think the err != nil boilerplate might drive me a little insane, but Haskells option types seem a nice fit.
• leosanchez 3y ago
  While I don't particularly like Golang. I definitely see why people like it. I use many tools that are written in Golang, and I am very grateful for it. docker, duf, chezmoi, fzf, croc are few tools I use that are written in Golang.
  • medv 3y ago
    fx, walk
  • leosanchez 3y ago
    Forgot lazygit :)
• evmar 3y ago
  As a person who was initially disappointed by Go and who has come to love it, one of the biggest things I learned from watching it grow was the following: As far as languages go, Go is relatively well-funded. You can of course imagine hypotheticals where there was more money behind it, but on the spectrum of PLs it's got more support than most. And further, I think the core developers who work on it like rsc and bradfitz are objectively great implementers. Despite that, the majority of complaints about Go are a lack of language features; you even see some in this thread. In other words, a language with an above-average amount of effort and ability and 14 years behind it is still perceived as feature poor. But imagine how much more time it would have taken if they had taken on a larger scope, like if they had gone through all the complex design process for generics up front. For me it is a great lesson on how important reducing scope is for shipping, and also how a reduced scope enables you to more judiciously choose what is important. If they had decided that features X, Y, Z were table stakes for their launch they would never have had the time to do the other things that I think have made Go great.
  • tejinderss 3y ago
    How does it compare to rust in your experience?
  • VBprogrammer 3y ago
    I only have a small amount of Go experience but in my humble opinion I don't think the lack of features is due to lack of time or funding. In fact it would have probably been much easier to say yes to a bunch of features than to continually deflect and reject the demand for those. I'm sure anyone working with different stakeholders recognises this effect. They have very deliberately tried to minimise the feature set in order to keep the language easy to learn. C++ is probably the canonical example of a language which hasn't kept the feature set tractable but I'd even argue that Python may have fallen into this trap in recent history.
    • asah 3y ago
      Given AI assisted programming, I'm not sure how much any of this matters...
• hamdouni 3y ago
  Getting things done with Go, effectively since then. That does not mean you can't do it with other languages, just that it works well for my business.
  • karolist 3y ago
    What's your business and stack?
    • hamdouni 3y ago
      Custom apps for small business. Svelte + Go.
• gren236 3y ago
  Golang's team approach of being "boring" sometimes tricks people into thinking that nothing happens with the language. Good article to show exactly how much work is done.
• jug 3y ago
  I'm stunned it has been this long. Wow. I'm growing old for real.
  • criddell 3y ago
    There are probably a few readers here younger than Go.
• spicyusername 3y ago
  Go is a great language. The Python of typed languages, if you will. Is it perfect? There's no such thing. But it's very easy to get to work and start solving problems with no headache, which is probably why so many very popular tools are written in it these days.
  • tgv 3y ago
    Not untrue, but fortunately, Go doesn't allow all the "oh so clever" stuff you can do in Python. Or in C#, to mention another one. And it performs very well, certainly in comparison with Python.
    • usrbinbash 3y ago
      > all the "oh so clever" stuff you can do in Python. Oh come on, who doesn't love to see something like this? [print("fizzbuzz" if not x % 15 else "buzz" if not x % 5 else "fizz" if not x % 3 else x) for x in range(1, 101)]
      • tgv 3y ago
        That's readable, in contrast to class magic.
  • wg0 3y ago
    Python of typed languages. I'm going to quote this often I guess.
  • the_gipsy 3y ago
    Typed, but zero-values makes it very weak. The Python of typed languages, if you will.
  • impulser_ 3y ago
    I don't understand why people compare it too Python. They are so far from eachother. Python has horrible builtin tooling and Go has great builtin tooling. Go is very restrictive language, while Python is not. Go has horrible FFI support, while Python has some of the best FFI support. I think the only thing that is similar between them is both of them are easy to understand compared to most languages. I mean you don't see people building AI/ML, Data Science lib raries in Go for a reason.
• qaq 3y ago
  Good tooling out of the box. Very predictable dev. trajectory. Became my go to language for most personal projects. My only remaining ask would be sum types. The stack I settled on: Postgres + sqlc templ (kindah jsx for go) + htmx Barely have to write any js/ts now
  • BD103 3y ago
    Sum types are amazing! Once I got introduced to them in Rust, it was hard to go back to languages like Java where the enum type is pitiful in comparison.
    • kaba0 3y ago
      Java literally has algebraic data types, see sealed classes/interfaces and records.
      • diarrhea 3y ago
        Not familiar with Java, but C# has sealed classes as well. They are not the real deal. You can fake your way around to achieve something resembling sum types, but the deep language integration like in Rust is simply unattainable. For example, ADT and pattern matching go hand in hand, so you want syntax-level, first class and powerful support for structural pattern matching as well. Not sure about Java, but last I used it C# had only relatively basic support.
        • kaashif 3y ago
          Java actually does have pattern matching like this: int eval(Expr e) { return switch (e) { case ConstantExpr(var i) -> i; case PlusExpr(var a, var b) -> eval(a) + eval(b); case TimesExpr(var a, var b) -> eval(a) \* eval(b); case NegExpr(var e) -> -eval(e); // no default needed, Expr is sealed } } But it only got that recently.
          • kaba0 3y ago
• tragomaskhalos 3y ago
  It's worth reiterating that Go was created by Google to solve Google's problems. If it also solves your problems, or a worthwhile subset thereof, then that is a happy serendipity, but it's not a design goal.
  • usrbinbash 3y ago
    Go was created to solve the problem of how to write real world code solving practical problems in the space of backends, systems (not system) programming and microservices, where performance matters, with a language that is easy to learn, the code of which is easy to read and maintain, which is easy to understand for tooling, and which lends itself naturally to projects where many coders of different skill levels and personal preference work on the same thing. I believe that it is very much a problem many entities that aren't Google like to have a good solution for.
    • zozbot234 3y ago
      > easy to learn, ... easy to read and maintain, These things are quite subjective. In practice though, Go lacks the kinds of features that would make very large scale codebases (the sorts of codebases where "many coders ... work on the same thing") truly surveyable, understandable and easily maintained. I mean, it's not a complete disaster like Python or JavaScript. It has some features to support modularity and programming "in the large". But other modern languages like Rust or even Swift are quite a bit better on that side of things, and it shows.
      • ramses0 3y ago
        There's an aside to that: Supposedly within google itself, they have super-magical tooling (ie: rename `dev.foo.bar(abc)` to `abc.dev.v2.foo(bar)`), so it's less important to have those "in the language", when "they" can just refactor "everything". Us mere mortals are trying to pick up Thor's hammer at the end of the day.
      • usrbinbash 3y ago
        > In practice though In practice though, there is a reason why Go is seeing continuous growth in usage, so I kinda doubt that these features of Go are subjective. > But other modern languages like Rust or even Swift are quite a bit better on that side of things, and it shows. In what metrics does that "show" if I may ask? Because it isn't showing in usage numbers across projects.
• wg0 3y ago
  Minimalist would love go. It is hard to over engineer when there's no inheritance, no meta classes, no properties, iterators, decorators and such. I've seen pretty convoluted code bases otherwise that showcase the engineering muscle of the individual and how they can employ almost every single language feature even to a very narrow business domain.
  • masklinn 3y ago
    > Minimalist would love go. That is an assertion which makes no sense to me. Go is not a minimalist language, it's a restrictive one. Although it made different choices, it's in the same vein as Java, and certainly no Forth, or Smalltalk. > It is hard to over engineer when there's no inheritance, no meta classes, no properties, iterators, decorators and such. None of that has anything to do with over engineering?
    • logicchains 3y ago
      >None of that has anything to do with over engineering? Most over-engineering in the wild overuses inheritance. That's why we see more monstrous "enterprise" code in Java and C# than languages like Go and Rust that lack inheritance.
      • kaba0 3y ago
        > That's why we see more monstrous "enterprise" code in Java and C# than languages like Go and Rust that lack inheritance. Rust has a completely different niche, and maybe wait a bit before claiming anything like that about Go - it is not being used for that kind of enterprise systems just yet.
    • bitshiftfaced 3y ago
      I'm not sure here how you differentiate minimalist from restrictive. I've always considered Go to be minimalist in terms of available tokens to the programmer: https://github.com/e3b0c442/keywords/blob/main/chart.png https://github.com/e3b0c442/keywords/blob/main/chart.png
• freecodyx 3y ago
  Golang pays the bills with little effort and frustration,
  • karolist 3y ago
    https://go.dev/doc/faq#go_or_golang https://go.dev/doc/faq#go_or_golang
    • th___4 3y ago
      Everything in Go is controversial, contentious, or at-war with itself. * It's name * Nils * Pattern matching * Enums / Sum types * Generics * Error handling Other ecosystems have recognized that pattern matching and sum types are the way forward as well as null safety.
      • kaashif 3y ago
        We're actually even at the point where Java has added language support for sum types and pattern matching! Java is also the most prominent example of a lack of null safety. Once Java gets around to fixing that in the next century or two, then Go will really be behind.
      • freecodyx 3y ago
        It’s fine, on the other hand it’s simple, concise, strong std library, and the std is written using go
• devnull3 3y ago
  Reminds me of a dialogue from the movie: "The Pursuit of Happyness" Interviewer: What would you say if man walked in here with no shirt, and I hired him? What would you say? Will Smith: He must have had on some really nice pants. Go has some really nice pants i.e Simplicity with good enough performance, backed by big corp. Simplicity scales!
• monlockandkey 3y ago
  I love Go. [Warning super hot take] If you are creating a backend service, the language of choice is clearly Go. Get productive within a week, straightforward to read, compiles to a single binary (easy deployment), suited for serverless functions, low memory usage , excellent ecosystem, static typing, composition over inheritance, sane dependency management, Goroutines instead of async/await, super fast compile times and very very performant. [Vs Language] Python: Very slow, dynamic typing, async await, multithreading is an issue, deployment not as straightforward, messy dependency management Java/C#: On the heavy side for resources, verbose and various design patterns, async await, around the same performance as Go Nodejs: Async await, slower than Go, node modules, deployment not as straightforward, single threaded execution Rust: async await, long compile time, high and long learning curve, on average will take longer to develop in Rust, sparse talent pool, faster than Go BUT for the effort it takes to get there, don't think its worth it and the extra performance is mostly not worth the above trade-offs (unless you operate on the scale of Discord) Yes there are issues with Go. No doubt. What it gives you by default is a language designed for the web backend. No contest in my opinion.
• nikolayasdf123 3y ago
  soon we will achieve AGI and travel to Mars and Go still not good fit neither for graphics, nor ML, no scientific computing, nor data engineering, nor embedded devices, nor VR, nor games, nor self-driving, nor industrial automation, nor robotics, nor video processing, nor desktop applications, ...
  • d-z-m 3y ago
    What does your first sentence have to do with the rest of your comment?
    • anacrolix 3y ago
      I think he means it doesn't make sense to be wasting time worrying about Go when it doesn't matter in the long run.
    • jodrellblank 3y ago
      I think it's a comparison[1] saying "the world has achieved so much with technology and Go has achieved so little". [1] not a good one.
• deergomoo 3y ago
  I recently (like, in the last couple of weeks) picked up a Go project from another team at work (coming from a largely PHP background commercially, but with a lot of dabbling in other languages like Swift in my spare time). I’ve enjoyed my initial foray into it so far. I like how small the surface area of the language is. I felt comfortable reading the code and starting to make changes within a couple of hours. While I love fancy complex features as much as the next nerd, there is something to be said about not having enough rope to hang yourself, especially when working in a team. I like having standard first-party tooling including a formatter. Goroutines seem super neat, as do channels. People say Go’s generic system is a little tacked-on, but PHP doesn’t have one at all and Swift’s can get quite complex, so I’m happy with it. I did find myself disappointed by a few things though, mostly around the type system. People consider PHP to be an untyped mess, but these days it actually has a reasonably expressive system that offers a lot of guardrails when paired with a static analyser. Swift has probably my favourite type system of any language I’ve used. Some complaints, in no particular order: I think zero-values are a mistake when you have a compiler that could make usage of uninitialised variables a compile-time error (Swift does this). I want the compiler to yell at me when I forget stuff, rather than just rolling with it until it inevitably causes some logic error somewhere. I sorely miss sum types and the ability that affords to strictly model a domain. It’s all well and good having linters that complain when I don’t handle an error, but I’d much prefer a compile-time guarantee that the return value of this function is a Value OR an Error, with the compiler forcing me to handle both cases. Granted PHP doesn’t have this, but it’s also a nearly 30 year old language that grew out of a simple templating engine. Swift is of course militant about this; you can’t even write a switch statement without handling all cases. Further to the previous point, there doesn’t seem to be a particularly ergonomic way to model optional values, besides using pointers and checking for nil. While PHP doesn’t actually enforce that you check before doing something with a value, nullability is part of the type (if one is supplied). I can define my function to take an `?int` in order to accept null as a value, but if I define it with just `int`, I am guaranteed to not receive null (albeit at runtime, because there’s no compilation step). Swift of course has the Optional enum with the associated syntactic sugar to make this very nice to deal with. It would seem that in Go, I would need to add `if ptr != nil` everywhere to have the same sort of guarantee, though I am very new to the language so there is perhaps some better way of handling this. No ternary operator…I accept the argument that nested ternaries are a readability nightmare but come on guys, given the infrequency in which they pop up in real-world codebases it doesn’t justify the visual noise that is “var-if-assignment-else-assignment”. Anyway, despite my griping it’s a neat language, just a shame the designers seem to have deliberately ignored so many advances in type systems over the last few decades.
• foobarbaz33 3y ago
  Most people like indent width 4. Some like a compact 2 or 3. Sometimes even 1! Others need 8 because of their eye sight. What should the indent width be? It should be TAB because anything else is wrong. Thank you go developers for embracing TAB.
• nottorp 3y ago
  Hmm considering i first thought "but Go is thousands of years old!". Doesn't Google owe a couple hundred million in royalties for the name to the ancestors of the Chinese and/or Indian people?
• phplovesong 3y ago
  Go is one of those languages that will be around after 30-40 years. Most likely lots of code today will still compile in 30 years. Go has succeeded and is the defacto networking language today.
• asylteltine 3y ago
  I can’t imagine a more FUN language to use than go. It’s just so damn pleasant to use. I love it.
• nunez 3y ago
  Thanks for an amazing, simple, and fast language!
• jordigh 3y ago
  It should have been called "issue 9", which would have been a great name, expandable to "Issue 9 from Google Labs", very unique, nicely abbreviated to i9 for compiler and filename extension. I was there, along with many others, and I'll never forget that this language has a dumb name and it could have had a much better name: https://github.com/golang/go/issues/9#issuecomment-66047467 https://github.com/golang/go/issues/9#issuecomment-66047467
• neonsunset 3y ago
  Fourteen years of Google language published on Google platform that first and foremost addresses internal engineering and culture issues of Google. Also, anemic and slow standard library.
  • kakwa_ 3y ago
    Given Golang popularity, it probably managed to solve more than Google's internal issues. It most likely ticked quite few boxes right: * easy syntax * fairly extensive std lib * easy memory management & mostly painless GC * easy shipping of dependencies (everything in one file, including runtime) * order of magnitude less tricky parallelism. In a world where Golang doesn't exist, quite a few recent software would probably look really different: * Etcd but in Java (hello Zookeeper) * Terraform but in Python * Docker but in C/C++ or Python * Kubernetes, but in Java and/or Python and/or C++ (hello Mesos) * Prometheus, but in Java and/or C/C++ And honestly, for most of these, either because alternatives in such languages do exist and mostly failed, or from performance/stability concerns, I think we would not have been better of.
    • kaba0 3y ago
      C++ and Java are still eons bigger within Google, and plenty new software is started with those over Go.
      • kakwa_ 3y ago
        Golang is not a complete replacement for Python and/or Java and/or C++. For example, if you were to create a complex native application (browser, game, cad software, etc), C++ is still probably the best choice. For data manipulation/transformation or glue scripting, Python is still a more convenient choice. If you want to structure an extremely large codebase and depend on tons of "Enterprisy" stuff, Java is most likely a good choice. (note: I'm caricaturally oversimplifying) Also software is rarely created in a vacuum: 1) software teams have certain skills and habits 2) new software is often created in a preexisting context 3) In fairness, language choice is often not that critical 4) Developers can be extremely vocal about technology choices, often way beyond the reasonable For all these reasons, even if we fall right in the Golang niche (small to medium size web api/app, "devops" tools/infra management and partially, some DB use cases), choosing Java/C++ over Golang could actually be the right choice.
• davewritescode 3y ago
  As a fan of Go the only really thing I’m missing is a better way to work with data. Something like LINQ probably wont ever be possible with Go but built in support for map/filter/reduce with some handy built in aggregations would make a lot of things simpler to accomplish. I’m not asking for the full Java streams equivalent, it would just be nice to be able to filter a slice or perform basic transformations without having to resort to for loops.
  • benhoyt 3y ago
    This is a lot more possible now that Go has generics (as of 1.18). I would probably never use these, as I find such libraries are a whole new domain-specific language to learn, and often don't make things much simpler anyway, but here are some libraries where people have done something like this: - https://github.com/ahmetb/go-linq https://github.com/ahmetb/go-linq: modelled after LINQ, but created pre-generics so only recently added some generics features - https://github.com/samber/lo https://github.com/samber/lo: kind of like JavaScript's lodash library but for Go 1.18+ (with generics) - https://github.com/asynkron/gofun https://github.com/asynkron/gofun: simple library with stand-alone functions to filter, map, and so on
• Xeoncross 3y ago
  There are a lot of issues one can point out about Go, it just so happens that what they picked sure makes the language compelling to me. Huge, working (unicode, streaming, etc..) stdlib that doesn't require 20 different third party packages to get a server running. Also has built in formatting, testing, and benchmarking(!) Compiling is so fast I can write tests that run on save in ms showing me outcome before I start typing again and actually enjoy TDD. This isn't possible with TypeScript, C++, or Java. I'd be happy for every other language except Rust to disappear tomorrow, but aside from that Go is just nice and unfussy to get really good performance with a quick dev story.
  • kaba0 3y ago
    > Compiling is so fast I can write tests that run on save in ms showing me outcome before I start typing again and actually enjoy TDD. This isn't possible with TypeScript, C++, or Java It is 100% possible with Java.
• dcchambers 3y ago
  I'll never forget when I was a freshman in college in 2010, someone from the language team at Google came to give a talk on this new little Go programming language they were working on. (For the life of my I can't remember who it was and that makes me very sad.) And ironically at the time my biggest thought was seeing the hand-drawn gopher and thinking "THAT'S the logo they're going with?!" At that time it was this cool but incredibly niche new thing...and now that gopher is iconic and the language is extremely popular. Who would have guessed what it would become? I think becoming the go-to language in the cloud native/kubernetes landscape has really helped the popularity as well. Personally between Go, Ruby, and some Bash I never feel tempted to reach for any other languages to get my work done.