1. 27
  1. 21

    My 2 cents. The other day, I wanted to test a new feature of Hugo that has not been released:


    Hugo doesnt have a CI, so the only option was building it myself. This might not sound like a big deal, but I am on Windows. On Windows, you typically have problems building projects as the developers many times dont even test on Windows. This will lead to compile and dependency errors.

    Hugo is a big project, the Zip file is 12 MB, so I was pretty sure I would have some trouble with this. But I didnt. I just followed the instruction:

    git clone git://github.com/gohugoio/hugo
    cd hugo
    go install

    and it took a while, but not a single error. I have built many projects with C, C++, C#, D, Nim and others over the years, and this is the first time I have had this experience with this large of a project. The closest to this I think is FFmpeg, but even with that you needed to install dependencies else something would be missing from the output or simply fail. I had a similar experience with Rust, where I needed a new build:


    except Rust just failed spectacularly, because it seems one of the dependency crates uses C on the backend, and has poor or no support for Windows:


    Go lets me get work done. I can focus on the code, where with other languages, I find myself getting distracted with the tooling or build process.

    1. 15

      Every time I write code in a language other than Go, I’m startled by how weak the tooling is. After writing all Go for about two years at a job, I switched to a place that has almost exclusively Python projects. To say that I miss go fmt is the king of all understatements. Also, after Go, I don’t see why every programming language doesn’t just come up with a native way of running tests a là go test. It’s weird to have a series of codebases where the command to execute their test suites is only the same because it’s placed behind a standardized make target.

      1. 16

        Maybe it’s just the ecosystems I play in, but it appears that language tooling is converging on this pattern though.


        • cargo fmt
        • cargo test


        • dotnet format
        • dotnet test


        • mix format
        • mix test
        1. 11

          Zig, too:

          • zig fmt
          • zig [build] test
          1. 2

            That’s awesome, thank you for your response! I know about prettier for Javascript (and to their credit, it really makes absolutely no sense to have a formalized code formatter for a language with no official interpreter). I also knew about cargo (slipped my mind), but am firmly outside the .NET/Elixir ecosystems, so glad to see that happening.

            1. 7

              There’s also pyfmt for python, and pytest. I think pytest came before go, though.

          2. 5

            Black (https://github.com/psf/black) is the Python equivalent of go fmt.

        2. 13

          I wouldn’t mind this. A Go, Rust, Java/TypeScript future sounds good to me.

          If you don’t want Rust’s up-front complexity, but still want some decent speed and clean code, I think Go is really a nice fit. While I vouch for Rust over Go any day, I think they are compatible. That is until a simpler subset of Rust begins to exist.

          1. 7

            Go has been my first-choice stack and mainstay lang since 2011. I think what the title suggests is quite likely, “for better or worse”. I always thought in the back of my head “it’s neatly lean, right-sized and quietly quite-brilliant for now, but wait til the EnterpriseDevelopers and Architects come bolting in and start adopting, they’ll turn it into another Java/.NET-like gross-growth in a matter of a few years”. Even without inheritance, Go’s certainly not immune to over-complications and over-abstractions. Interfaces, first-class funcs, channels and GC (cleanup for ‘free’ (to the dev), yay!) are enough for endless make-work — even though they’re also so very powerful and shouldn’t be missing (from sth. like Go, that is).

            Even so, all in all, I’m still on board with growth & adoption here because it’s better than sth. like Go sinking into obscurity. And it will improve / trim various nasties in many many overgrown and often outright horrendous legacy codebases & stacks. Some of the simplicity philosophy & resulting design intrinsics does transfer to the minds of the users, I have also observed that. For a while they’re fumbling for abstract factory builders and what not, but even to the most robotic ones it quickly seems so pointless that they drop it and these patterns fade. Others take root that aren’t always beneficial (make all the things chainable! because one can!) but also mostly benign and harmless in practice.

            Well in terms of “backend” it is absolutely on track with ongoing adoption in “enterprisey” contexts. Not explosive, but steady from my observation. (Though at the same time, more-polygot itself, over nearly-mono-stack, seems also on the rise.) For transitioning existing systems, looks to be the Java codebases way more so than the dotnet ones. I guess with the shiny .NET Core promise (of a truly natively cross-platform and (somewhat more) cloud/CICD-deployable .net) “MS-married” departments / shops / corps stay put for now.

            1. 3

              Interfaces, first-class funcs, channels and GC (cleanup for ‘free’ (to the dev), yay!) are enough for endless make-work

              Don’t forget reflect. My order or cleanup for Go projects: remove all use of reflect, then all humongous interface{}s. There is nothing harder than writing simple code.

              1. 2

                but wait til the EnterpriseDevelopers and Architects come bolting in and start adopting, they’ll turn it into another Java/.NET-like gross-growth in a matter of a few years

                Apparently the Kubernetes codebase was built like or grew into this, and now at least some of them are trying to reverse the process.

              2. 5

                Keep it simple and straightforward This encourages developers to write the simplest possible code with the least amount of cognitive overhead

                The complexity of the problem domain doesn’t go away. It migrates into boilerplatey code that’s hundreds of lines long instead, which… adds to cognitive overhead.

                It’s as if nobody before had thought “you know what, let’s make things simpler”. Of course they did, they just had different trade-offs, and it doesn’t help to state blankly that Go’s way is simpler without considering the cost of the type of simplicity that it values.

                Good code is obvious, avoids cleverness, obscure language features, twisted control flow, and indirections.

                Yes. Also, completely orthogonal to Go or any other programming language.

                Go requires to handle or return each error manually

                No it doesn’t, you can ignore everything.

                Cross-compilation Self-contained Deployment Vendoring Dependencies

                None of these are specific to Go.

                Fast Execution

                Compared to scripting languages. It’s consistently slower than compilers that generate code that actually runs fast.

                1. 3

                  Ok, I’ve bought into the marketing. I always have a long running project to use to teach me languages in depth. My current one is a spacecraft trajectory simulator written in C++ 1. As you can imagine it is compute intensive, and it has a text parsing component (which was, surprisingly, not horrible to write in c++). I’ll be porting it to go and doing further development all in go. I’m especially curious if go makes it easier for me to parallelize code.

                  1. 2

                    I think it would be good if Go were to become a enterprise programming language, because it’s absolutely unfit for teaching algorithms – which would mean that universities wouldn’t use it in their programming courses either, and perhaps consider to use something that teaches computational thinking instead of boilerplate-coding.

                    1. 7

                      Why is it unfit for teaching Algorithms?

                      1. 1

                        Thinking about it, “unfit” probably isn’t the best word, but let’s say if you want to have nice code, you’re going to have to write nice Go, which is it’s own discipline, seeing as Go has it’s own peculiar limitations (which might/often make sense from a specific engineering standpoint). And it’s this gap in method between Go and “regular imperative languages” that employ OO, Generics, … that would make Go a very unusual choice as a language for a (introductory) algorithms course.

                        1. 1

                          I’d question whether an algorithms computer science course should be teaching you OO and Generics, or whether that’s the way it’s been done up until now because a lot of Algorithms courses have been taught with Java.

                          I’d raise with you that many courses are taught using Python. Open ended type support, as such, but it’s so seamless that it hasn’t actually taught you anything about generics as much as you’ve ignored it at that point.

                          Regarding OO - the industry has broadened its notions of acceptable software and OO is no longer a must have. Hasn’t been for a while. Probably better taught in another course to be honest.

                          1. 2

                            To be clear, I’m not a fan of using Java either, and I don’t see a necessity to teach OO and Generics (as examples). In most cases, Python would be much more preferable, yes.

                            But you seem to have misunderstood my point: What you learn about OO and Generics (let’s generalize: Software Design, something that’s usually burdened onto Algorithms courses) in Java is more easily applicable to other languages – since Java ultimately isn’t that different – than you would if you were thought good Go design (for example the sort package).

                      2. 5

                        I feel like your response contradicts itself. You think it would be good for enterprise and that’s good because Universities wouldn’t teach it? That sounds bad to me.

                        1. 5

                          No, universities wouldn’t use it for algorithms classes, as they commonly use Java nowadays, which is what I care about.

                        2. [Comment removed by author]

                          1. 4

                            C is a boring imperative language.

                            1. [Comment removed by author]

                              1. 4


                                I feel like I missed the recent memo where everyone agreed to use “bespoke” instead of “custom”.

                                poor cross platform support

                                C builds and runs pretty much everywhere. It’s libraries which through things awry, but that’s true for most languages.

                                lack of libraries

                                This should say “lack of built-in libraries”.

                                1. -1

                                  I feel like I missed the recent memo where everyone agreed to use “bespoke” instead of “custom”.

                                  this. so much

                                  1. 1

                                    I went ahead and deleted my comment. Making fun of a word I chose to use isn’t very nice. Reminds me of reddit. Maybe its time to move on from here too.

                                    1. 1

                                      oh no! :( - was not intending to make fun of you. I was just agreeing with that because I feel like I’m seeing the word used a lot in the past 6-9months and wonder why…

                            2. 1

                              On the contrary, Go is great in an academic context.

                              I think the lack of generics is a weakness in using Go to teach students data structures and algorithms. Apart from that, I think Go has a good balance between being enough to explain various concepts and being practical enough to be useful for students if they end up in industry.

                              So, it will get there.

                              I’ve always found the disconnect between industry and the academy in computer science bizarre. Hundreds or thousands of algorithms are produced in these journals every year, but almost none of them are ever used in real software. It’s quite sad.

                              It is often useful to establish better bounds. But that doesn’t mean that these algorithms are practical, faster in practice (e.g. due to the size of N, cache hierarcy, etc.), etc. Also, 90% of real-world programming is pretty boring from the theoretical perspective (implementing forms, etc.). Most companies do not have the challenging problems that FANG et al. have. Estoric C may be a factor, but I don’t think it is the largest reason for this disconnect. Besides that, nowadays it’s usually sloppy Python ;).

                              1. 2

                                It’s a weakness for producing production library standard data structures/algorithms, but inconsequential I think, for learning about them. Lock the type to something sensible for the situation and I don’t think you lose anything worth keeping in a course about algorithms, especially not with the amount of sheer content covered in your average course.

                                1. 1

                                  I’m not sure about generics for learning. In my experience working with newer developers they can get lost in the abstractions, and they are particularly difficult to write code with. I suppose a basic LinkedList is nice. But even a HashMap<K, V> can get you in messy territory with how to deal with the hashability of types. Starting with just a string or int might be easier.

                                  I agree with you about the papers. Having any reference implementation at all has been a significant improvement - an area where Github helps. And I’ll take sloppy python :). It’s usually pretty easy to follow.

                            3. 0

                              Java is up there for “next enterprise programming language” candidates.

                              1. 5

                                Java is the enterprise language nowadays. Along with C#/.Net.