27 ms·

Go is boring, and that’s fantastic

250 points by rauhl 6y ago

pif 6y ago
Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. https://www.angelo.edu/faculty/kboudrea/cheap/cheap3_murphy.htm https://www.angelo.edu/faculty/kboudrea/cheap/cheap3_murphy....
- pdog 6y ago
  Counterargument: build systems that any idiot can run, because eventually an idiot will be running it.
- artsyca 6y ago
  Murphy's eighth law is contrary to every success metric. People tend to say "..but we're doing well!" and that's supposed to be a bad sign.
- moreaccountspls 6y ago
  You think everyone building tools like k8s, terraform, etc. are fools? That's a pretty myopic worldview.
  - erik_seaberg 6y ago
    Terraform is I/O bound on cloud provisioning APIs (its CPU performance doesn't matter), and its complex object models need to be extensible. Python would have been a better choice.
    - jen20 6y ago
      As a former maintainer of Terraform, I 100% assure you that Python would have in no way been a better choice. While Terraform is I/O bound to some degree, it has a large degree of concurrency - something quite miserable to do in Python. Terraform does not take full advantage of even the type system available in Go, but a dynamic language would make things even worse. I do not think Go is the ideal language for programs like Terraform, but having spent many thousands of hours in that codebase now, the answer is stronger types (likely Rust), not fewer.
      - erik_seaberg 6y ago
        I'm currently generating bloated JSON templates because writing any kind of non-Go plugin looked like a painful ordeal.
deleted 6y ago
[deleted]
ladyanita22 6y ago
From what I'm reading, I fail to see how Go is faster than other languages. It actually seems pretty bad. In the article, it is said to match Java. In the Benchmark Game, it is certainly not among the fastest.
- corty 6y ago
  Go is on average about as fast or as slow as Java, with different strong and weak points. But there is definitely a lot if optimisation potential, the compiler is only "so so" in that regard.
- throw_m239339 6y ago
  In my experience Go uses less RAM than Java, but perhaps it has absolutely nothing to do with the language but more with how libraries are written. I rarely see fixed sized arrays used in Java for instance. It's common in Go. When it comes to speed, on a running server, Go isn't faster at all at scale, and DB drivers tend to be less mature for certain RDBMS.
- didip 6y ago
  In my experience, Go gives a perception of faster than Java because the GC pause on average is really quick compared to a decently tuned G1 GC.
  - erik_seaberg 6y ago
    Go's GC has always had pretty low throughput compared to a JVM, but with value types (which Java doesn't have yet) it can be faster if you manage to keep everything on the stack.
cmrdporcupine 6y ago
Enums, immutables, and generics aren't good because they're exciting. They're good because they give us expressive tools to write descriptive, type safe systems that manage state better. I don't like "modern" systems because I have a fetish for novelty. There's nothing novel about these concepts, they've been around since the 60s and 70s. I like these tools because they improve my ability to reason about the code, but more importantly they let the compiler and other static analysis tools reason about my code. I am getting old and lazy. I want the compiler to do more for me, not less. What I see is a situation where Go is gaining traction from two communities: a) people who attempted to build large systems at scale in dynamic late bound languages like Python and Ruby and NodeJS etc, and hit the wall from a performance and maintainability POV. I could have warned you... b) people who came from the Java world and got frustrated with the language and tooling there People coming from a) especially but also b) to some degree will be perfectly comfortable with Go missing the nicer aspects of modern static typed languages because they never had them in the first place. As for... "Go doesn’t have a virtual machine or an LLVM-based compiler." How is this any kind of pro or con? It's just an implementation detail.
- akavi 6y ago
  Exactly. I don't want sum types becuase they're exciting, I want them because they're the simplest way to communicate to the compiler that "my data can either be this or this and nothing else", so I don't blow off my foot by accidentally making it that. When I was younger and less jaded, it actually was fun and exciting thinking up ways to hack around language limitations like that. Now it's just frustrating.
  - deleted 6y ago
    [deleted]
  - frankie_t 6y ago
    That actually surprises me a lot. I've seen plenty of critique about lacking generics and exceptions, while haven't seen much complaint about ADTs. From my rather dilettante point of view they are neither too complex for "philosophy of simplicity", nor they add much of compile time. It seems to me they even can be implemented as a syntactic sugar on top of type casts. I certainly cannot see them being more complex than generics.
dmitshur 6y ago
I’ve been very happily using Go the last 7 years (disclaimer, I’m employed to work on Go as of 2 years ago), some random personal thoughts. It’s interesting how a language can be boring and so fun to use at the same time. I guess I don’t want excitement at the language layer because there’s plenty of opportunity for it in other layers. A boring language to me means there’s usually roughly one way of doing something, so you just need to write up that one thing and move on to the next part of what you’re building, knowing the past part is finished. Once something works well and has a good API, I almost never want to come back to it and rewrite it with a different set of language features that I happen to learn. The process of writing Go is fun to me because starting with an empty Go program to do a new task is always a refreshing experience, it’s easy to reuse any past functionality that you’ve already created (or found) and you can focus on the new task. In contrast, when I was primarily using C++, starting a new codebase wasn’t pleasant because of all the housekeeping and boilerplate (like defining a uint16 type in a platform-agnostic way) I needed to copy/paste just to have a reasonable starting point. Also, the feeling of gofmt/goimports running on save and formatting the code on save is a huge part of what makes it fun (fortunately, code formatters are much more commonplace now; I wouldn’t want to go back to not having them).
- gcatalfamo 6y ago
  Since you work with go I have a question. I learned it superficially but I’d like to get more fluent with it. Which resource would you suggest?
  - threeaccents 6y ago
    If you have built a program in any other language I would say rewrite that program in GO. The benefit being you already solved the the domain logic of the program the only thing you need to focus on is writing/learning GO. If this is your first programming language or attempt to learn to program I would say to just pick a small but simple app/program and just go ahead and build it. Don't spend too much time on reading articles or video tutorials just get your hands dirty as soon as possible.
  - dmitshur 6y ago
untog 6y ago
Obviously this is all a matter of opinion but I don't consider a lack of exceptions, enumerations and generics "boring", I just consider them to be missing features. Certainly there's an argument to be made for simpler languages being better (maybe we should all be writing in Assembly?) but I'm personally not convinced.
- isp-localhost 6y ago
  I hear these sorts of arguments often, as someone who likes both Go and C I do have some responses: I would hardly call exceptions in C++ a "feature" but more of a "liability." Enumerated types (probably referring to sum types here) have trade offs that are not necessarily clear from simply reading the code. Generics often lead to code which is (IMO) difficult to follow, debug, and reason about. The point about assembly is jest? Or dishonest? I would argue that C, C++, Go, Haskell, etc etc are "simpler" than assembly, if they weren't we probably would be writing assembly, and I suppose following that logic maybe we'd be hand constructing opcodes with a two key keyboard.
grey-area 6y ago
Being boring really is what I love most about Go. It doesn't change much and there is a culture of simplicity, so it's quick to onboard new devs and there isn't a lot to get your head around. That also makes it good for building large projects, as the complexity is in the domain and the application, not clever uses of the language itself. I almost wish they'd make it more boring and take a few things out, but it's probably too late now to change the language much and people would complain vociferously. Things I never use and wish it didn't have: panic, goto, labels, struct tags, executable comments, even arrays. The only things I'd like to see improved significantly are enums, errors, and user-space generic collections (coming soon!).
- cy_hauser 6y ago
  > generic collections (coming soon!) You and I must experience time differently. I read a couple days ago that the end of 2022 would be the earliest they might appear but probably further out than that.
  - leetrout 6y ago
    > the earliest that generics could be added to Go would be the Go 1.17 release, scheduled for August 2021 https://blog.golang.org/generics-next-step https://blog.golang.org/generics-next-step
  - grey-area 6y ago
    I've been using it about 8 years at work, and don't mind if they take another year, it'll take a while to work into large code bases anyway. Personally I've felt generics as a lack but not a huge unfillable hole, and prefer language stability to churn, so am completely fine with it taking time to add large features. I'm pleased with the evolution of the generics proposal so far - it's getting simpler and more transparent. I really wish in their mooted Go 2 they could just remove some features, as listed above, rather than add some. Perhaps everyone prefers a slightly different subset of the language though so that isn't really possible.
zaphar 6y ago
I wonder what the actual statistics on bridge building are. Are they really typically done on time and on budget? How many times do the drawings or engineering specifications for a specific bridge have to change while getting built to adapt to new information? We trot out this particular analogy all the time in software engineering and I can't remember ever seeing any real data to back up the assertions.
- corty 6y ago
  From having lunch with guys from the mechanical engineering department (they were right next door at uni) my anecdotal second-hand wisdom is: Most larger engineering projects are as broken, tedious, expensive and unpredictable as most software projects. You will always find unsteady ground that nobody told you about, new last-minute requirements, shitty subcontractors making a mess and substandard parts that happened to be cheapest on the tender. From what I've heard, around 2 in 3 projects are over budget or over time in a significant way because something was massively screwed up somewhere and needed to be hotfixed, patched, rebuilt or -my favourite- reevaluated to be statically sound without structural changes. I think the common software engineering myth about "real engineering" being somehow better and something one should aspire to is just really a myth.
jrockway 6y ago
> Go doesn’t have ... an LLVM-based compiler. https://github.com/tinygo-org/tinygo https://github.com/tinygo-org/tinygo
- todotask 6y ago
  Yes, it's not part of Go standard library https://tinygo.org/faq/why-a-new-compiler/ https://tinygo.org/faq/why-a-new-compiler/
corty 6y ago
While the article overall might not be totally wrong, at least two details are dead wrong. Go DOES have a virtual machine, thats what gives you all the lightweight threads and garbage collection. You may call it "runtime", but there is no difference between a heavyweight runtime or a lightweight VM. And go DOES have exceptions, thats what panic does. The are just used less frequently than in other languages (e.g. Java, where even the happy path may contain exceptions, e.g. in Swing).
- pjmlp 6y ago
  So C has a VM apparently, https://en.cppreference.com/w/c/thread https://en.cppreference.com/w/c/thread https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc https://clang.llvm.org/docs/Block-ABI-Apple.html https://clang.llvm.org/docs/Block-ABI-Apple.html
- efficax 6y ago
  A "runtime" is not a virtual machine anymore than the standard c library is a virtual machine... it's clear what virtual machine means in this context: an abstraction layer between machine code and program code that translates one to the other at runtime.
  - corty 6y ago
    By that argument a x86-VM running on x86 is not a VM because there is no code translation in between.
    - lostmsu 6y ago
      Words can have different meanings in different contexts.
      - corty 6y ago
        Yes, but here they don't. A VM is a non-physical machine that executes instructions. Nothing more, nothing less. And yes, this means that even a library might be considered a VM. I don't see why people get so wound up about that.
melvinroest 6y ago
> But the people who design and build bridges, they're great at it. Bridges get built on time, on budget, and last for dozens, hundreds, even thousands of years. Bridge building is, if you think about it, kind of awesome. And bridges are such a common occurrence that they’re also incredibly boring. No one is amazed when a bridge works correctly, and everyone is kind of amazed when software does. Emphasis mine was added by me. Sorry, source needed. You're a software developer, not a bridge builder. Yes, bridges in my country seem to work, fair enough. But I have the faintest clue if the design/building process really is going that smoothly. To write this down as a fact to build your argument is IMO a pretty big assumption.
- buster 6y ago
  Especially if you consider the state in which some infrastructure is around the world. I'm impressed to see the occasional aqueduct from 2000 years ago in Europe, but i also see the occasional modern bridge collapsing in the same country (https://www.theguardian.com/cities/2019/feb/26/what-caused-the-genoa-morandi-bridge-collapse-and-the-end-of-an-italian-national-myth https://www.theguardian.com/cities/2019/feb/26/what-caused-t...). From what I've heard and seen, infrastructure in the US (roads, bridges) isn't exactly the example for "build once, use for thousands of years". And that's not even considering how many of those road or bridge building projects really are in time and budget.
- mplanchard 6y ago
  I agree with this. I live in Austin, TX, and we’ve constantly got five to ten big construction projects going, both in the private sector (new buildings) and the public sector (usually roads and other transportation infrastructure). It’s certainly possible I just haven’t been paying good enough attention, but it seems like the vast majority of such projects that have been completed over the last six years have been over budget and behind schedule.
- encloser 6y ago
  I am a US citizen with a bunch of civil engineer friends who are Professional Engineers (the capital letter, licensed kind). For a good number of years I had a roommate whose job was literally designing bridges. We've talked about this very comparison. Bridge building is not as boring as this author thinks. It can be pretty stressful. There are a few factors that make bridges very reliable (but not perfect) in the US. A real engineer can probably describe this far better than I can. 1) Physics and material science are pretty well known quantities. There is innovation and new materials come to market, but by the time they are approved to be used in real bridges their qualities are fairly well known and tested. They have solid evidence of the capabilities of a material or part. (Tensile strength of an item under various environmental conditions, for example). 2) Standards & Very Firm Requirements (Where waterfall works!) They have a set of strict approved industry standards to rely upon. Not the "industry standard by convention" kind that you see around IT a lot, but the "tested, reviewed, approved, published by a standards body" kind. When a civil engineer is assigned to build a specific bridge they reference these standards that tell them "given this type of ground do this", "given this length of span do that". They know the lengths and widths, they check the traffic patterns, they know the desired weight limits. Challenges do come up, yet they have fewer unknown unknowns. Something changed from their expectations, maybe the ground is different than expected, but they still have standards that guide them in what to do in those cases. 3) Reviews, reviews, reviews. Other Professional Engineers have to sign off on the work of the initial designer(s). Deep reviews. Not what typically passes for software architecture and code reviews I've seen. 4) Legal responsibility. Professional Engineers have an amount of personal accountability at stake because real lives are at stake if something fails. 5) "User" common sense and intuition Nobody builds a 100,000 ton vehicle and then tries to drive it over a bridge. Most any human that thought about doing this can probably reason that doing so would break the bridge. In my experience software users have no idea that trying to push a 1TB file into a system that was designed to only handle 1MB files will cause it to fail. They often have no idea when their data volume increases. "I'm doing the same thing I did last month!" All that and more, yet bridges still go over budget and over time and fail and people die.
empath75 6y ago
IMO, the thing that makes go good, from an enterprise point of view, is that you can take a team of mediocre coders who have never used it before, and deliver working code quickly. It might be ugly, it might be dumb, but it'll get the job done, and will generally be easier to maintain than python or ruby in the long run and with good performance. I think a few things contribute to that: 1) Relatively few language primitives -- it takes like a day to learn 90% of the keywords you'll be using day to day. 2) Transparency -- it's easy to look at any code base, and track down all the relevant code, even without an ide. Compared to a language like ruby, there's not a lot of 'magic' happening. 3) Conciseness. Unlike a lot of statically typed languages -- go code isn't verbose. It's statically typed, but the inference works well enough that you're very rarely having to use type hints all over the place -- Java has started to be more like this, but back when go started, it was a breath of fresh air. 4) Kubernetes. If you want to build on top of k8s, go is pretty much the only game in town. It just makes everything eaaier. Other languages have k8s support, but any language other than go will have more friction. 5) Go channels and concurrency -- I actually don't think this is that important, but knowing that it's available if you have that kind of performance demand is nice.
- pjmlp 6y ago
  The irony is that in 2020 from Go's point of view, Java is a PhD level language.
  - courtf 6y ago
    What does it mean to be a "PhD level language?"
    - pjmlp 6y ago
      It means a language with support for enumerations, generics, overloading, pattern matching, annotations, compiler plugins, access levels,....
      - deleted 6y ago
        [deleted]
sandGorgon 6y ago
One of the questions that i have always wondered about is how do financial companies work with math libraries in any language other python - which not only has the entire math/statistical software mindshare..but pandas/scipy + BLAS/LAPACK is optimised to its gills in Fortran. For e.g. Monzo engineers have tweeted that they had to create an internal math library - https://twitter.com/_liclac/status/1264142576908722178 https://twitter.com/_liclac/status/1264142576908722178 Once you bring Pandas, Scipy, LAPACK/BLAS, Numba/Cython into play...then i bet these benchmarks look a lot different.
stephc_int13 6y ago
>There are a few things that we have learned in the last 60 years about writing programs where there is pretty much universal agreement: >We agree that it's better to find problems earlier rather than later. Agreed. >We agree that people are awful at managing memory in programs. Nope, manual memory management can be done properly and this is not rocket science. >We agree that code reviews help find bugs. Sure, but this is not the only way and not always the most efficient. >We agree that on any project that requires more than one person, communication costs dominate. Nope, this is a blatant over-generalization.
- zeveb 6y ago
  > Nope, manual memory management can be done properly and this is not rocket science. Outside of NASA (often, literally rocket science!), where has manual memory management ever been done properly? I don't think that it ever has. For that matter, I would be unsurprised if even NASA had manual memory management failures.
  - cyb_ 6y ago
    Even NASA apparently has rules against dynamic memory management in critical systems. > 3: Do not use dynamic memory allocation after initialization. https://sdtimes.com/nasas-10-rules-developing-safety-critical-code/ https://sdtimes.com/nasas-10-rules-developing-safety-critica... https://news.ycombinator.com/item?id=4339999 https://news.ycombinator.com/item?id=4339999
    - blibble 6y ago
      high performance trading systems use the same approach (of course: failure is less catastophic than it would be for NASA!)
  - defnotashton2 6y ago
    Video game industry?
    - 6y ago
deleted 6y ago
[deleted]
jherdman 6y ago
Boring technology that does great things has been a huge part of my career for the past eight years at Precision Nutrition. With that said, the following opinions are mine and mine alone. Here are some boring choices we made that paid dividends: 1. Postgres. It does what it does, it's stable, it's reliable, and continues to improve as time goes on. 2. Ember. It's by far the most stable front end framework going. It's made our job easy in uncountable numbers of ways. 3. PostCSS. Write plain CSS, use modern features, remove plugins as browser support grows. A few years ago I'd have said Rails was a boring technology we chose too. These days I'd say it's a bit of a thorn. It's clear that some of the magical choices made make long term maintainability challenging, as are some of the performance characteristics. A few of the libraries used by the community have bitten us hard too insofar that they're either a maintenance nightmare, poorly maintained, or exceptionally difficult to migrate away from (e.g. CanCanCan, Active Model Serializers). These days I'm playing with Elixir, which is also boring but allows you to do exciting things. I especially appreciate ExUnit having come from the RSpec world — assert, refute, end of story.
- sirtaj 6y ago
  Not disagreeing with your general point, but I see Postgres as far from a boring choice. It is constantly evolving in inventive ways.
- brendanmc6 6y ago
  I'm a frontend dev and amateur solo founder interested in tools that empower me to build more with less effort. Should I finally bite the bullet and learn Postgres/SQL? I have the (ill-informed) impression that it's better suited for large and complex systems whereas I'm mostly building SaaS and simple e-commerce apps. Aren't there usually full-time SREs focused on managing and maintaining SQL databases? I can get really really far, really quick with Cloud Firestore (for free at my scale), and stay focused on my frontend. But as complexity grows and requirements change I can sometimes find myself in sticky situations-- mostly because there are no tools for schema migration in Firestore. But on the other hand with Firestore and similar noSQL products I can get scaleability, security, speed, stability and a lot more all out of the box. Curious to hear your input.
konart 6y ago
>You don't have permission to access "http://www.capitalone.com/tech/software-engineering/go-is-boring/" http://www.capitalone.com/tech/software-engineering/go-is-bo... on this server. oh...
tapirl 6y ago
> Go doesn’t have immutables. Declared functions in Go are immutables.
LandR 6y ago
I sometimes wonder if Go is a long running by joke by Google. Like someone internal at Google said people will use and adopt en masse anything they make, regardless of how good it is. Someone else said no way, a bet was made, and Golang was released. Ignoring 20-30 years of programming languge theory advancements. Yet everyone laps it up. And here we are today. I'm sure someone at Google is laughing. I find Go completely tedious and inelegant to work with, its too verbose and i think verbosity hides intention and expressiveness.
- defnotashton2 6y ago
  What are you comparing it to and would prefer?
  - LandR 6y ago
    Languages I would prefer to work in than Go: Clojure C# F# Rust Scala Ruby Kotlin
    - leetrout 6y ago
      Are you working in those languages now and do you have a remote build environment or are you building on your laptop? Scala and Rust's build times get very noticeable very quick IME.
      - LandR 6y ago
        Ive worked places where compiling the C# solution on my dev machine took 30-40 mins and the build server took an hour plus... I haven't seen anything else ever be that bad.
        leetrout 6y ago
        The scala shop I was at Last year was 45+ mins on a 2019 mbp with 16gb ram. You had to turn off IntelliJ so you wouldn’t run out of ram.
    - 6y ago
drewcoo 6y ago
Coding Go is like an old bridge. Because almost all Go code will be removed or replaced in short order. And only a very few survivors will still exist years from now to feed the confirmation bias of "history." That analogy should go the way of most old bridges.
k_bx 6y ago
Go does have subtyping (unlike Rust and Haskell), which makes type system needlessly more complicated and type inference harder.
- atombender 6y ago
  Go doesn't have subtyping, only implicit coercions. Not the same thing.
  - k_bx 6y ago
    Right, thank you for this correction! I've just spent some more time with Go, looks like I was wrong and it has something closer to Type Classes (or Traits), but not subtyping. // Too bad editing is not available anymore
- entha_saava 6y ago
  Type deduction from right hand side expression is enough and that was stated in FAQ that they didn't want HM inference. Edit: well not in FAQ but somewhere else. IIRC Rob Pike.
  - k_bx 6y ago
    Turns out I was wrong (and corrected thankfully), Go does not have subtyping, which is good news (at least it makes the language way more tolerable for me).
throw_m239339 6y ago
Go is like C. AKA roll your own unsafe type system at runtime with void pointers (or interface {} in Go). This isn't acceptable for a language released 10 years ago. On one hand you have a rigid type system very limited in terms of polymorphism, on the other hand with interface {} anything goes, even creating Adhoc functions at runtime. Go should have taken cues from ADA and how it implements generics. There is enough polymorphism to solve most cases where generics are useful, but also enough limitations so that a codebase isn't cluttered with `Type A<Type B<C,D,Type E<F,G,H>>>` horrors everywhere.
carapace 6y ago
If you were trying to choose between Go, D, Nim, and Zig for a general-purpose compiled language, what are the criteria for differentiating and what are the pros and cons of these languages? Are there other languages that should be included in this list? (Common Lisp?) (FWIW, chief on my list of criteria is the "debug story": what kind of hell am I in when things inevitably go wrong?)
- jaco8 6y ago
  After looking through the lot we settled on Nim. Give it a try , it will grow on you.
- blandflakes 6y ago
  I often try to jam OCaml in that list based on my own interests, and people also suggest Crystal a lot. To me Nim is maybe the most interesting to the widest audience.
- kazinator 6y ago
  To make things interesting, can we add the following choice: wading chin-deep over a half-mile wide tract of land flooded with raw sewage, to reach a C compiler.
  - carapace 6y ago
    I'm coming around to C-with-good-tools as a decent option. It's everywhere and it's been studied and meta-programmed to death and back again.
rchaves 6y ago
> Among compiled languages, garbage collection is rare ?????? > Rust's borrow checker is a fascinating way to get high performance and memory management, but it effectively turns the developer into the garbage collector, and that can be hard to use correctly Isn’t the whole point of rust that you cannot get memory management incorrectly because compiler guides you? > all Go code is formatted the way that go fmt says code should be formatted. just like rustfmt, elm-format, prettier and I hope most modern or future languages I agree with his main idea, I also like the idea of a boring language, but then his arguments misses the point completely, talking about benchmarks and such. He should talk about why having no exceptions can be a good thing, or having no generics. Having a very small API surface and stable language is one of the reasons I love Elm as well, nobody is able to do too smart abstractions with monads and such, it’s about code, readability, explicit better then implicit, etc, nothing to do with garbage collecting, performance, blablabla
- leetrout 6y ago
  I worked at a shop where there was some Ruby code and autoformatting was argued against from one of the senior tech leads because "[ruby] wasn't designed for an autoformatter. go was built that way" Absolutely blew my mind. I love go fmt, prettier, black, etc and cannot understand why people still love to argue over styling at this point. I get that he was saying the formatter ships with Go but I don't subscribe to the idea that you can't use an opinionated formatter because the language authors didn't make one.
  - recursive 6y ago
    I can kind of understand it. If it's a first class part of the language, then it's never going to get painted into an ugly corner. As a nearly related example, the LESS css pre-processor language was developed prior to `calc()` expressions. As a result, the LESS language parses arithmetic expressions. So `calc(10em + 10px)` compiles to `calc(20em)`. So in order to do `calc()` expressions, you have to use nasty hacks like `calc(10em ~"+" 10px)`. If LESS "shipped" with CSS, this wouldn't have happened.
    - 6y ago
hyperman1 6y ago
It strikes me how this gives a value proposition for go that is very similar to COBOL: Easy structure, predictable to build and run, minimize individual coding style differences,.... Not necesarrily disparaging for either lanfuage, as COBOL, boring as it is, has brought tremendous value in large scale software engineering. There are of course big differences too, like i18n, variable width strings, ... But if you give COBOL a c-style syntax,some dynamic size data structures, and you squint a bit, you end up quite close to Go
ed25519FUUU 6y ago
My favorite thing about Go is that I can jump into any codebase, written by any developer, and the mental load required to unwrap their logic is very low. The "stylistic opportunity" for other languages is such that I can usually tell which developer on the team wrote what just at a glance. Not so with Go. It's all the same bland but beautiful gray. Something to be said about languages that help external people understand them, as opposed to languages developed to improve developer satisfaction.
- didip 6y ago
  I agree with this opinion, code review burden in Go is so little.
exabrial 6y ago
...functions returning multiple parameters, confusing operators that are different 'just because', types on the right hand side instead of the left 'just because', I don't think GoLang is solving as many problems as it creates. It's different because being different is cool, not because it solves any sort of practical problems. If I were going to go learn some strange non-C-like-outer-worldly-syntax, I think your effort is best spent learning Rust, which is way faster, offers some strong failure guarantees, and fills a lot of use cases from embedded systems to WASM.
__tg__ 6y ago
Re. the bridge analogy in the article: we had a bridge being built behind our building at work and they had announced the opening date a year in advance. Sure, when the date came the bridge was opened exactly on time. I was walking with my colleague across it and asked him, "How come we can't ever predict when we'll be done?". His answer was deeply insightful: "They build the same bridge every time while we build a different one".
nikki93 6y ago
The manual memory management thing -- like needing GC -- feels like a false dichotomy. Most of these languages that have GC need you to "manually" manage resource lifetimes anyways for a lot of resources: files, network connections. If you're making a UI, you think about when components are mounted and unmounted. The logic for all this is domain logic and part of the code for your program. Memory is just one such resource, and I think there should be more acknowledgement of it as such by languages, instead of just piling it up and kicking a "GC cycle" to clean it up whenever, leading to pauses in interactive programs and whatnot (Go's GC, and Go in general, do not perform well under WASM in my experience). In Go you have to "manually" defer a file.Close() call -- vs. the destructor getting automatically called in C++ (it even gets automatically called when a containing object is destructed, if it's a member, and so on). Go's version doesn't seem very "automatic" to me. The simplicity of Go actually hides a lot of runtime complexity that is happening: the GC, map lookups, scheduling of goroutines and so on. Which you have to understand and then ultimately learn how to tune from a distance (because you don't have direct control) for a lot of applications where it matters. For server applications (where the hardware is under your control) and also CLI tools (which can just run, only allocate memory, then just exit), this matters less. If your code is running on user's devices as an interactive application, it feels to me like how it performs on and uses their actual hardware is part of your responsibility as the developer, and some things about Go make that harder to do. Like you have to think about the GC and try to avoid it ("from a distance") if you run into that (which you do quickly in WASM, and which eg. Gio tries to explicitly design around, and so on). I want to see languages that care about simplicity and also include such deterministic resource management as part of their design and offering.
- coder543 6y ago
  > In Go you have to "manually" defer a file.Close() call -- vs. the destructor getting automatically called in C++ (it even gets automatically called when a containing object is destructed, if it's a member, and so on). Go's version doesn't seem very "automatic" to me. To clarify this one point, Go allows you to attach a destructor (finalizer) to an object, but since the language is garbage collected, there’s no guarantee of when the destructor will be called, if ever, since disabling the garbage collector is entirely possible, even if not advisable. The File object will Close the file when the Finalizer runs, since the standard library attaches a finalizer to it, but you should defer the Close to deterministically ensure that the file is closed when you expect it to be closed, and to free that OS resource of a file handle as soon as possible, since some OSes limit how many you can have at a given time. Finalizers also won’t be run when the program exits, which is fine for most things, but you’ll want to have ensured any buffers were flushed before then, and defer can guarantee that. Languages like Rust and C++ have deterministic destruction at the end of a given scope thanks to RAII, so it makes sense for them to lean more heavily on destructors there. Java File*Stream objects should have “close()” called on them, from what I’m seeing on a Google search, so this doesn’t seem to be a surprising pattern for a garbage collected language. I know in Python you’re encouraged to use a “with” block to ensure that file objects get closed. https://golang.org/pkg/runtime/#SetFinalizer https://golang.org/pkg/runtime/#SetFinalizer
charlesdaniels 6y ago
I think a lot of the commenters are missing the point. Golang is less expressive than other languages, like Rust or Haskell. You can't create fancy custom types and things like that. Of course there are drawbacks. The benefit however, is that it's much harder to write "clever" code, which translates into being harder to write unmaintainable code. If you know Go, you can sit down at nearly any Go codebase and know what's going on pretty easily. That certainly isn't the case for C or C++, and probably others (other people have told me this is true of Rust, but I have not used it, so I will not claim that). Golang is not the fastest, or the most expressive, or whatever else. But it's got enough expressiveness to not be painful for most use cases (slices, maps, and structs cover a lot of ground). It's fast enough for most use cases (faster than most scripting languages). In my opinion, Golang has a very good ratio of (effort required to learn) / (utility of learning). I have no doubt that Haskell is extremely powerful... if you can learn how to use it. I wouldn't be signing up to write a new OS kernel in Go, but for a userland program that doesn't have hard-RT requirements? I think Go strikes a better balance compared to C, C++, Java, Python, and others.
- thatswrong0 6y ago
  > The benefit however, is that it's much harder to write "clever" code, which translates into being harder to write unmaintainable code. If you know Go, you can sit down at nearly any Go codebase and know what's going on pretty easily. I don't think this necessarily follows. I don't think "clever"ness is what makes code unmaintainable. You can still create a tangled mess in Go just as easily as other, more expressive languages. In fact, I think it's more likely in Go simply because you _have_ to write more code in Go. More code is more maintenance. Go encourages you to repeat yourself and to not create / use abstractions. Nil pointers are still a thing. It's incredibly easy to accidentally shadow a variable and not handle an error. These are all solved problems in other languages, yet they persist in Go, and they are all maintenance headaches.
  - cloverich 6y ago
    > I don't think "clever"ness is what makes code unmaintainable. You can still create a tangled mess in Go... It's not the only factor, but it is certainly _a_ factor: "Clever code" is typically meant as derogatory. Fancy abstractions for simple use cases is a common cause of tech debt IME, and harder to unwind than under-abstracted code (tedious as that is to fix).
oconnor663 6y ago
> Go doesn’t have generics. > And Go hasn’t added any major features since Go 1 was released in 2012. Isn't Go in the process of adding generics as we speak? https://blog.golang.org/why-generics https://blog.golang.org/why-generics
ssorc3 6y ago
'Go doesn't have immutables'? So it has mutability then. How does that affect how 'boring' a language is? Surely immutability is simpler.
- tsimionescu 6y ago
  Immutability is much more difficult to reason about except for some very mathy problems. It is extremely natural to think in terms of state, so much so that almost all algorithms you'll find in computer science are commonly expressed in imperative terms.
  - dimitar 6y ago
    It is fine to use local mutable variables to implement an algorithm, however global objects modified all over a complex program can be risky - you might have bugs caused by getting into an "unexpected" state.
    - tsimionescu 6y ago
      And what does that have to do with everything being immutable by default? Either the language supports mutability as a first-class concept, or it doesn't. Sure, you shouldn't be using mutable global state, either in Go or in Haskell. The bad part about Go is that it's impossible to write type-safe immutable collections. Apart from that, I don't think it encourages mutable global state anymore than any other language with first-class mutation.
  - erik_seaberg 6y ago
    In a concurrent language, shared mutable state is the trap that Hoare's CSP book was urging us to avoid. Worse, in Go builtin maps are always writable yet parallel writes and reads can segfault. There's a sync.Map type but it isn't a drop-in replacement (because builtin maps don't implement any interfaces) and it isn't typesafe (because no generics).
    - tsimionescu 6y ago
jdonaldson 6y ago
There's been other boring, fantastic languages... Lua comes to mind. There also always seems to be one or two "crippling" missing features for these kinds of languages as well. I actually think it's a good thing! We should stop adopting one-size-fits-all thinking.
imagetic 6y ago
Capital One is probably the worst endorsement possible.
kockic 6y ago
I think the main advantage of go is it's learning curve. Standard lib is quite small, so even with no experience, in a few weeks you could be fully productive on any go code base. With e.g. C, Rust, Java, Ruby this would probably be months.
roryrjb 6y ago
But is Go boring? I'm less interested in language syntax and semantics than I am about the runtime. I mean this generally and with all languages. Yes Go the language is simple and boring but the runtime, to me at least seems somewhat magical. By that I'm really talking about the concurrency. A lot of people sell Go by talking about Go routines but to me it's the one thing that makes me wary of adopting it. I'm very uncomfortable just blindly using concurrency features and not really knowing what's going on underneath.
entha_saava 6y ago
Maybe, Idk who that appeals to.. But Go lacks the even most trivial of array / slice manipulation functions. Is this loop an index() or apply() or filter() or count() or sum() or wutt? Don't even talk about generic data structures. To be fair, Go authors are pretty smart having created something more usable than C while not even seriously looking at how things are done in other languages.

250 points by rauhl 6y ago

pif 6y ago

Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. https://www.angelo.edu/faculty/kboudrea/cheap/cheap3_murphy.htm https://www.angelo.edu/faculty/kboudrea/cheap/cheap3_murphy....

pdog 6y ago
Counterargument: build systems that any idiot can run, because eventually an idiot will be running it.
artsyca 6y ago
Murphy's eighth law is contrary to every success metric. People tend to say "..but we're doing well!" and that's supposed to be a bad sign.
moreaccountspls 6y ago
You think everyone building tools like k8s, terraform, etc. are fools? That's a pretty myopic worldview.
- erik_seaberg 6y ago
  Terraform is I/O bound on cloud provisioning APIs (its CPU performance doesn't matter), and its complex object models need to be extensible. Python would have been a better choice.
  - jen20 6y ago
    As a former maintainer of Terraform, I 100% assure you that Python would have in no way been a better choice. While Terraform is I/O bound to some degree, it has a large degree of concurrency - something quite miserable to do in Python. Terraform does not take full advantage of even the type system available in Go, but a dynamic language would make things even worse. I do not think Go is the ideal language for programs like Terraform, but having spent many thousands of hours in that codebase now, the answer is stronger types (likely Rust), not fewer.
    - erik_seaberg 6y ago
      I'm currently generating bloated JSON templates because writing any kind of non-Go plugin looked like a painful ordeal.

deleted 6y ago

[deleted]

ladyanita22 6y ago

From what I'm reading, I fail to see how Go is faster than other languages. It actually seems pretty bad. In the article, it is said to match Java. In the Benchmark Game, it is certainly not among the fastest.

corty 6y ago
Go is on average about as fast or as slow as Java, with different strong and weak points. But there is definitely a lot if optimisation potential, the compiler is only "so so" in that regard.
throw_m239339 6y ago
In my experience Go uses less RAM than Java, but perhaps it has absolutely nothing to do with the language but more with how libraries are written. I rarely see fixed sized arrays used in Java for instance. It's common in Go. When it comes to speed, on a running server, Go isn't faster at all at scale, and DB drivers tend to be less mature for certain RDBMS.
didip 6y ago
In my experience, Go gives a perception of faster than Java because the GC pause on average is really quick compared to a decently tuned G1 GC.
- erik_seaberg 6y ago
  Go's GC has always had pretty low throughput compared to a JVM, but with value types (which Java doesn't have yet) it can be faster if you manage to keep everything on the stack.

cmrdporcupine 6y ago

Enums, immutables, and generics aren't good because they're exciting. They're good because they give us expressive tools to write descriptive, type safe systems that manage state better. I don't like "modern" systems because I have a fetish for novelty. There's nothing novel about these concepts, they've been around since the 60s and 70s. I like these tools because they improve my ability to reason about the code, but more importantly they let the compiler and other static analysis tools reason about my code. I am getting old and lazy. I want the compiler to do more for me, not less. What I see is a situation where Go is gaining traction from two communities: a) people who attempted to build large systems at scale in dynamic late bound languages like Python and Ruby and NodeJS etc, and hit the wall from a performance and maintainability POV. I could have warned you... b) people who came from the Java world and got frustrated with the language and tooling there People coming from a) especially but also b) to some degree will be perfectly comfortable with Go missing the nicer aspects of modern static typed languages because they never had them in the first place. As for... "Go doesn’t have a virtual machine or an LLVM-based compiler." How is this any kind of pro or con? It's just an implementation detail.

akavi 6y ago
Exactly. I don't want sum types becuase they're exciting, I want them because they're the simplest way to communicate to the compiler that "my data can either be this or this and nothing else", so I don't blow off my foot by accidentally making it that. When I was younger and less jaded, it actually was fun and exciting thinking up ways to hack around language limitations like that. Now it's just frustrating.
- deleted 6y ago
  [deleted]
- frankie_t 6y ago
  That actually surprises me a lot. I've seen plenty of critique about lacking generics and exceptions, while haven't seen much complaint about ADTs. From my rather dilettante point of view they are neither too complex for "philosophy of simplicity", nor they add much of compile time. It seems to me they even can be implemented as a syntactic sugar on top of type casts. I certainly cannot see them being more complex than generics.

dmitshur 6y ago

I’ve been very happily using Go the last 7 years (disclaimer, I’m employed to work on Go as of 2 years ago), some random personal thoughts. It’s interesting how a language can be boring and so fun to use at the same time. I guess I don’t want excitement at the language layer because there’s plenty of opportunity for it in other layers. A boring language to me means there’s usually roughly one way of doing something, so you just need to write up that one thing and move on to the next part of what you’re building, knowing the past part is finished. Once something works well and has a good API, I almost never want to come back to it and rewrite it with a different set of language features that I happen to learn. The process of writing Go is fun to me because starting with an empty Go program to do a new task is always a refreshing experience, it’s easy to reuse any past functionality that you’ve already created (or found) and you can focus on the new task. In contrast, when I was primarily using C++, starting a new codebase wasn’t pleasant because of all the housekeeping and boilerplate (like defining a uint16 type in a platform-agnostic way) I needed to copy/paste just to have a reasonable starting point. Also, the feeling of gofmt/goimports running on save and formatting the code on save is a huge part of what makes it fun (fortunately, code formatters are much more commonplace now; I wouldn’t want to go back to not having them).

gcatalfamo 6y ago
Since you work with go I have a question. I learned it superficially but I’d like to get more fluent with it. Which resource would you suggest?
- threeaccents 6y ago
  If you have built a program in any other language I would say rewrite that program in GO. The benefit being you already solved the the domain logic of the program the only thing you need to focus on is writing/learning GO. If this is your first programming language or attempt to learn to program I would say to just pick a small but simple app/program and just go ahead and build it. Don't spend too much time on reading articles or video tutorials just get your hands dirty as soon as possible.
- dmitshur 6y ago

untog 6y ago

Obviously this is all a matter of opinion but I don't consider a lack of exceptions, enumerations and generics "boring", I just consider them to be missing features. Certainly there's an argument to be made for simpler languages being better (maybe we should all be writing in Assembly?) but I'm personally not convinced.

isp-localhost 6y ago
I hear these sorts of arguments often, as someone who likes both Go and C I do have some responses: I would hardly call exceptions in C++ a "feature" but more of a "liability." Enumerated types (probably referring to sum types here) have trade offs that are not necessarily clear from simply reading the code. Generics often lead to code which is (IMO) difficult to follow, debug, and reason about. The point about assembly is jest? Or dishonest? I would argue that C, C++, Go, Haskell, etc etc are "simpler" than assembly, if they weren't we probably would be writing assembly, and I suppose following that logic maybe we'd be hand constructing opcodes with a two key keyboard.

grey-area 6y ago

Being boring really is what I love most about Go. It doesn't change much and there is a culture of simplicity, so it's quick to onboard new devs and there isn't a lot to get your head around. That also makes it good for building large projects, as the complexity is in the domain and the application, not clever uses of the language itself. I almost wish they'd make it more boring and take a few things out, but it's probably too late now to change the language much and people would complain vociferously. Things I never use and wish it didn't have: panic, goto, labels, struct tags, executable comments, even arrays. The only things I'd like to see improved significantly are enums, errors, and user-space generic collections (coming soon!).

cy_hauser 6y ago
> generic collections (coming soon!) You and I must experience time differently. I read a couple days ago that the end of 2022 would be the earliest they might appear but probably further out than that.
- leetrout 6y ago
  > the earliest that generics could be added to Go would be the Go 1.17 release, scheduled for August 2021 https://blog.golang.org/generics-next-step https://blog.golang.org/generics-next-step
- grey-area 6y ago
  I've been using it about 8 years at work, and don't mind if they take another year, it'll take a while to work into large code bases anyway. Personally I've felt generics as a lack but not a huge unfillable hole, and prefer language stability to churn, so am completely fine with it taking time to add large features. I'm pleased with the evolution of the generics proposal so far - it's getting simpler and more transparent. I really wish in their mooted Go 2 they could just remove some features, as listed above, rather than add some. Perhaps everyone prefers a slightly different subset of the language though so that isn't really possible.

zaphar 6y ago

I wonder what the actual statistics on bridge building are. Are they really typically done on time and on budget? How many times do the drawings or engineering specifications for a specific bridge have to change while getting built to adapt to new information? We trot out this particular analogy all the time in software engineering and I can't remember ever seeing any real data to back up the assertions.

corty 6y ago
From having lunch with guys from the mechanical engineering department (they were right next door at uni) my anecdotal second-hand wisdom is: Most larger engineering projects are as broken, tedious, expensive and unpredictable as most software projects. You will always find unsteady ground that nobody told you about, new last-minute requirements, shitty subcontractors making a mess and substandard parts that happened to be cheapest on the tender. From what I've heard, around 2 in 3 projects are over budget or over time in a significant way because something was massively screwed up somewhere and needed to be hotfixed, patched, rebuilt or -my favourite- reevaluated to be statically sound without structural changes. I think the common software engineering myth about "real engineering" being somehow better and something one should aspire to is just really a myth.

jrockway 6y ago

> Go doesn’t have ... an LLVM-based compiler. https://github.com/tinygo-org/tinygo https://github.com/tinygo-org/tinygo

todotask 6y ago
Yes, it's not part of Go standard library https://tinygo.org/faq/why-a-new-compiler/ https://tinygo.org/faq/why-a-new-compiler/

corty 6y ago

While the article overall might not be totally wrong, at least two details are dead wrong. Go DOES have a virtual machine, thats what gives you all the lightweight threads and garbage collection. You may call it "runtime", but there is no difference between a heavyweight runtime or a lightweight VM. And go DOES have exceptions, thats what panic does. The are just used less frequently than in other languages (e.g. Java, where even the happy path may contain exceptions, e.g. in Swing).

pjmlp 6y ago
So C has a VM apparently, https://en.cppreference.com/w/c/thread https://en.cppreference.com/w/c/thread https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc https://clang.llvm.org/docs/Block-ABI-Apple.html https://clang.llvm.org/docs/Block-ABI-Apple.html
efficax 6y ago
A "runtime" is not a virtual machine anymore than the standard c library is a virtual machine... it's clear what virtual machine means in this context: an abstraction layer between machine code and program code that translates one to the other at runtime.
- corty 6y ago
  By that argument a x86-VM running on x86 is not a VM because there is no code translation in between.
  - lostmsu 6y ago
    Words can have different meanings in different contexts.
    - corty 6y ago
      Yes, but here they don't. A VM is a non-physical machine that executes instructions. Nothing more, nothing less. And yes, this means that even a library might be considered a VM. I don't see why people get so wound up about that.

melvinroest 6y ago

> But the people who design and build bridges, they're great at it. Bridges get built on time, on budget, and last for dozens, hundreds, even thousands of years. Bridge building is, if you think about it, kind of awesome. And bridges are such a common occurrence that they’re also incredibly boring. No one is amazed when a bridge works correctly, and everyone is kind of amazed when software does. Emphasis mine was added by me. Sorry, source needed. You're a software developer, not a bridge builder. Yes, bridges in my country seem to work, fair enough. But I have the faintest clue if the design/building process really is going that smoothly. To write this down as a fact to build your argument is IMO a pretty big assumption.

buster 6y ago
Especially if you consider the state in which some infrastructure is around the world. I'm impressed to see the occasional aqueduct from 2000 years ago in Europe, but i also see the occasional modern bridge collapsing in the same country (https://www.theguardian.com/cities/2019/feb/26/what-caused-the-genoa-morandi-bridge-collapse-and-the-end-of-an-italian-national-myth https://www.theguardian.com/cities/2019/feb/26/what-caused-t...). From what I've heard and seen, infrastructure in the US (roads, bridges) isn't exactly the example for "build once, use for thousands of years". And that's not even considering how many of those road or bridge building projects really are in time and budget.
mplanchard 6y ago
I agree with this. I live in Austin, TX, and we’ve constantly got five to ten big construction projects going, both in the private sector (new buildings) and the public sector (usually roads and other transportation infrastructure). It’s certainly possible I just haven’t been paying good enough attention, but it seems like the vast majority of such projects that have been completed over the last six years have been over budget and behind schedule.
encloser 6y ago
I am a US citizen with a bunch of civil engineer friends who are Professional Engineers (the capital letter, licensed kind). For a good number of years I had a roommate whose job was literally designing bridges. We've talked about this very comparison. Bridge building is not as boring as this author thinks. It can be pretty stressful. There are a few factors that make bridges very reliable (but not perfect) in the US. A real engineer can probably describe this far better than I can. 1) Physics and material science are pretty well known quantities. There is innovation and new materials come to market, but by the time they are approved to be used in real bridges their qualities are fairly well known and tested. They have solid evidence of the capabilities of a material or part. (Tensile strength of an item under various environmental conditions, for example). 2) Standards & Very Firm Requirements (Where waterfall works!) They have a set of strict approved industry standards to rely upon. Not the "industry standard by convention" kind that you see around IT a lot, but the "tested, reviewed, approved, published by a standards body" kind. When a civil engineer is assigned to build a specific bridge they reference these standards that tell them "given this type of ground do this", "given this length of span do that". They know the lengths and widths, they check the traffic patterns, they know the desired weight limits. Challenges do come up, yet they have fewer unknown unknowns. Something changed from their expectations, maybe the ground is different than expected, but they still have standards that guide them in what to do in those cases. 3) Reviews, reviews, reviews. Other Professional Engineers have to sign off on the work of the initial designer(s). Deep reviews. Not what typically passes for software architecture and code reviews I've seen. 4) Legal responsibility. Professional Engineers have an amount of personal accountability at stake because real lives are at stake if something fails. 5) "User" common sense and intuition Nobody builds a 100,000 ton vehicle and then tries to drive it over a bridge. Most any human that thought about doing this can probably reason that doing so would break the bridge. In my experience software users have no idea that trying to push a 1TB file into a system that was designed to only handle 1MB files will cause it to fail. They often have no idea when their data volume increases. "I'm doing the same thing I did last month!" All that and more, yet bridges still go over budget and over time and fail and people die.

empath75 6y ago

IMO, the thing that makes go good, from an enterprise point of view, is that you can take a team of mediocre coders who have never used it before, and deliver working code quickly. It might be ugly, it might be dumb, but it'll get the job done, and will generally be easier to maintain than python or ruby in the long run and with good performance. I think a few things contribute to that: 1) Relatively few language primitives -- it takes like a day to learn 90% of the keywords you'll be using day to day. 2) Transparency -- it's easy to look at any code base, and track down all the relevant code, even without an ide. Compared to a language like ruby, there's not a lot of 'magic' happening. 3) Conciseness. Unlike a lot of statically typed languages -- go code isn't verbose. It's statically typed, but the inference works well enough that you're very rarely having to use type hints all over the place -- Java has started to be more like this, but back when go started, it was a breath of fresh air. 4) Kubernetes. If you want to build on top of k8s, go is pretty much the only game in town. It just makes everything eaaier. Other languages have k8s support, but any language other than go will have more friction. 5) Go channels and concurrency -- I actually don't think this is that important, but knowing that it's available if you have that kind of performance demand is nice.

pjmlp 6y ago
The irony is that in 2020 from Go's point of view, Java is a PhD level language.
- courtf 6y ago
  What does it mean to be a "PhD level language?"
  - pjmlp 6y ago
    It means a language with support for enumerations, generics, overloading, pattern matching, annotations, compiler plugins, access levels,....
    - deleted 6y ago
      [deleted]

sandGorgon 6y ago

One of the questions that i have always wondered about is how do financial companies work with math libraries in any language other python - which not only has the entire math/statistical software mindshare..but pandas/scipy + BLAS/LAPACK is optimised to its gills in Fortran. For e.g. Monzo engineers have tweeted that they had to create an internal math library - https://twitter.com/_liclac/status/1264142576908722178 https://twitter.com/_liclac/status/1264142576908722178 Once you bring Pandas, Scipy, LAPACK/BLAS, Numba/Cython into play...then i bet these benchmarks look a lot different.

stephc_int13 6y ago

>There are a few things that we have learned in the last 60 years about writing programs where there is pretty much universal agreement: >We agree that it's better to find problems earlier rather than later. Agreed. >We agree that people are awful at managing memory in programs. Nope, manual memory management can be done properly and this is not rocket science. >We agree that code reviews help find bugs. Sure, but this is not the only way and not always the most efficient. >We agree that on any project that requires more than one person, communication costs dominate. Nope, this is a blatant over-generalization.

zeveb 6y ago
> Nope, manual memory management can be done properly and this is not rocket science. Outside of NASA (often, literally rocket science!), where has manual memory management ever been done properly? I don't think that it ever has. For that matter, I would be unsurprised if even NASA had manual memory management failures.
- cyb_ 6y ago
  Even NASA apparently has rules against dynamic memory management in critical systems. > 3: Do not use dynamic memory allocation after initialization. https://sdtimes.com/nasas-10-rules-developing-safety-critical-code/ https://sdtimes.com/nasas-10-rules-developing-safety-critica... https://news.ycombinator.com/item?id=4339999 https://news.ycombinator.com/item?id=4339999
  - blibble 6y ago
    high performance trading systems use the same approach (of course: failure is less catastophic than it would be for NASA!)
- defnotashton2 6y ago
  Video game industry?
  - 6y ago

deleted 6y ago

[deleted]

jherdman 6y ago

Boring technology that does great things has been a huge part of my career for the past eight years at Precision Nutrition. With that said, the following opinions are mine and mine alone. Here are some boring choices we made that paid dividends: 1. Postgres. It does what it does, it's stable, it's reliable, and continues to improve as time goes on. 2. Ember. It's by far the most stable front end framework going. It's made our job easy in uncountable numbers of ways. 3. PostCSS. Write plain CSS, use modern features, remove plugins as browser support grows. A few years ago I'd have said Rails was a boring technology we chose too. These days I'd say it's a bit of a thorn. It's clear that some of the magical choices made make long term maintainability challenging, as are some of the performance characteristics. A few of the libraries used by the community have bitten us hard too insofar that they're either a maintenance nightmare, poorly maintained, or exceptionally difficult to migrate away from (e.g. CanCanCan, Active Model Serializers). These days I'm playing with Elixir, which is also boring but allows you to do exciting things. I especially appreciate ExUnit having come from the RSpec world — assert, refute, end of story.

sirtaj 6y ago
Not disagreeing with your general point, but I see Postgres as far from a boring choice. It is constantly evolving in inventive ways.
brendanmc6 6y ago
I'm a frontend dev and amateur solo founder interested in tools that empower me to build more with less effort. Should I finally bite the bullet and learn Postgres/SQL? I have the (ill-informed) impression that it's better suited for large and complex systems whereas I'm mostly building SaaS and simple e-commerce apps. Aren't there usually full-time SREs focused on managing and maintaining SQL databases? I can get really really far, really quick with Cloud Firestore (for free at my scale), and stay focused on my frontend. But as complexity grows and requirements change I can sometimes find myself in sticky situations-- mostly because there are no tools for schema migration in Firestore. But on the other hand with Firestore and similar noSQL products I can get scaleability, security, speed, stability and a lot more all out of the box. Curious to hear your input.

konart 6y ago

>You don't have permission to access "http://www.capitalone.com/tech/software-engineering/go-is-boring/" http://www.capitalone.com/tech/software-engineering/go-is-bo... on this server. oh...

tapirl 6y ago

> Go doesn’t have immutables. Declared functions in Go are immutables.

LandR 6y ago

I sometimes wonder if Go is a long running by joke by Google. Like someone internal at Google said people will use and adopt en masse anything they make, regardless of how good it is. Someone else said no way, a bet was made, and Golang was released. Ignoring 20-30 years of programming languge theory advancements. Yet everyone laps it up. And here we are today. I'm sure someone at Google is laughing. I find Go completely tedious and inelegant to work with, its too verbose and i think verbosity hides intention and expressiveness.

defnotashton2 6y ago
What are you comparing it to and would prefer?
- LandR 6y ago
  Languages I would prefer to work in than Go: Clojure C# F# Rust Scala Ruby Kotlin
  - leetrout 6y ago
    Are you working in those languages now and do you have a remote build environment or are you building on your laptop? Scala and Rust's build times get very noticeable very quick IME.
    - LandR 6y ago
      Ive worked places where compiling the C# solution on my dev machine took 30-40 mins and the build server took an hour plus... I haven't seen anything else ever be that bad.
      - leetrout 6y ago
        The scala shop I was at Last year was 45+ mins on a 2019 mbp with 16gb ram. You had to turn off IntelliJ so you wouldn’t run out of ram.
  - 6y ago

drewcoo 6y ago

Coding Go is like an old bridge. Because almost all Go code will be removed or replaced in short order. And only a very few survivors will still exist years from now to feed the confirmation bias of "history." That analogy should go the way of most old bridges.

k_bx 6y ago

Go does have subtyping (unlike Rust and Haskell), which makes type system needlessly more complicated and type inference harder.

atombender 6y ago
Go doesn't have subtyping, only implicit coercions. Not the same thing.
- k_bx 6y ago
  Right, thank you for this correction! I've just spent some more time with Go, looks like I was wrong and it has something closer to Type Classes (or Traits), but not subtyping. // Too bad editing is not available anymore
entha_saava 6y ago
Type deduction from right hand side expression is enough and that was stated in FAQ that they didn't want HM inference. Edit: well not in FAQ but somewhere else. IIRC Rob Pike.
- k_bx 6y ago
  Turns out I was wrong (and corrected thankfully), Go does not have subtyping, which is good news (at least it makes the language way more tolerable for me).

throw_m239339 6y ago

Go is like C. AKA roll your own unsafe type system at runtime with void pointers (or interface {} in Go). This isn't acceptable for a language released 10 years ago. On one hand you have a rigid type system very limited in terms of polymorphism, on the other hand with interface {} anything goes, even creating Adhoc functions at runtime. Go should have taken cues from ADA and how it implements generics. There is enough polymorphism to solve most cases where generics are useful, but also enough limitations so that a codebase isn't cluttered with `Type A<Type B<C,D,Type E<F,G,H>>>` horrors everywhere.

carapace 6y ago

If you were trying to choose between Go, D, Nim, and Zig for a general-purpose compiled language, what are the criteria for differentiating and what are the pros and cons of these languages? Are there other languages that should be included in this list? (Common Lisp?) (FWIW, chief on my list of criteria is the "debug story": what kind of hell am I in when things inevitably go wrong?)

jaco8 6y ago
After looking through the lot we settled on Nim. Give it a try , it will grow on you.
blandflakes 6y ago
I often try to jam OCaml in that list based on my own interests, and people also suggest Crystal a lot. To me Nim is maybe the most interesting to the widest audience.
kazinator 6y ago
To make things interesting, can we add the following choice: wading chin-deep over a half-mile wide tract of land flooded with raw sewage, to reach a C compiler.
- carapace 6y ago
  I'm coming around to C-with-good-tools as a decent option. It's everywhere and it's been studied and meta-programmed to death and back again.

rchaves 6y ago

> Among compiled languages, garbage collection is rare ?????? > Rust's borrow checker is a fascinating way to get high performance and memory management, but it effectively turns the developer into the garbage collector, and that can be hard to use correctly Isn’t the whole point of rust that you cannot get memory management incorrectly because compiler guides you? > all Go code is formatted the way that go fmt says code should be formatted. just like rustfmt, elm-format, prettier and I hope most modern or future languages I agree with his main idea, I also like the idea of a boring language, but then his arguments misses the point completely, talking about benchmarks and such. He should talk about why having no exceptions can be a good thing, or having no generics. Having a very small API surface and stable language is one of the reasons I love Elm as well, nobody is able to do too smart abstractions with monads and such, it’s about code, readability, explicit better then implicit, etc, nothing to do with garbage collecting, performance, blablabla

leetrout 6y ago
I worked at a shop where there was some Ruby code and autoformatting was argued against from one of the senior tech leads because "[ruby] wasn't designed for an autoformatter. go was built that way" Absolutely blew my mind. I love go fmt, prettier, black, etc and cannot understand why people still love to argue over styling at this point. I get that he was saying the formatter ships with Go but I don't subscribe to the idea that you can't use an opinionated formatter because the language authors didn't make one.
- recursive 6y ago
  I can kind of understand it. If it's a first class part of the language, then it's never going to get painted into an ugly corner. As a nearly related example, the LESS css pre-processor language was developed prior to `calc()` expressions. As a result, the LESS language parses arithmetic expressions. So `calc(10em + 10px)` compiles to `calc(20em)`. So in order to do `calc()` expressions, you have to use nasty hacks like `calc(10em ~"+" 10px)`. If LESS "shipped" with CSS, this wouldn't have happened.
  - 6y ago

hyperman1 6y ago

It strikes me how this gives a value proposition for go that is very similar to COBOL: Easy structure, predictable to build and run, minimize individual coding style differences,.... Not necesarrily disparaging for either lanfuage, as COBOL, boring as it is, has brought tremendous value in large scale software engineering. There are of course big differences too, like i18n, variable width strings, ... But if you give COBOL a c-style syntax,some dynamic size data structures, and you squint a bit, you end up quite close to Go

ed25519FUUU 6y ago

My favorite thing about Go is that I can jump into any codebase, written by any developer, and the mental load required to unwrap their logic is very low. The "stylistic opportunity" for other languages is such that I can usually tell which developer on the team wrote what just at a glance. Not so with Go. It's all the same bland but beautiful gray. Something to be said about languages that help external people understand them, as opposed to languages developed to improve developer satisfaction.

didip 6y ago
I agree with this opinion, code review burden in Go is so little.

exabrial 6y ago

...functions returning multiple parameters, confusing operators that are different 'just because', types on the right hand side instead of the left 'just because', I don't think GoLang is solving as many problems as it creates. It's different because being different is cool, not because it solves any sort of practical problems. If I were going to go learn some strange non-C-like-outer-worldly-syntax, I think your effort is best spent learning Rust, which is way faster, offers some strong failure guarantees, and fills a lot of use cases from embedded systems to WASM.

__tg__ 6y ago

Re. the bridge analogy in the article: we had a bridge being built behind our building at work and they had announced the opening date a year in advance. Sure, when the date came the bridge was opened exactly on time. I was walking with my colleague across it and asked him, "How come we can't ever predict when we'll be done?". His answer was deeply insightful: "They build the same bridge every time while we build a different one".

nikki93 6y ago

The manual memory management thing -- like needing GC -- feels like a false dichotomy. Most of these languages that have GC need you to "manually" manage resource lifetimes anyways for a lot of resources: files, network connections. If you're making a UI, you think about when components are mounted and unmounted. The logic for all this is domain logic and part of the code for your program. Memory is just one such resource, and I think there should be more acknowledgement of it as such by languages, instead of just piling it up and kicking a "GC cycle" to clean it up whenever, leading to pauses in interactive programs and whatnot (Go's GC, and Go in general, do not perform well under WASM in my experience). In Go you have to "manually" defer a file.Close() call -- vs. the destructor getting automatically called in C++ (it even gets automatically called when a containing object is destructed, if it's a member, and so on). Go's version doesn't seem very "automatic" to me. The simplicity of Go actually hides a lot of runtime complexity that is happening: the GC, map lookups, scheduling of goroutines and so on. Which you have to understand and then ultimately learn how to tune from a distance (because you don't have direct control) for a lot of applications where it matters. For server applications (where the hardware is under your control) and also CLI tools (which can just run, only allocate memory, then just exit), this matters less. If your code is running on user's devices as an interactive application, it feels to me like how it performs on and uses their actual hardware is part of your responsibility as the developer, and some things about Go make that harder to do. Like you have to think about the GC and try to avoid it ("from a distance") if you run into that (which you do quickly in WASM, and which eg. Gio tries to explicitly design around, and so on). I want to see languages that care about simplicity and also include such deterministic resource management as part of their design and offering.

coder543 6y ago
> In Go you have to "manually" defer a file.Close() call -- vs. the destructor getting automatically called in C++ (it even gets automatically called when a containing object is destructed, if it's a member, and so on). Go's version doesn't seem very "automatic" to me. To clarify this one point, Go allows you to attach a destructor (finalizer) to an object, but since the language is garbage collected, there’s no guarantee of when the destructor will be called, if ever, since disabling the garbage collector is entirely possible, even if not advisable. The File object will Close the file when the Finalizer runs, since the standard library attaches a finalizer to it, but you should defer the Close to deterministically ensure that the file is closed when you expect it to be closed, and to free that OS resource of a file handle as soon as possible, since some OSes limit how many you can have at a given time. Finalizers also won’t be run when the program exits, which is fine for most things, but you’ll want to have ensured any buffers were flushed before then, and defer can guarantee that. Languages like Rust and C++ have deterministic destruction at the end of a given scope thanks to RAII, so it makes sense for them to lean more heavily on destructors there. Java File*Stream objects should have “close()” called on them, from what I’m seeing on a Google search, so this doesn’t seem to be a surprising pattern for a garbage collected language. I know in Python you’re encouraged to use a “with” block to ensure that file objects get closed. https://golang.org/pkg/runtime/#SetFinalizer https://golang.org/pkg/runtime/#SetFinalizer

charlesdaniels 6y ago

I think a lot of the commenters are missing the point. Golang is less expressive than other languages, like Rust or Haskell. You can't create fancy custom types and things like that. Of course there are drawbacks. The benefit however, is that it's much harder to write "clever" code, which translates into being harder to write unmaintainable code. If you know Go, you can sit down at nearly any Go codebase and know what's going on pretty easily. That certainly isn't the case for C or C++, and probably others (other people have told me this is true of Rust, but I have not used it, so I will not claim that). Golang is not the fastest, or the most expressive, or whatever else. But it's got enough expressiveness to not be painful for most use cases (slices, maps, and structs cover a lot of ground). It's fast enough for most use cases (faster than most scripting languages). In my opinion, Golang has a very good ratio of (effort required to learn) / (utility of learning). I have no doubt that Haskell is extremely powerful... if you can learn how to use it. I wouldn't be signing up to write a new OS kernel in Go, but for a userland program that doesn't have hard-RT requirements? I think Go strikes a better balance compared to C, C++, Java, Python, and others.

thatswrong0 6y ago
> The benefit however, is that it's much harder to write "clever" code, which translates into being harder to write unmaintainable code. If you know Go, you can sit down at nearly any Go codebase and know what's going on pretty easily. I don't think this necessarily follows. I don't think "clever"ness is what makes code unmaintainable. You can still create a tangled mess in Go just as easily as other, more expressive languages. In fact, I think it's more likely in Go simply because you _have_ to write more code in Go. More code is more maintenance. Go encourages you to repeat yourself and to not create / use abstractions. Nil pointers are still a thing. It's incredibly easy to accidentally shadow a variable and not handle an error. These are all solved problems in other languages, yet they persist in Go, and they are all maintenance headaches.
- cloverich 6y ago
  > I don't think "clever"ness is what makes code unmaintainable. You can still create a tangled mess in Go... It's not the only factor, but it is certainly _a_ factor: "Clever code" is typically meant as derogatory. Fancy abstractions for simple use cases is a common cause of tech debt IME, and harder to unwind than under-abstracted code (tedious as that is to fix).

oconnor663 6y ago

> Go doesn’t have generics. > And Go hasn’t added any major features since Go 1 was released in 2012. Isn't Go in the process of adding generics as we speak? https://blog.golang.org/why-generics https://blog.golang.org/why-generics

ssorc3 6y ago

'Go doesn't have immutables'? So it has mutability then. How does that affect how 'boring' a language is? Surely immutability is simpler.

tsimionescu 6y ago
Immutability is much more difficult to reason about except for some very mathy problems. It is extremely natural to think in terms of state, so much so that almost all algorithms you'll find in computer science are commonly expressed in imperative terms.
- dimitar 6y ago
  It is fine to use local mutable variables to implement an algorithm, however global objects modified all over a complex program can be risky - you might have bugs caused by getting into an "unexpected" state.
  - tsimionescu 6y ago
    And what does that have to do with everything being immutable by default? Either the language supports mutability as a first-class concept, or it doesn't. Sure, you shouldn't be using mutable global state, either in Go or in Haskell. The bad part about Go is that it's impossible to write type-safe immutable collections. Apart from that, I don't think it encourages mutable global state anymore than any other language with first-class mutation.
- erik_seaberg 6y ago
  In a concurrent language, shared mutable state is the trap that Hoare's CSP book was urging us to avoid. Worse, in Go builtin maps are always writable yet parallel writes and reads can segfault. There's a sync.Map type but it isn't a drop-in replacement (because builtin maps don't implement any interfaces) and it isn't typesafe (because no generics).
  - tsimionescu 6y ago

jdonaldson 6y ago

There's been other boring, fantastic languages... Lua comes to mind. There also always seems to be one or two "crippling" missing features for these kinds of languages as well. I actually think it's a good thing! We should stop adopting one-size-fits-all thinking.

imagetic 6y ago

Capital One is probably the worst endorsement possible.

kockic 6y ago

I think the main advantage of go is it's learning curve. Standard lib is quite small, so even with no experience, in a few weeks you could be fully productive on any go code base. With e.g. C, Rust, Java, Ruby this would probably be months.

roryrjb 6y ago

But is Go boring? I'm less interested in language syntax and semantics than I am about the runtime. I mean this generally and with all languages. Yes Go the language is simple and boring but the runtime, to me at least seems somewhat magical. By that I'm really talking about the concurrency. A lot of people sell Go by talking about Go routines but to me it's the one thing that makes me wary of adopting it. I'm very uncomfortable just blindly using concurrency features and not really knowing what's going on underneath.

entha_saava 6y ago

Maybe, Idk who that appeals to.. But Go lacks the even most trivial of array / slice manipulation functions. Is this loop an index() or apply() or filter() or count() or sum() or wutt? Don't even talk about generic data structures. To be fair, Go authors are pretty smart having created something more usable than C while not even seriously looking at how things are done in other languages.