48 ms·

Ask HN: Go programming language is over ten years old. What do you think of it?

• notankies 6y ago
  It's a real good Java
  • deepsun 6y ago
    Unfortunately, Go is not even close by the number of tools written for it, at least for web services, where I work. It's hard to imagine something useful that doesn't have either JVM port, or originally written in Java (testing/mocking, builders, freaking ORMs, frameworks). It's not always good though, in Java world you have to choose between multiple competing tools, while other ecosystems have mostly only one, often adopted from Java version (except Javascript, Rust, they have their own zoos). But IMHO Java is still the nursery for all kinds of tools for development.
  • afrojack123 6y ago
    Java is actually better(faster runtime and less energy usage) than Go but where Go beats Java is memory usage. C beats all of course. https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...
    • lanstin 6y ago
      Java might in theory be faster but I have never seen a real Java team put out code that was capable of doing 10k requests per CPU per second. Always hitting per thread limits or logging lock contention or GC issues etc. except one thing written by a genius with NIO. Ordinary people can hit those performance numbers with Go and without special smarts.
      • pjmlp 6y ago
        Don't mistake the tooling capabilities with those that use them.
        • _ph_ 6y ago
          Of course one shouldn't mistake those. But one has to understand, a tool is only as valuable as it actually produces result, not as what it could produce given a theoretical perfect programmer. C is an extremely capable programming language judging on "what you could do with it", but in reality, most programmers fail to create robust C code. And most Java code suffers from programmers using it in a less than optimal manner. Also, Go does not suffer from some fundamental Java problems, though they slowly get corrected. Go has value types, unboxed arrays. Generally, no struct in Go is boxed automatically. You have first class functions in Go and of course, it is statically compiled. It is true, that Hotspot often produces very good code, but for a lot of szenarios, a statically compiled Go executable beats it, as run-time compilation is not required.
          • pjmlp 6y ago
            Java also has AOT compilation to native code, if one is willing to pay for such tools (since around 2000, but now there is free beer AOT anyway). Value types are around the corner and I bet they will be done first than generics in Go.
            • _ph_ 6y ago
              As I wrote, Java is in the process of adding features that mitigate its problems. My post was pointing out a few things where Go is clearly ahead of Java.
              • pjmlp 6y ago
                Only on support for value types, everything else Java did it first.
                • philosopher1234 6y ago
• maerF0x0 6y ago
  you might like the State of Go talks eg: https://www.youtube.com/watch?v=0c-1KJwSMCw https://www.youtube.com/watch?v=0c-1KJwSMCw
• abatilo 6y ago
  The structural type system is something I really wish other languages started using.
  • Nullabillity 6y ago
    Structural types are one of those things that annoy me in both theory and practice, when I have to touch Go code. In theory, it's annoying because it prevents you from expressing constraints (think: monad laws, or Rust's Sync/Send traits). In practice, it makes stuff like go-to-definition nearly useless, which makes it a pain to read code written by other people. Especially when combined with the almost sadistic module system.
• codegladiator 6y ago
  The most productive new language. - great community - ample libraries - ecosystem support - no breaking changes (yet) - no magic, limited and simple - inbuilt testing/profiling/dependency manager
• midrus 6y ago
  It is a great alternative for things that otherwise you would build with C++,C or Java. Not so much for things you would otherwise build with python, ruby, etc.
  • lanstin 6y ago
    If you take a bit of time to think about the data flow, you can get it about as succinct as Python. And then you get to distribute a static binary that will be light on the CPU is needed and use all the CPUs if needed.
• pmb 6y ago
  They tried to make a better C++ and accidentally made a better Java and a better Python.
  • midrus 6y ago
    Agree over the java part. But Python is still orders of magnitude more productive, being it because of the ecosystem, available libraries, frameworks, or almost any other metric. The only advantage over python is performance, and maybe static typing depending on your taste.
    • sevagh 6y ago
      Go more than makes up for this in the deployment aspect, since deploying Python in 2020 (Python 2, Python 3, conda, pip, venv, system interpreter, poetry, etc.) is still a mess.
      • djstein 6y ago
        Only a mess if you use python 2, conda, etc... What’s difficult about this? /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh https://raw.githubusercontent.com/Homebrew/install/master/in...)" curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py https://raw.githubusercontent.com/python-poetry/poetry/maste... | python - brew install pyenv // update shell with pyenv pointer pyenv install 3.9.0 pyenv global 3.9.0 poetry init poetry config virtualenvs.in-project true --local poetry install For deployment, Docker python3:alpine, install poetry, copy over pyproject.toml and install
        • Thaxll 6y ago
          pip is broken in no many aspects, between pip and pip3, things installed in your home folder vs /var, "binary" entries that don't exist after installing a tool, cryptics stack traces because of missing libs / not compatible for your platform ( native build ) ect ... Why do we need virtual env in 2020? It's one of the worse "modern" language to build, even Java / NodeJS are better.
• rantwasp 6y ago
  i think it’s both good and bad at the same time and YMMV depending on how you use it / where you use it. i like: being able to cross-compile things into a single binary. raw speed in case of simple services i dislike: the way generics and package management were (are handled/ignored?) and the super-verbose error handling. go would not be my first choice but i can understand why people find it appealing
• sabellito 6y ago
  Speaking strictly about the language, and not the platform, I'm skeptical about the lack of more modern core library and language features like immutability, pattern matching, and records. They spent almost 10 years saying "we don't need generics", but now are implementing it Also, the dependency management.
  • Mr_T_ 6y ago
    > They spent almost 10 years saying "we don't need generics", but now are implementing it You're making things up. Not a single member of the Go team ever said "we don't need generics". In fact, the FAQ stated from day one that they "continue to think about it", and that "Generics may well be added at some point".
    • vram22 6y ago
      Yes. IIRC, Rob Pike or someone else on the Go team even said something like "it's hard, so we are taking our time about it, may implement it later". Edit: see [1] below. Also googled and found this: http://lambda-the-ultimate.org/node/4554 http://lambda-the-ultimate.org/node/4554 which includes this section: Go might have generics in future with this text: The Go FAQ recognizes the issue and says that generics may be added at some point... http://golang.org/doc/go_faq.html#generics http://golang.org/doc/go_faq.html#generics Considering how Java generics turned out I am fine with the Go team taking the time to think about a proper design for generics in Go :-) By ted stockwell at Tue, 2012-06-26 15:03 [1] The golang.org link above about generics also says this: We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.
    • tsimionescu 6y ago
      They've always also said "show us some compelling use cases", as if those still need to be shown ~15 years after after every other language except C got them.
      • cma 6y ago
        C has the preprocessor at least, reducing the need for them.
• setheron 6y ago
  The real value is that Google is pumping a lot of money into writing high quality libraries. Any language with similar backing would do equally as well. The golang standard library and high-quality third-party libraries are really great
• ram_rar 6y ago
  Its a good compromise between python and java. We gradually moved our codebases from python to golang. This has reduced our infra cost quite a bit. Some of our mission critical stuff is still in C++ and I'm fairly certain golang would not replace any of those. I hope the golang community takes a thing or two from rust in terms of package management.
  • Mr_T_ 6y ago
    > I hope the golang community takes a thing or two from rust in terms of package management. Go's dependency management was designed after analyzing Cargo and its problems: https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs
• marvinblum 6y ago
  I've been using Go as my main programming language for the past 5 years or so, and it's still my favorite language (picking from PHP, Java, C++, Python, and a few more I have experience with). Its simplicity makes it relatively easy to write high quality software and reduces maintenance, as there are no breaking changes in the language itself. Tooling is on point, you get everything you need, standard formatting (which helps to keep all code bases in the wild consistent), and cross compile. One of the things that might make it even better are generics, but I haven't really missed them so far. In conclusion, I don't think I will switch to anything else soon.
• pizlonator 6y ago
  It’s a unique and different language that clearly hit some kind of niche. It’s great when a language has any users and this one has quite a bunch. That’s super cool! Personally I don’t like it. Not low level enough for when I need to go low level, not high level enough when I want to go high level. Also I would have wanted generics right from the start; that should be the norm for typed languages unless the types are really super simple (Go’s are complex enough to warrant generics in my opinion). But, maybe the reason why Go has the niche it has is because other programmers prefer it the way it so. So it goes with languages - it’s an aesthetics thing just as much as it is a technical thing.
  • ra7 6y ago
    Go has wide enough adoption that I don’t think you can call it niche anymore. It’s become somewhat of a de-facto systems/infrastructure programming language and is replacing Python in a lot of places where it was traditionally used for automation. The language is simple, performant and writing concurrent code is intuitive (although I feel Go developers tend to get carried away using channels/goroutines).
    • lanstin 6y ago
      Because every time I need to use a lock I know I am not smart enough to do so. Channels and go routines, I can reason about. (Tho they are slower - I have a runtime stats package that just stuff the numbers into a channel and then returns to the calling goroutine. I did an implementation using Atomic’s and it could sustain like 20x more calls per second before using all the callers CPU. But I still use the channel implementation.
      • nicoburns 6y ago
        Rust is ideal for this scenario: it lets you use the faster locks / atomics, and the compiler will check everything for you (assuming you can use a standard implementation rather than needing to implement your own - but there are well tested libraries for most common use cases).
• clktmr 6y ago
  Go was the first language that put a real effort in building a community, best practices and a healthy, sustainable ecosystem. This starts to pay off as there are more and more actively maintained, high quality libraries available.
  • dav 6y ago
    This claim of first is not true at all. The Ruby community did all this at least a decade before Go existed, and I imagine there are other examples.
• SubGenius 6y ago
  Decent for writing web backends, APIs, RPC services. The high number of libraries also help. The language is very simple, which is good or bad, depending on who you ask. Tooling could use a lot of work though. After switching between vim-go, gopls, and a handful of other language server implementations, I've given up on auto-completion, definitions etc altogether. Maybe it's my setup... Overall, I'm pretty happy with running a fairly big Go app in production. Would I choose Go for my next serious project? Most likely.
  • marvinblum 6y ago
    Have you tried GoLand?
    • SubGenius 6y ago
      No, but I've heard really good things about it, and even tried out the demo when it initially came out a few years ago. I was hesitant to change my Vim workflow though. Thanks for mentioning it, I think I'll take another look at it now. Having a real IDE probably has more benefits once the code grows beyond tens of thousands of LOC.
      • jen20 6y ago
        FWIW IdeaVIM is the closest thing to "real" vim around, so you can at least use reasonable key bindings with Goland (and all IntelliJ-based IDEs)
  • psanford 6y ago
    Sorry you've had issues with gopls, the gopls deep completions are one of my favorite things! At this point gopls works way better than godef+gocode ever did for me.
• anonymoushn 6y ago
  Non-exported struct fields are a way of preventing your library from being composable. Checking if a value implements an interface is a way of writing surprising bugs. The standard library uses both of these features extensively, to give users bugs and prevent itself from being composable. Checking that the user uses all values bound to variables but letting them discard errors by not binding them to a variable is a weird choice. Channels panicking instead of returning an error is a weird choice. It's ok and I would like to to use it instead of Java.
  • closeparen 6y ago
    Can you elaborate on private struct fields? The same criticism would apply for any OO language with access control / visibility of fields right?
    • pjmlp 6y ago
      I guess is the typical critic of people used to monkey patch libraries in dynamic languages.
    • anonymoushn 6y ago
      The particular combination of things is, some library includes some method signatures that accept and return a specific struct (not a specific interface). Then, also, there is no exported way to make one of that struct, or to set its fields. Now you cannot write a library that wraps the original library and exposes the same API (unless you use unsafe and reflection). In the OO languages I have encountered there seems to be a stronger convention toward using interfaces instead of struct or class types in this sort of situation, but people are certainly free in Java to use a final class type as the type of their parameters and return values if they want to make their library less composable.
      • closeparen 6y ago
        Is this a different problem from private constructors / setters in OO world?
• akmittal 6y ago
  It does lots of things right 1. Built in support for tooling, testing, formatting etc 2. Trying to make concurrency mainstream 3. Large and developer friendly standard library, there is hardly any programming language where web backed can be written without using a framework or a library. Go is one of those.
• pydry 6y ago
  My fingers are getting real tired from typing if err != nil all the damn time. I do like it for small things - compiling to one (albeit huge) binary and its relative speediness is nice. I wouldn't use it for large systems though. The amount of code really balloons over time, relative to, say, python and that SLOC correlates to bugs and maintenance cost.
  • politician 6y ago
    Have you considered using a snippet or macro to type the 13 characters for you? Snippets or macros are available in most editors.
    • baq 6y ago
      if everybody could use a macro in their editor or IDE, it's a strong hint that the language could do better. (looking at you, java)
    • curryst 6y ago
      I have debated this. I was actually going to formulate mine into a pre-processor so that if I can change a macro it will retro-actively update the other ones. I thought it would be useful for this, and for structs that I want to replicate for various types. At what point are we just creating a new language that compiles to Go, though?
  • andreygrehov 6y ago
    Curious, what's your definition of a large system?
    • apta 6y ago
      I'm not the person you're replying to, but I've had similar experiences with larger programs in golang. It's quite terrible to deal with, and overly verbose. I'd say anything more than 2000-3000 lines and golang becomes tedious to manage (and that isn't much given how verbose golang is).
• piinbinary 6y ago
  I find myself reaching for it over other languages when I want to build small servers with a bit of in-memory state or a bit of heavy processing. For little search-engines, Go is perfect. While writing servers in Flask + Python is much more convenient, I still prefer Go because I don't run into the limits that Python has. The development process is fluid enough that I wish the language was suited to more usecases. When I need to handle complicated data (e.g. abstract syntax trees), I use Rust or Haskell because of their rich data types. But it tends to be much harder to get things running in those languages (borrow-checker and monads, respectively). I want to reach for Go to make those problems go away, but then realize that it would be really painful to try to express the program in Go. I understand that other people are unhappy with Go's development process, particularly if you deal with package versioning. The language design itself may have been backed into a corner where adding generics will create an ugly mess (what will the standard library look like if it tries to maintain backwards compatibility?). Time will tell. The tooling is mostly pretty good, but many things feel half-baked (compared to more mature ecosystems). On the spectrum of 'written in a weekend' to 'dozens of developer-years of work', the package "net/http/pprof" feels closer to the weekend side. There are bright sides, like having the production parser available as a library. It's a language that is frustrating in different ways from other languages. Instead of fighting with Cabal/Stack, you have to write a million `if err != nil {}` statements. Part of what makes it frustrating is seeing how good it could have been.
  • mylons 6y ago
    What limitations do you run into with the flask/python setup? (I’m not asking what ARE the limitations, I’m asking which ones specifically you run into)
    • piinbinary 6y ago
      For large data sets, it sometimes spends all day in GC while just loading the data into memory (this is actually more of a problem in Ruby than in Python, but it still exists here). It's also not very efficient about using memory, so it can be easier to get a dataset to fit in RAM in Go vs. Python. Python also makes it hard enough to make use of multiple cores that it becomes easier to just use Go. The same goes for making it fast. It can be done in Python, but I tend to be happy with the performance of my Go code out of the box.
• raggi 6y ago
  I use go (long term) in places where I need as part of my DR plan the ability to fix stuff without expert access. The toolchain is simple enough that I can maintain it in this scenario alone, and meanwhile the stdlib is complete enough as to be useful for solving a multitude of problems, while offering the ability to produce programs that run on many systems and integrate with them with sufficient efficiency. It's a really usable systems glue language, and it powers chunks of my telco infrastructure. This pro is mostly about the implementation/engineering design. My biggest gripe with the language is that it doesn't scale that well for teams. It requires a certain culture & approach to produce maintainable programs that goes against the grain for many developers, and while I enjoy the simplicity it offers, that simplicity leads to cost of ownership problems in many team scenarios. This con is mostly about the language. As a specific tactical item, the runtime multiplexer could do with a refactor. The merging of the pollers essentially could continue until it is much cleaner, there are more layers there than necessary to solve the problem. You can follow the FD close path to understand the strains of the current factoring. Such a cleanup could probably remove some overhead for io heavy workloads too, maybe even drop some lock contention. Oh, and the spins should all be removed from the runtime before we really start using it on very high core count systems. This opportunity is mostly a side effect of a long history of incremental improvement.
  • bborud 6y ago
    Could you elaborate on why you think it doesn't scale well for teams?
    • InvOfSmallC 6y ago
      Imho because it is highly opinionated and the designers of the language also suggests best practices. They don’t do anything wrong in suggesting best practices although some of those best practices only work when you write infrastructure code and not micro services (with business logic) and some programmers cannot really compute that and they stick with the religion. I also had the same experience of not scaling for teams for this reason, because you had people who would not allow for discussion. It is honestly never happened to me before. Given it could only be a matter of having found just a bad apple in the team, my first reaction was that this language doesn’t scale with teams.
• theonemind 6y ago
  They set out to make a pretty generic ALGOL/C-ish/Java "OO"ish language with sharp corners filed off and some decent concurrency primitives put in. They executed successfully (they got the language out there, built an ecosystem, didn't undermine their own goal in the language design or make it unusable.) If I had to choose between Go and C++, I'd probably pick Go because of C++'s complexity, so they really nailed it. In the grand scheme of things, it's a really forgettable language. Frankly, I haven't programmed in it. I don't need to. I know ALGOL+(N+1) when I see it.
  • kcartlidge 6y ago
    > In the grand scheme of things, it's a really forgettable language. Strangely enough, for me that is one of the major plus points. A forgettable language (which is not the same as a language which you forget how to use) is one which gives you the tools for the job and then gets out of the way. Some other languages feel like prima donnas with their shiny brilliance and complex possibilities. I'll take a small, dirty, simple, and performant back-seat one like Go every time.
• intricatedetail 6y ago
  Python and Go is a dream stack. Prototype services in Python and when performance is needed, do Go implementation.
• oriesdan 6y ago
  After 9 years of ruby, I finally switched to Go as my professional language 3 years ago, after a couple years of side projects with it. My feelings after building for that long : safety and productivity. I initially thought it was because of moving to compiler and type checking, but then I learned C for my personal use (an other thing passing through Go allowed for me), and was surprised to realize my C compiler was not allowing me close to the same peace of mind than my Go one. Go is just a well-designed language that makes everything straightforward. The main reason I started learning and building with C is that I'm not confident the code I write in Go will age well. The discussions around Go-2 make me extremely nervous (it has something that reminds me of angular-2, python-3, symfony-2, bootstrap-3, and others major redesigns who left developers in a lot of troubles, I hope time will prove me incorrect). So basically, I'm enjoying it, but I worry if it will last. I guess that means I really love it.
  • ainar-g 6y ago
    Re. Go 2. The Go Team people have repeatedly said that they want to avoid the Python 3 situation, so even if there will be a real, compatibility breaking Go 2, it won't be anywhere near that level of incompatibility. They'll probably just fix a few nits like string(int). Re. C. You really should use at least one static analyser when programming in C. Clang-tidy has been my go-to tool for that, and it's been working pretty good.
    • oriesdan 6y ago
      Thanks, I'll have a look at it.
  • dkarlovi 6y ago
    Can't say for the rest, but Symfony 2 was a resounding success. Current Symfony 5 is very similar to Symfony 2, with just a ton of refinements and facelifts.
    • oriesdan 6y ago
      Oh yes, I'm not saying those are bad projects. What they have in common is that migrating from previous version to them was especially difficult and painful. The few symfony developers I know indeed loved symfony-2 very much. But migrating their projects from symfony-1 to symfony-2 was felt basically as a rewrite.
• darkest_ruby 6y ago
  So many comments, not a single mention of Rust...kinda sad.
  • edfletcher_t137 6y ago
    "What are your thoughts on the Go programming language?" "Well, let me tell you about this other language called Rust..." Classic Rustacean: sees zero daylight to inject oneself, does so anyway.
• candiddevmike 6y ago
  I really like it. It makes it really easy to have easy to develop monoliths--Go will scale (vertically and horizontally) and can easily handle doing everything. There are some annoyingly verbose and not DRY parts, like adding instrumentation or context, but it leads to less weird side effects. The tooling is also very good, though I wish more of golangci lint would move into stdlib so I could just run golint.
• rowanG077 6y ago
  It's good for small scratchpad programming but I wouldn't use it for something large or longlived.
• _ph_ 6y ago
  I use Go for many years now and I quite love it. Not for everything I do, but for a large part of my programming. In my eyes, it hits a sweet spot of not having too much complexity, no magic and being an efficient language. It has a fast compiler, a good module system and a strict type checker. Certainly helped by the module system, there is a rich set of libraries in Go. Compiling to a single file executable also solves a lot of deployment problems. In my eyes, Go is also the modern times successor to the Wirth family of programming languages. In Europe, for a long time the Wirth languages were far more popular than C was. Only in this millenium they faded from public perception, but with Go many of their concepts and philosphies come back, even when dressed up like a C language :).
• blabla321 6y ago
  It's pretty shitty, why on earth would I create {} for everything
• whateveracct 6y ago
  It's meh. I find no matter how much I use it (going on like 6 years on-and-off now), I do a lot of tedious work. If I'm getting paid by the hour or salaried, that's fine. I'll get paid to do compiler-work by hand. But if I'm trying to do a personal project, that amounts to a waste of time with 0 value.
• edumucelli 6y ago
  I do not like it. The lack a proper (1) Class, (2) Enums (seriously, using constants to describe a proper Enum like Java has is a must, we are in 2020 not in 1980), (3) being able to call methods on methods on nil pointers, (4) generics that are available for langauge internals but not for language users, the list could go on. All this just because I am working on it few months now. Let's see how it will evolve through the years, but could not have been worst start.
  • lanstin 6y ago
    I think most Go people will put most anything that goes over the wire into some protocol description language like protobuf or even swagger. Inside your call stack I am not sure you need enums instead of constants. If you are either persisting or transmitting data then you want some formal description which will essentially get you enums as useful symbolic values.
    • cy_hauser 6y ago
      Lack of real enums is one of my biggest annoyances with Go. So so many times I've put the wrong enum value in because it's just an int and it matches another set of enums. I've taken to putting each set of enums into a separate file and separate folder just to help the compiler catch this. The project I'm working on now has about 25 separate enum files+folders. Gagh!
      • TopInvestor 6y ago
        I made this playground: https://play.golang.org/p/S1Yh0Oq24q- https://play.golang.org/p/S1Yh0Oq24q- There are a ways to do unique enums with implicit repetition. Like this: I 0 1 2 II 101 102 103 III 201 202 203 IV 10 20 40 80
        • cy_hauser 6y ago
          Yes and no. Most of the time my enums are well defined: ContactStatus, AwardLevel, JugeStatus, for example. I have not control over the names or values and all have a "Revoked" value. When they come in from an external system it's pretty easy to parse them and convert them to the wrong type if someone isn't paying close attention. Then they don't get caught for a week or so because the code compiles, runs, and appears to work correctly except for these occasional odd results.
• _huayra_ 6y ago
  I'm glad it enables other folks to build such great tools with it, but I don't think I'd pick it for my own projects or prefer to code in it at work. For the clever stuff they picked up from ConcurrentML (channels), they treat the user (developer) like an idiot due to having to spell out everything in great deal compared to languages that have a better type system. It's good to get a lot of programmers onboard at Google who may have never written a line of C or C++ in their life. Coming from Java or Python, I can see the proposition of a language like Go. As in those languages, Go doesn't have myriad points of "unwritten code", e.g. having to worry about lifetimes of objects, the "rule of 5/6" for autogenerated methods (and knowing when the compiler generates some and not others) in C++. It's all there in the code with great verbosity. I think people complain about Go because it's not the hammer for their nail. It's not for folks working with a team of moderate to elite-level C++ or Haskell folks who enjoy writing "beautiful code". It's for a company with an army of developers of varying degrees of skill who all have to maintain the same codebase without exploring the dark arts of the C++ abstract machine, and to do it in a much faster language than Java. Like Java, it's driven primarily by business decisions for application software that needs to support all sorts of developers for server-side applications. It's very good at that. It's just that playing to that lowest common denominator creates an unpleasant experience for folks who want a more expressive language.
  • cy_hauser 6y ago
    > I think people complain about Go because it's not the hammer for their nail. Or it's _almost_ the correct hammer! If they'd just fix those damn
    • _huayra_ 6y ago
      It's the correct hammer for a company that employees tons of people who, for the most part, don't really care about the craft of programming and don't want to be bothered by learning anything difficult. They just want to ship their features on time and get their year-end bonus or whatever pat on the head. Even at a company like Google, I don't think most programmers are really pushing their understanding of software design or tools or techniques. They learn all the silly interview stuff about red-black trees then are just happy using coding within the well-defined bumper car arena of Google's frameworks and coding guidelines (e.g. Golang with no "hidden code" like in C++, where not writing certain things causes the compiler to generate stuff for you). We all read Hacker News and generally are excited by new advances in things (e.g. C++ concepts! No more stupid SFINAE!), but most people at big companies don't. It's truly a testament to the genius of Go that it solves this problem: much faster than Java, not complicated because most programmers at Big Corp can't deal with complexity (e.g. no exceptions in Google's C++ coding guideline), and understandable without too much effort by the average programmer at Google. We all understand what it looks like without this effort: The Monolith of Bug Spaghetti Code I work for an extremely large software company that is stuck on C for decades. I try to use C++ where I can, but I usually get shot down in code review with a message of "C++ is too complicated for your colleagues to understand what you did". To solve the code mess, they implement their own languages to generate the boilerplate C (e.g. like protobufs, but poorly done and NIH because some guy wanted a promotion to "Principal Engineer"). As much as I dislike Go, I would take Go over the current situation I'm in...
• cercatrova 6y ago
  The lack of algebraic data types makes it hard to use, as opposed to other languages. Even Python now has ADTs with type hinting and Microsoft's Pylance language server in VSCode.
• dmayle 6y ago
  More and more, when looking for (open source) software solutions to adopt for my startup, Go as a development language is a deciding factor. Go-based software is smaller, faster, easier to deploy, easier to update, easier to contribute to. I find that the installation footprint of a Go-based service is usually in the 10s of megabytes or less, where the installation footprint of pretty much anything else starts in the hundreds of megabytes. In the classic world of one or two servers for a small company, sure, the disk space is meaningless, but with containerized workloads, small images are great for quick deploy, and quick iteration.
  • TopInvestor 6y ago
    Fast compilation was one of the main reasons Golang was invented. The gradual accumulation of #include clauses in C programs scales very badly. A large distributed compilation system was created in Google to handle the slow compilation. One reason is you never know if some #include is actually needed. In Golang unused dependencies are a compile-time error. The generated object file includes type information for all related import dependencies in binary format. This speeds up the compilation significantly.
• dunefox 6y ago
  I think it's boring, overly simplistic, and ignores the last couple of decades of PL research.
  • bborud 6y ago
    Boring is actually what a lot of people look for.
    • q3k 6y ago
      Yep. I use Go precisely because it's boring.
    • chridou 6y ago
      I never understood why people are looking for things which are boring and I think it is mostly employers who do. They should look for something which is good and solves their problems. I don't know how something with the attribute boring is of interest here as other attributes for a technology/PL might be much more important... Actually they mean something different with "boring": It is just a lack of courage for simply saying "We are most conservative, do not want to move forwards and are not willing to take any risk. Also we are scared of specialists and talent and want to stay mediocre. Actually working with us is boring."
      • dunefox 6y ago
        This, plus it enables them to fire and replace developers without much difficulty because there's a great number of people who know these languages (see Java...).
        • bborud 6y ago
          You are actually arguing for mediocrity. If someone needs to protect their employment by making their work more obscure so they won't be replaced then they probably aren't a very good hire. Companies tend to want to retain highly competent talent - not mediocre people or incompetents.
• jamil7 6y ago
  I've picked it up from time to time when I've had to, either for a small web service or cli tool. It feels kind of like a blunt instrument rather than a fine tool but thats also totally OK. It seems to have found it's place in various parts of infrastructure tooling and developer tooling.
• deleted 6y ago
  [deleted]
• pjmlp 6y ago
  It was a large mistake to ignore the lessons of Java and now the language is full of quirks as well, including the upcoming generics design. Regardless of the whole systems programming language polemic from the anti-GC crowd, several projects deployed into production like gVisor and TamaGo prove otherwise. Finally thanks to killer applications like Docker, Kubernetes and everything around them, Go has become unavoidable for many developers, regardless of our opinion towards the language.
  • staticassertion 6y ago
    > several projects deployed into production like gVisor and TamaGo prove otherwise Do they? AFAIK gVisor absolutely had to fight with Go, and it has a huge performance impact, and lots of larger projects have done some semi-absurd work such as implementing their own generics impl via preprocessors.
    • pjmlp 6y ago
      Just like C then.
• stperrin 6y ago
  Go is a welcomed simplicity to the stack in a world where everyone is over complicating software engineering by jumping to Kubernetes and micro-services. Simplicity really is where Go stands out against languages like Java. Yes, you may write more boilerplate and break DRY, but your code will be readable and won’t contain any hidden magic. We spend most of our work day reading and trying to understanding code. What you see is what you get with Go! Side note: Go also runs fabulously on Kubernetes and is great for building micro-services :)
  • edfletcher_t137 6y ago
    All of this, 1000%.
  • mrmonkeyman 6y ago
    Ironically Kubernetes is written in Go.
• bsaul 6y ago
  Go taught me how we tend to rely on overly complex structures to solve our daily problems, which makes our code look smart, but in fact is harder to maintain and understand by newcomers. 99% of the time, trying to use idiomatic go instead of fighting the type system lets you have more maintainable and easier to understand code. Now, every time i'm back to using another PL, i tend to rely on advanced type systems feature much less frequently, and only after making sure i'm not making the problem more complicated than it is.
  • doktorhladnjak 6y ago
    So true. I was nervous about not having generics in Go but haven't missed them after primarily working in it for several years. You have to stop trying to write C++ or Java or C# in Go.
    • pjmlp 6y ago
      You can perfectly write C++ (from around 1993), Java (until version 1.4) or C# (until .NET 2.0) in Go. That is the whole point, we know better 25 years later.
• hexmiles 6y ago
  I introduced it where i work. While it has some drawback (as any language) i find myself most productive when i'm writing in go. Just this week i wrote an entire toolchain for developing with an embed device, that now i can distribute to anyone that need to work on that project. Before go i used nodejs/python due to the large ecosystem of library, but go nowadays has a similar ecosystem and allow me to build static executable without any dependency. That is super useful since i work with different OS (ubuntu, fedora, windows and macos). Also even sloppy/draft code is really fast and i don't need to start optimizing and profiling from the start like in python (i often process large dataset). Lastly the language is very simple and my colleague who ,didn't even know go, learned in a week and, most importantly, is able to navigate my large codebase without much help (that for me is the biggest advantage of go)
• stevefan1999 6y ago
  Frustration over not having a proper parametric polymorphism (Also known as “static generics”) so I cannot write elegant functional style code to promote more code reuse. You wonder how do you do some kind of Map/Filter/Reduce in Golang? Check out go-funk in Github but bear in mind they use reflection to emulate it so the performance can be very dissatisfying. This is the biggest pain point of Go throughout my journey and I have been waiting so long for Go 2! PLEASE!
• svntid 6y ago
  I work with golang since 2011 and am still in love with this language like I am with no other. I am super impatient for the generics release in 1.17 aroung August next year as I think the current proposal is super good. Besides sometimes I miss adoption of golang in fields like ml and data science eg voice recognition.
• mitchellh 6y ago
  Wow! 10 years already. I'm the founder of HashiCorp and I'd love to share my thoughts. Credentials: I started using Go around 9 years ago and since then I've built a company of over 1,000 employees with ~250 engineers that write Go full time. We maintain dozens of open source projects and libraries (Terraform, Vault, etc. etc.) all written in Go. We've shipped commercial products that are used by a significant percentage of the F500. Vault for example serves trillions of secrets per year for _one_ company that we know of. I could probably write pages and pages so I'll try to highlight a few things. Go is not a perfect language or community by any means but I love it. NOTE: Folks often read this feedback with the opinion of "but language X can also..." or some variant and I hope that doesn't come across. My feedback is not against any other language unless I'm specifically using an example. Another language might solve all these same problems for you! I'm just sharing how Go has been fantastic at these aspects for us. == Junior and new-hire friendliness Go is a very simple language. From the beginning of the company until now, we can hire people who have never used Go, point them at a couple resources (i.e. Tour of Go), and they can be committing to production-grade projects within a week. It is incredible. Go makes it really hard to do anything that isn't obvious. The cost of this is often verbosity or repetition. But the benefit above is well worth it in my opinion. I know lots of people disagree with this but I personally prefer to repeat "if err != nil" 1,000 times versus introducing new control flow options that now must be educated. I love telling new folks (junior or not): read the file top to bottom, that's how it'll execute. And for the most part, that's true. As someone who built a rapidly growing team/company around Go, this has been indispensable. == Flexible Any "general purpose language" can theoretically write any software. However, I'm sure we'll all agree that its easier to write some software in certain languages, and that's a good thing. However, I've been blown away by how flexible Go has been without feeling forced. We've written desktop CLIs, web APIs, distributed systems, security software, networking software, infrastructure software, accounting software, bots, etc. all in Go. And most of these categories are at a scale of millions of downloads per year and successfully in production. It's very cool to see that coming from a prior major background in Ruby where there were significant tradeoffs when doing these things. It was _possible_ of course but you had to really understand the tradeoffs you were making. In Go, there's certainly some tradeoffs but they've been minimal and Go has just worked. As both an individual contributor and manager, this flexibility has been awesome in building a company around. == Cross-platform Compilation and Statically-Linked Binaries Since the first day I adopted Go 9 years ago, Go has encouraged and simplified static binary compilation and simple cross-platform compilation. Today you basically set an env var of what platform you want to target, run `go build`, and it usually works. You still have to learn of various gotchas around platforms (API availability, filepath awkwardness, subprocess/signal behavior, etc.) but the compilation aspect alone makes it so much easier to tackle this task. My previous experience of at-scale software I built was Vagrant in Ruby, and making that work across platforms was a constant, enormous challenge. I had to spend a few months full time just to get installers to help setup the proper runtime environment across platforms. Looking at this also from the perspective of rising popularity with ARM systems and other less standard architectures (even Power for enterprises...), this property of Go has been very important. == Culture The culture surrounding the Go community is generally one that is very philosophically aligned with how I view software. I would roughly describe it as pragmatic & measured. I think this culture is exactly why many people dislike Go (or seem to "hate" it which I think is a pretty wild emotional reaction to a language for programming computers but I digress). The Go community doesn't chase the next hot thing or rush to implement the "state-of-the-art" without a very measured, pragmatic approach. Some view this as Go being inferior by some definition but I view it as a huge benefit. Go core in particular appears to me (I'm not part of the core team so purely an opinion) to be a measure-twice-cut-once (or maybe measure like 8 times) approach. And I love that. == Fun At the end of the day, the language is generally fun for me. I like writing it. And that's important, too. == Conclusion I'm very lucky that Go took off as a language in the industry I built my company in. It certainly wasn't that way when we started using it (it was pre-1.0, pre-Docker, pre-K8S, the majority of infra sw was still in Ruby). I feel that the language is super productive (we built Vault 0.1 in ~6 weeks for example), it has shown to scale to the largest needs and does so stably (Vault is in the hot path of every trade in one of the major US stock exchanges and has never gone down there), and we've been able to build a large company and active OSS community around it. Hands down a successful choice for us with zero regrets.
• one2know 6y ago
  Great tool, two big negatives. First, checking result values is dumb. It adds 50% more code. Add exception handling. Second, the way imports work is obviously due to some internal google kitschy-ness. Remote import paths are so dumb. People set up entire domains and CDN's just to host some code. The import path has to have a specific format, you can't have three levels. github.com/me/sub1/module won't work, so everyone creates mypersonalgithub.com/sub1/module. It feels like one L3 at google set this up on a Friday, and the industry has to live with it. Of course all this code will be broken in 3 years. There is no easy way to point imports to a local development copy of a repo because google uses a monorepo and everyone else has to live with it.
  • lanstin 6y ago
    A super important principal for large code base is locality. I should be able to look at a function and understand everything about its possible code paths. Exceptions make this impossible (most of my experience with exceptions coming from C++ and Python). People that think like me would forbid exceptions every where.
    • one2know 6y ago
      return values don't say anything about possible code paths. If you are saying the function should document what could go wrong when it is called, Java solved this 24 years ago when each method lists the exceptions they throw. If you need to know what the back trace/call stack was when the error happened, well that is stored in the exception. People that use return codes simply don't check every possible value, otherwise they would see that it increases program length by at least 50% and makes the code unreadable. A common pattern in Go is this if (err == MY_ERROR) { log my error; notify user; return MY_ENCAPSULATING_ERROR_CODE } for high quality code this has to occur for every function call in the entire codebase. So you'll get huge functions which are mostly 'if' statements checking error codes, logging the results, and returning another error code that has to be checked again one step up the call stack. moving from c++ to java 20 years ago it was clear that the c/c++ community didn't really know what they were doing in this regard. A lot of c/c++ dogma boilerplate code was holding it back. Too bad some of it made it into golang.
• Glavnokoman 6y ago
  Being backed by Google contributes a big deal to its (relative) success. I think it is the most limited and ugliest of all the "modern" languages (Rust, D, Zig (never tried Swift)). And at the same time it seems to have the most significant output of all these (docker, kubernetes, gitea...).
  • panpanna 6y ago
    I find it more important that it is backed by Rob Pike. He doesn't cancel things when he gets bored with them.
    • Glavnokoman 6y ago
      maybe he should
• jokethrowaway 6y ago
  We have a few go web apps to maintain and, honestly it's not a pleasant experience. - Package management is terrible. - Development on Mac is not a great experience (someone in the team purchased a paid IDE, everyone else just run everything through a docker image, are we missing something obvious?). - The language is not flexible enough (lack of generics?) and code is significantly longer. - Lots of quirks. I'm sure you can learn the language and overcome these small annoyances (and that's exactly what we did, because we wanted to squeeze more performance out of our services), but personally I think nowadays we have better languages which perform just as well (eg. Rust).
  • lanstin 6y ago
    Since they added go mod I find the dependency management to be ok. And I use emacs so Mac or Linux it is a pleasant experience. You have first class lambdas so you can do pretty much anything in the language that doesn’t depend on syntax. It is a language with the aesthetics of C - small and simple syntax. Things that make the code more verbose, eg error checking, are things C programmers think you should do anyways and are morally suspect if you set up some invisible throw/catch system between your lower level code and your top level. Everyone typing code must reason about errors.
    • djeiasbsbo 6y ago
      Worth noting that Go Modules are still relatively new (Blog post from March, 2019 - https://blog.golang.org/using-go-modules https://blog.golang.org/using-go-modules) so some people in this thread might not be aware of them. I find that dependency management works well enough now.
  • wrs 6y ago
    Go works fine for me on the Mac with VS Code — in fact I recently used it to develop a Windows service so I wouldn’t have to deal with Windows (except for testing, of course). The cross-compiling is really easy.
• seanwilson 6y ago
  I don't code with it but I use Hugo (a static site generator) that's written in Go because it's ridiculously fast. Ruby and JavaScript static site generators I've tried end up taking several seconds to generate a handful of pages when Hugo spits out hundreds of pages in less than a second. It's pretty crazy how used we are now to slow dynamic languages. I also like how Hugo is available as a single binary file - much simpler compared to the complex build chain of a typical JavaScript app.
  • spurgu 6y ago
    I slapped together a static site generator in (mostly) Bash the other day and it renders all of my 6 shitposts (Node for MD -> HTML conversion) in 2.7 seconds flat and I'm perfectly happy with it. Or I was. Now your post made me want to rewrite it in Go, for science.
    • MH15 6y ago
      My Node.js (well, Typescript) static site generator that I wrote for my blog is carefully written to be fast enough for me. I am considering rewriting in Go too, "for science", but I'll probably continue to use the Node.js version if only for the npm packages I use. https://github.com/mh15/neanderthal https://github.com/mh15/neanderthal
• sagichmal 6y ago
  It's a lovely language perfectly suited to building network-oriented services in market-driven organizations. It's basically the only language in meaningful use that optimizes for the right things in this context: productivity at the team scale (rather than the individual scale) and making things easier for code readers (rather than code authors).
• adoxyz 6y ago
  Love it. It's not perfect, but hasn't failed me yet.
• kbd 6y ago
  It’s a boring language and I avoid it where I can help it. Its facilities for abstraction are too limited, everything is a loop, if err return, and so on. It’s just not a language I’d use by choice for anything.
  • bborud 6y ago
    What do you prefer?
    • kbd 6y ago
      Python for almost everything, but I’ve been getting into Elixir for web tier, and Nim is SO much more pleasant/featureful for a quick compiled language. I’d be happy to use any of the above for things but would feel “forced to” if I had to do anything in Go.
• nemo1618 6y ago
  I think Go is one of the most misunderstood languages. Many people want Go to be something that it isn't, and often for the wrong reasons. Generics are the most contentious issue, and people have been disparaging Go since day 1 for not supporting them. And yet, somehow we've spent the last 10 years writing all kinds of programs in Go, and the lack of generics has rarely been a showstopper. Go does have generics of course -- it just doesn't have user-defined generics. My hot take is that this is actually an area of the programming space that deserves more exploration. It feels like a Pareto phenomenon, where adding a small number of generic types and functions covers 80% of the usecases. And indeed, it seems that generic arrays/slices/maps/channels, plus a generic 'append' function, a generic 'range' keyword, etc. really are sufficient for the vast majority of programming tasks. These "reified" generics have significant advantages: for one, you can build deep compiler optimizations and tooling around them; and for two, perhaps more importantly, every Go developer is familiar with them. Reducing mental overhead when reading someone else's code is a big part of the Go philosophy. (Having a really high-quality standard library contributes to this as well, for obvious reasons.) People made similar arguments about operator overloading. It's true, operator overloading allows for more "expressive" code. It also allows people to write code that is much harder to read, harder to debug, and whose performance is harder to analyze. I think it could be cool to have an 'expressive {}' block, like Rust's 'unsafe {}', where overloading is allowed; but when I'm reading normal code, I don't want to have to worry about 'x + y' jumping away to some other piece of code. (As a side note, I see many people arguing for generics based on their desire to write map/filter/reduce functions in Go. My feeling is that map/filter/reduce (and other HOFs) are unlikely to become commonplace in Go code, even if generics are added. The reason is lambda syntax: even the simplest map or filter will require three lines of code (or one long one), including multiple type definitions and a return statement. It's not enough of an improvement over a 'for' loop to be worth it. If you could write 'xs.map(x => x*x)', it'd be another story, but that would require a much deeper language change.) Anyway, Go wasn't designed by idiots, which means you should apply Chesterton's Fence. If some aspects of the design seems wrong, or violates your sensibilities, your first instinct should be "perhaps this is optimizing for some usecase I haven't considered," or "perhaps this is targeting a particular niche that I'm not familiar with," rather than "this is clearly a mistake." The steelman argument, then, should be usually be of the form "It seems like Go is optimizing for X, but it falls short of X in significant ways," or "Go is targeting X, but doing so comprises value Y that I consider more important."
• cesarb 6y ago
  I haven't studied the language yet, but when I had the need to compile and run something written in it (IIRC, it was a checker for the Heartbleed vulnerability) I disliked it. With every other language, you checkout the code in any directory you want (as long as there are no spaces in the path), run either a language-specific tool or the traditional configure/make combo to compile and optionally install, and you're done. With Go, not only you had to put the code in a specific place in your home directory, but also every code written in Go you'd ever want to compile had to also be placed in that specific directory in a specific way, mixed with the code of other projects, instead of allowing you to place them separately in your personal projects directory hierarchy (which you already use with every other programming language).
  • Insanity 6y ago
    This is only true if you don't use go modules - so for recent projects you would not have this problem.
  • rowanseymour 6y ago
    All that has changed now thankfully, no more $GOPATH, put your go projects wherever you want, and there's a decent dependency system.
  • imadr 6y ago
    I think you can put your project in any directory you want with go modules
  • intortus 6y ago
    This is no longer the case. Now you instantiate a go module wherever you want by running “go mod init” (which just produces a trivial text file). Each module’s dependencies are now well encapsulated. There’s no longer a need for a messy globally shared GOPATH space.
• MichaelMoser123 6y ago
  When a struct implements an interface one has to keep guessing that it really does so (unlike Java, C++ there is nothing in the syntax of go that would show interface inheritance as a fact), and that really doesn't help the poor guys who have to read/understand/maintain some code. Why did they do that to a language that is based on interfaces?
  • rowanseymour 6y ago
    I often find it useful that implementing an interface is implicit. For example maybe I'm using a library that provides a struct A. I can make another struct B that mocks that functionality for testing, and then everywhere in my code use an interface C that encapsulates A and B. That wouldn't be possible if A had to explicitly declare that it implements C. If you want to explicitly declare that you implement an interface.. just put it in the comments, or it's common to see a line like this after a struct declaration: var _ C = (*A)(nil); It's a way of asserting that A satisfies C.
    • MichaelMoser123 6y ago
      - that's an optional convention, and it is not always followed - not easy to search for this pattern. You are right that go interfaces give you some flexibility with mocking, but i still think it's a questionable choice.
      • rowanseymour 6y ago
        If the problem is finding implementations of an interface, that's provided by the standard tooling. If you're using VSCode just right-click on an interface and select Find All Implementations.
        • MichaelMoser123 6y ago
          actually i was not using 'standard tooling'; was using vim with YouCompleteMe plugin for code completion. I couldn't get all the VSCode plugins to work well, somehow.
• speedgoose 6y ago
  Its a great programming language that is helpful to solve problems without wasting time. I really appreciate the simplicity, I think it totally makes sense at work where not everyone wants to deal with weird code. I think maintaining old golang code will not be a major problem in the future for example. The garbage collector make things a lot simpler too. The dependencies management is not great compared to npm/crates/rubygems/... but it's still better than the Java world and it exists and it's being used. I wish generics were already there, and I'm not a fan of the interface{} keyword. I'm also sick of the if err!=nil everywhere, I wish it could have a better error management like Haskell/Elm/Rust/... I use Rust in my latest personal projet and while I prefer Rust, it's a bit too complex quite often and I spend more time thinking about rust things than thinking about the problem I'm solving. This is not the case with Golang. It's not a fun programming language but it does most jobs very well.
  • ncmncm 6y ago
    Go is carefully designed to be adequate for the large majority of problems that don't need much, meant for use by the large majority of programmers who don't know or need much, whose attention is elsewhere. It is hard to get too deep into the weeds by accident. It builds fast, so programmers who code by successive approximation, making more or less random changes until something works can get there quickly. It runs pretty fast, so programs usually don't need much optimization attention. It competes in the same niche as Java, but lacks Java's complications that, more often than not, are purely obstacles. Before Go, before Java, there was Visual Basic. Visual Basic coders didn't go anywhere. Go acknowledges and welcomes them.
    • apta 6y ago
      golang is anemic in front of Java (the JVM, the language, and the ecosystem) and introduces its own set of gotchas. Once Java gets green threads (by means of Project Loom), golang will be an extremely difficult sell for anyone considering a new project.
      • pjmlp 6y ago
• rienbdj 6y ago
  I have no interest in Go because it is so limited, more limited than other languages that I have already moved beyond, such as C#. I am far more interested in cutting edge languages such as Rust (borrow checker) or Idris (dependent types) or even C++ 20 (template madness), since these will allow me to express things that I cannot express in other languages. What does Go bring to the table? Note that my perspective is of someone who works in a small team of experienced programmers, not a large organisation with more junior ones.
  • baq 6y ago
    > What does Go bring to the table? junior devs edit: it might sound like sarcasm, but i'm deadly serious.
  • jahaja 6y ago
    > What does Go bring to the table? A still maintainable code base 5 years along.
    • dfgdghdf 6y ago
      Is it really though? Go is not expressive enough to model your problem domain in a concise and coherent way, which leads to very large code-bases compared to other languages. Whilst each line is easy to understand in the small (because there is very little abstraction), it becomes extremely difficult to understand how the code works in the large.
      • mrmonkeyman 6y ago
        Your "problem domain" is a bunch of boring, easy, simplistic tax and/or logistics calculations and you know it.
      • baby 6y ago
        I’ve worked on both large rust and go codebases and I can’t agree with you.
    • apta 6y ago
• bitwize 6y ago
  Insert standard whinge about the lack of generics and the presence of garbage collection. Generally, a type system at least as strong as Hindley-Milner is table stakes for a new language in the 21st century; its omission from Go is a glaring fault that cannot be ignored. And the RAII pattern beats GC in 90% of cases; for the rest, reference counting may be employed. GC is obsolete, and better technologies to supersede it have been around since the 90s. That said, Go is fun to work in, and is great for constructing microservices that are truly "micro" in terms of small footprint of code and dependencies. Today, enterprise development shops that embrace the microservice pattern hew stickler-like to the "do one thing" bit of Unix philosophy, but slack off on the "do it well" bit, bringing in dozens of dependencies to serve, say, a list of employee names and IDs out of a table. Go's opinionated minimalism helps to mitigate this trend, but Go has also proven itself up to large-ish development tasks like Kubernetes as well. So that's Go -- capable, but not ideal. A worthy choice if you want to get something out there without fighting the borrow checker -- though you may wish to consider that time spent satisfying rustc now is more than paid for by maintenance time saved later.
• parksy 6y ago
  I haven't enough experience to talk about any things I don't like but my limited experience with it on a couple of small personal projects has been positive. All of this is subjective of course but these are my impressions: - It's fast - given I work with PHP for a living it's no fair comparison really, transposing a processor-intensive algorithm into Go is like lifting a veil. In one instance I think Go ended up being ~100 times faster, and that was without splitting computation across multiple cores. - Getting async multi-core concurrency feels smooth with golang, it's not that much of a stretch to transfer concepts from my experiences with async JavaScript / nodejs applications, only that it feels more natural dealing with flow control, race conditions, and shared resources in Go - JS tools have improved in recent years but being single threaded they only really approximate the experience of concurrency in Go and that can sometimes bite hard. - It's fairly intuitive to pick up and use. I used to be a big fan of C#'s syntax, and prior to working with PHP I learned development with C-style languages (including C/C++) so anything with a similar syntax feels natural to me. Golang feels to me like JavaScript got in bed with C# and made a baby. tl;dr: I'd definitely welcome the opportunity for some professional work using Go, and will certainly consider implementing some of my future projects with it to gain experience.
• ruffrey 6y ago
  I have used Go for a good 5 years when performance and maintainability are the necessary trade offs. It has the unique feature that all the code sorta looks the same style, across users. So the readability remains high during maintenance. I don’t think it is the best at building rest or graphql APIs, or for highly complex data centric systems. For that I would reach for a language with better generic programming support and many libraries available - like TypeScript.
• aczerepinski 6y ago
  Go is one of my favorite languages. I love that I can build things quickly with just the standard library (my personal website uses no external packages). There are other "sexier" languages that I sometimes enjoy even more (Elixir, Rust), but Go is rock solid, easy to use, and has never let me down in production.
• api 6y ago
  I love it, and consider it surprisingly and even “unreasonably” effective. My favorite feature is its simplicity. It imposes very little cognitive load, allowing you to spend more time thinking about the problem you are trying to solve and less time on language gymnastics. I am way “over” being impressed with that kind of cleverness. I am much more impressed with what a program does than with cleverness at the code level. Go mostly picks the right features and avoids those that just add complexity, and it mostly gets that right. It doesn’t get everything right. I am disappointed with channels and I do think it needs generics, though I hope the latter do not add much complexity and are not overused.
• fleventynine 6y ago
  I don't hate it, but I don't love it either. For the projects I've used it with, it works fine up until I need some complex data structures, then it falls apart into bunch of runtime-casting-infected code. Also, I don't find that it makes threading less error-prone than a language like Java. I've switched most of my personal projects over to Rust and so far I'm not looking back...
• mtalantikite 6y ago
  I’ve been using Go professionally for a while now, since before the first GopherCon, which I think was back in 2014. Coming from a mainly Ruby and JavaScript world, Go was a vast improvement over what I had been used to. The compiler was fast, the language was simple, and the concurrency patterns were nice. Writing backend HTTP APIs was pretty simple and I was happy. I’ve always loved playing with languages, so over the same period of time Rust was a language I’d often tinker with. It never really felt great for web stuff, but I kept going back to it to toy around with maybe a CLI here and there. Fast forward to the pandemic and I found myself with a lot more free time at home, coupled with a newly mature async story in Rust, and everything changed for me. The error handling due to algebraic types is phenomenal (particularly with the ‘anyhow’ and ‘thiserror’ crates), rust-analyzer in my emacs is awesome, type safe SQL with sqlx is amazing, cargo is great, compiler error messages are super clear, and the list goes on. I just started a new project with a client and the backend is written in Go, and honestly it’s a bit of a let down having to go back to it. It’s totally fine, it just doesn’t feel beautiful to me. Seeing empty interfaces with type casting makes me cringe (I mean it always has) and I’m really going to miss the Rust error handling. Thankfully a lot of this project I’m going to be able to use AWS lambda for and I’ll just use TypeScript since the front end team is using it there (no one is comfortable with Rust). tldr; Go is a simple language that will let a team get things done and it’s easy enough for any developer to onboard with it. But personally I wouldn’t reach for it ever again because of Rust (and even TypeScript).
• andy9775 6y ago
  It's fast, memory efficient and you're productive in it. It also follows write once, run anywhere without any dependencies. Downside is no generics but otherwise great.
• the_only_law 6y ago
  I'm impressed it took off. I remember looking at it when it was just a few years old and I was still kinda new to programming. At the time, it was just interesting because of novelty factors, and I kinda just wrote it off as a neat language that I should stop wasting my time with as it would never take of.
• chrislusf 6y ago
  It depends on your project. I used Go since 2011 on multiple projects, two of them are http://github.com/chrislusf/seaweedfs http://github.com/chrislusf/seaweedfs and http://github.com/chrislusf/gleam http://github.com/chrislusf/gleam. One is a distributed file system, the other is a distributed computation. * Refactoring is powerful ========== Nobody can design well upfront for a large project. Constant refactoring is need for large projects. Go is super good on this. * Generics is not ready yet. ========== The distributed computation project was re-written multiple times. I tried different approaches to address the generics problem. I even tried to make it work fairly well with LuaJIT, but still decide to change again due to the need to learn a different scripting language and losing the type checking.
• CyberRabbi 6y ago
  Hype ware. I still use and prefer c++ for numerous reasons
• burtonator 6y ago
  I'm going to come out and risk getting downvoted but I strongly dislike it. I haven't used it in a few years so maybe some of these things have been fixed. - Type system sucks - No decent package management system or dependency system - No generics - error handling is horrible. ... My fav lang right now is Typescript... You can do frontend stuff, backend stuff (with node). Great tool support, etc.
• kitd 6y ago
  The syntax has warts (eg duck typing hinders long-term maintenance and the package member operator should have been '::' or similar, both IMHO). But the simplicity of the toolchain and breadth of the standard library makes it the most pragmatic major language for backends.
• skyzyx 6y ago
  I learned JavaScript in 1999, PHP in 2003, Ruby in 2009, Python in 2015, and Golang in 2018. Modern PHP (despite its historical reputation) and Python are pretty much a toss-up to me (both have warts, both are a blend of functions and objects, and both can be written very well or very poorly). Ruby and JavaScript are more elegant (I like how everything is an object), but Ruby has historically been very slow and JS developers have forgotten how to program (see left-pad, or the dumpster fire of npm modules). In July 2018, I decided to go all-in on Golang. I like how fast it is, I like that it forces me to pay attention to my types. I wish that error handling felt less like yak shaving, but I understand the rationale. I write task-oriented servers/daemons, and CLI tools mostly, and it's great because it compiles down into a single binary with zero dependencies (which none of my other languages can claim), and it's extremely fast. It compiles easily for a variety of OS/Arch combinations, and as someone who can follow instructions to compile C/C++ code, dependency management is FAR easier than having to track down which "dev" versions of packages I need to install from whatever flavor of Linux or on macOS (via Homebrew). Overall, it's the best of many worlds for producing something that's easy for other people to consume. These days, I do a lot with AWS, Docker, Security, Terraform, etc. I'm also going back to my web roots a bit on the weekends and looking at building a GraphQL API on top of DGraph, and the tooling for Go is really good. Lots of static analysis and linting tools are available to help me write the best code I can, and teach me when I've done something poorly. My only big complaint is when I'm parsing JSON of which I don't know the shape. I end up with this nested mess of `map[string]interface{}` types that I have to sift and cast over. Even when I know the shape ahead of time, I still need to do the work to model it as a struct before I can work with it sanely. This is something that JS, PHP, Python, and Ruby all do with far more ease. I still write in multiple languages frequently, but Go has become my go-to for a lot of things over the past couple of years.
  • zeroc8 6y ago
    When you know the shape, you can just use https://mholt.github.io/json-to-go/ https://mholt.github.io/json-to-go/
• ed25519FUUU 6y ago
  It’s fun to read. I enjoy reading Go code and doing go code reviews. Much more so than my day to day languages (python and Java). I can usually understand everything happening in Go with a single pass without jumping around too much in the code.
• miki123211 6y ago
  Things I like about Go (in this order): * useful, not shiny. No new framework every year, just for the sake of it. An actually readable spec. Changes heavily thought through before being introduced. A programming language isn't a place to move fast and break things, as changes often cannot be undone. * Readable code. You can figure out what a piece of code does pretty easily. Even if you can't do so at first glance, you know where to look next. * Simplicity. I personally like having full understanding of things. This applies both to the language itself, as well as to the tools (go test, go mod, go generate etc). This is pretty subjective. * The formatter. As a screen reader user, aligning things with spaces so that they would form nice little tables is a hard task for me. I'm happy I don't have to do so. * Compiling programs as single, static binaries, assets included. Some small things I don't like (also in that order): * No try macro[1]. IMO try was a better solution than exceptions, and I found the arguments against it not that compelling. * Overrelliance on struct tags, which shouldn't exist at all IMO. I don't want to couple my business logic, storage and view layers. Options for i.e. JSON should be specifiable at call time. * No generics, or, even better, zig-like comptimes. They're simpler and more powerful, though they wouldn't probably neatly fit into go2. Overall, I'd give go about 8.5/10. [1] https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md https://github.com/golang/proposal/blob/master/design/32437-...
• aprdm 6y ago
  I played with Golang a little bit, it is very boring (and that is good), it is very pragmatic and performant. I didn't like dealing with JSON data but other than that.. it's great to get work done in a simple way if work == services/backendy kind of things. I would love to rewrite a lot of our python services in golang, both for the performance gains and to make the projects look more alike. Python gives way too much flexibility, is a pain to deploy and has too many frameworks for doing the same thing.
• TopInvestor 6y ago
  I started using Golang 8 years ago and introduced it to the company I worked for to build several web services from scratch. The reason it was adopted quickly was that building RESTful Web Services or gRPC Micro Services is relatively easy because all the libraries needed are native to the language. Of course I was building .net SOAP web services for years and knew the customers' needs. Another reason was the developers knew first hand how inflexible was configuring IIS with its web.config and the efforts needed to make it work. Then the adoption of Kubernetes was easy too because it was written on Golang. The next transition to GCP was natural too. Basically being backed from Google made all this technology development and adoption a natural and I'm glad that I made this choice early. Another reason I'm using Golang is that my recent project is mobile-GCP solution making possible to get information about 80mil/100GB US Property database in iOS App: https://topinvestor.app https://topinvestor.app One of the reason this functionality was made possible because I managed to create Gomobile embedded database in iOS which is much faster than SQLite or CoreData for my purpose - creating geodetic solution - tapping on the map is retuning lat/lng which are two numbers and creating just one number representation of location suitable for key-value datastore.
• dpc_pw 6y ago
  10? Huh. Feels like at least 50.
• draw_down 6y ago
  I find it tedious to work in, for a bunch of reasons. The docs suck. Packaging stuff keeps changing. The idea of “simplicity” that’s really just about ignoring complexity in one area so that other areas are forced to deal with it. The tools are crappy and unfriendly. The whole ecosystem just has this vibe of “ehh, deal with it <shrug>”. I worked on a big project this year which was my first time using golang seriously. I’d rather not use it again if I have a choice in the matter.
• GoOnThenDoTell 6y ago
  I wish it used Result and Option types. Checking if err != nil constantly feels off
• quickwen 6y ago
  I just want C(native performance) + Java(memory garbage collection) + Python(quick expression & battery include) + Erlang(massive concurrency), yes all in one, so take Go for simple!!!
• thespoonbends 6y ago
  After disliking it for 6-7 years, because it doesn't offer the amount of abstraction that others languages offer (Scala, Haskell, Java), Go has grown on me. I got too caught up in designing elaborate abstractions in those languages. I couldn't avoid it either, since other libraries would also use elaborate abstractions. With Go, I just write plain dull code, against a suite of good dull libraries. Ultimately I spend less time writing programs (typically internet services) in Go than other languages.
  • loopz 6y ago
    Without too many distracting abstractions I find it easier to evolve a codebase over time rather than overengineering at start.
• caditinpiscinam 6y ago
  When I see programmers talk about Go's simplicity, I think about the different things that simplicity can mean. For example: seqA = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20] seqB = [2, 4, 6, 7, 11, 12, 14, 16, 17, 19, 20] You could argue that seqA is simpler because it follows a regular pattern: the range of ints from 0 to 20, inclusive. Or you could argue that seqB is simpler because it contains fewer numbers. Go seems like seqB to me. It is simple in that it provides a limited set of features, but to me it ends up feeling fractured.
• apta 6y ago
  It's a very mediocre language with many poor design decisions. It only got traction because of the Google name behind it (it's predecessors designed at other companies were barely recognized). It's ok for writing small tools or simplistic web servers. For complex non-trivial applications, it is very poor at modeling, which introduces a lot of friction when dealing with larger code bases. Performance is adequate and nothing to brag about (it sacrifices throughput for latency) and compiling speed took a hit when they rewrote the compiler from C to golang. Linking times are quite abysmal for larger projects. Depending on what you want to do, there are superior alternatives. Java and C# are both better in almost every aspect (and keep closing the gap when it comes to low latency and small footprint), and Rust is also a potential viable option if you are running in a memory constrained environment.
• floppiplopp 6y ago
  I value the readability of go code. Compared to other languages it's fairly easy to understand what's going on. If used for it's purpose it's really efficient and powerful. Also, the community is pretty helpful and still enthusiastic after a decade.
• junon 6y ago
  Nonsense language. We've only had problems with it historically, both writing and deploying it. It's threading model sounds great in theory, but we've found that bounding most programs to one system thread improves performance in nearly all cases we've come across. The tooling and ecosystem are ridiculous, the dependency management is a nightmare, and the fact it's backed by an incredibly evil company doesn't help either. Further, any criticism of the language results in cult-like angry responses, as do most modern toy languages.
  • diehunde 6y ago
    How is Go a toy language?
• greyman 6y ago
  My experience with Go is positive. I transitioned to Go from Python (which we still use in some projects), but overall I started to prefer Go over python. What I like about Go: - explicit error handling, one is forced to write correct code and think how exactly the errors will be handled. I now prefer Go's approach over exceptions. - code is readable, I can look at the code of my coworker and very quickly see what exactly it does. - surprisingly, I found myself not missing OOP features - If project is compilable on localhost, it will be compilable on the server... this is easy to achieve and also deployment is straightforward. - it forces to write "stupidly simple" code. for example, it doesn't allow function parameters with default values. The consequence is, that I sometimes need to spend a little extra time on refactoring, but then have more readable code.
• tmaly 6y ago
  I learned it in 2014 and have been using it ever since. I think the backward compatibility has been the number one feature for me followed by the tooling and batteries included standard library. It is nice to be able to do most things without depending on a 3rd party library.
• oftenwrong 6y ago
  I won't re-hash the many great things about Go that have been said. Instead, I will explain some of the reasons why I continue to use Java (for now) instead of Go. Go is seen as one of the best alternatives to Java, and some see it as a better Java. It has won over many shops from Java. Therefore, I think these reasons are relevant to this question, and not just me doing the usual "my language of choice is better": 1. Tooling and library ecosystem of Java is still better. There are tools for pretty much everything, including high-quality commercial offerings. For example, IDEs, profilers, build systems, other languages that run on the same VM. Nearly every major SaaS I have ever integrated with has a Java SDK. 2. Weight of big players behind the ecosystem. Big companies all over the world are heavily invested in Java. Even Google is still more invested in Java than Go (internally, and in Android, especially). This makes Java an insanely safe choice for us small players. 3. The many, many warts and deficiencies of Java (and parts of the Java ecosystem) are well-known. Experienced developers, at least ones with good taste, know how to mitigate them without pain. For us, a language with fewer warts, like Golang, is therefore not as big of a selling point. It's like getting your hands dirty. When your hands are clean, you are reluctant to make them dirty. When your hands are already dirty, touching dirty things is not a big deal. 4. Golang is not the only language evolving. Rapid improvements to the language and JVM are already here, and more, bigger changes are planned (e.g. Loom, Valhalla) that will nullify some of Go's advantages.
• diehunde 6y ago
  Great language. Easy to learn, makes sense, good documentation, good tooling support, great core packages, fast, consistent, etc. The only thing I dislike is the CSP concurrency paradigm the community and language try to push. Every time you ask someone how to implement something more complex using locks or atomics, they just parrot the "share memory by communicating" lemma.
• HerbsMan 6y ago
  The amount of libraries/frameworks around AI and video games production is still small.
• caviv 6y ago
  I like it for the compiler. So easy to compile Windows application on Linux and vise versa - supporting all major OSes. If you had to go with C/C++ it becomes a much uglier solution and I hate Java.