10 ms·

Bringing up goland always annoys me for some reason. Like, it's really practical, it is fast, but not actually low-level, it compiles fast, and most importantly

by krick 2y ago

Bringing up goland always annoys me for some reason. Like, it's really practical, it is fast, but not actually low-level, it compiles fast, and most importantly it is very popular and has all the libraries. It seems like I should use it. But I just almost irrationally hate the language itself. Everything about it is just so ugly. It's a language invented in 2009 by some C-people who are apparently oblivious to everything that excited PL design folks for the last 20 years (as of 2009). PHP in 2009 was already a more modern and better designed language than goddamn golang. And golang didn't really improve since. I just cannot let it go somehow.

pimeys 2y ago
I know, I'm on the same boat. What I realized is I just need to avoid the companies using Go and I don't really need to be vocal about my dislike. It's not my loss if others find the language useful, but for me it either solves problems I'm not interested in solving, or the language and tooling just does not make it for me. But, I can always just write Rust and be happy where I am. Or, to be honest, would not be very unhappy with F#, Haskell or Ocaml either.
- meowface 2y ago
  >What I realized is I just need to avoid the companies using Go What do you mean, exactly?
  - leftyspook 2y ago
    I'd imagine not seeking employment at Google is a big part.
    - tempest_ 2y ago
      Go is definitely used a lot more outside of google as of late. Anecdotally I would say where a lot of companies would have used Java in the past they are now turning to go for their server-side/backend service implementations.
      - danudey 2y ago
        Also it feels like pretty much everything in the k8s/container/etc. space is go-related, which kind of makes sense.
        guappa 2y ago
        Why does it make sense? You can implement a container in any language that can make system calls.
- mistrial9 2y ago
  > I just need to avoid the companies using Go and they also will avoid you! A monthly go-lang meetup in San Francisco impressed me as the only meetup I have ever been to where no one (in a crowded venue) seemed to want to talk to anyone outside their clique
  - guappa 2y ago
    They don't like hearing that the new exciting feature that the new go has was already in every other programming language 10 years ago.
pjmlp 2y ago
It is worse than that, as Go initially lacked generics (introduced by CLU and ML in 1976), still doesn't do even basic Pascal enumerations (1970) rather the iota/const dance, let alone the 1990's programming language design surface. I only advocate for it on the scenarios where a garbage collected C is more than enough, regardless of the anti-GC naysayers, e.g. see TamaGo Unikernel.
- Thaxll 2y ago
  So every language have to implement every features released in the last 50 years?
  - treyd 2y ago
    I expect it to implement features that have become ubiquitous in every other mainstream language from the last 30 years, yes.
    - Thaxll 2y ago
      That's how you end up with C++ and soon C#.
      - pjmlp 2y ago
        We also end up with C23, Fortran 2023, COBOL 2023, Scheme R7RS,... even those oldies embrace modern ideas.
      - miohtama 2y ago
        When we can call it Go++
      - biorach 2y ago
        No, the person you were replying to was advocating for the intersection of ubiquitous features. C++ seems to be aiming for the union.
      - School-Cotton 2y ago
mattgreenrocks 2y ago
I’m convinced there’s a contingent of devs who don’t like/grok abstraction. And it overlaps partially with stated goals of an easy language to onboard inexperienced devs with. Nothing wrong with that, but it will probably never work for me. Newer versions of Java are much more enjoyable to work with versus Go.
- ralegh 2y ago
  I guess I’m in that camp. I can come up with a good abstraction after working on a problem for a while and refactor it into my code. Or I can come up with a really simple abstraction (eg a Go interface with 2-3 methods), and that usually works well. But I try to avoid starting a project by defining a bunch of abstractions, since I just end up writing loads of boiler plate. Yes, I’m probably doing some things wrong.
  - mattgreenrocks 2y ago
    Sounds about right. Proper abstractions are difficult to get right up front, might as well pull them out only when they're obvious and profitable.
- keldaris 2y ago
  > I’m convinced there’s a contingent of devs who don’t like/grok abstraction. I am one of those. I grok abstractions just fine (have commercially written idiomatically obtuse Scala and C#, some Haskell for fun, etc.), but I don't enjoy them. I use them, of course (writing everything in raw asm is unproductive for most tasks), but rather than getting that warm fuzzy feeling most programmers seem to get when they finish writing a fancy clever abstraction and it works on the first try, I get it when I look at a piece of code I've written and realize there is nothing extraneous to take away, that it is efficient and readable in the sense of being explicit and clear, rather than hiding all the complexity away in order to look pretty or maximize more abstract concerns (reusability, DRY, etc.). This mindset is a very good fit for writing compute-heavy numerical code, GPU stuff and lots of systems level code, not so much for being a cog in a large team on enterprise web backends, so I mostly write numerical code for physics simulations. You can write many other things this way and get very fast and bloatfree websites or anything else, but it doesn't work well in large teams or people using "industry best practices". It also makes me prefer C to Rust.
guappa 2y ago
I've had to use go occasionally and it feels like the language is designed to stop me from achieving my goals. The standard library is unimpressive (to be generous), it has plenty of footguns like C but none of its flexibility. Also for some reason parenthesis AND \n are required. So you get the worse of C and python there.
- aftbit 2y ago
  You're intended to run gofmt on every save. golang is designed to be a sort of straight-jacket that forces everyone to write code in the same way (style etc) so that the junior devs can understand it clearly.
  - grey-area 2y ago
    And so that people (of any level) don't bikeshed over silly things like tabs and spaces or { and newlines. I really like this about go - that it formats code for you, and miss it in other languages where we have linters but not formatters, which is a terrible idea IMO.
    - School-Cotton 2y ago
      What mainstream languages don’t have formatters nowadays? Rust has rustfmt, C and related languages have clang-tidy, python has Black…
      - grey-area 2y ago
        I mean built in that everyone uses. There are of course third party formatters.
        School-Cotton 2y ago
        You can force everyone on a project to use a formatter just as easily in any of those languages as you can in Go, with a few lines in your CI job definitions. Whether they're third-party or not is irrelevant.
madeofpalk 2y ago
go’s error handling patterns, while lacking every established feature that makes it ergonomic, is baffling. Embarrassing that developers are still forgetting nil pointer checks in 2024.
- ziml77 2y ago
  The error handling is one of the worst parts of Go for me. Every call that can fail ends up being followed by 3 lines of error handling even if it's just propagating the error up. The actual logic get drowned out.
  - danudey 2y ago
    I would kill for some kind of `err_yield(err)` construct that handles propagating the error if it's the caller's problem to deal with. That said, I discovered that Go has the ability to basically encapsulate one error inside of another with a message; for example, if you get an err because your HTTP call returned a 404, you can pass that up and say "Unable to contact login server: <404 error here>". But then the caller takes that error and says "Could not authenticate user: <login error here>", and _their_ caller returns "Could not complete upload: <authentication error here>" and you end up with a four-line string of breadcrumbs that is ostensibly useful but not very readable. Python's `raise from` produces a much more readable output since it amounts to much more than just a bunch of strings that force you to follow the stack yourself to figure out where the error was.
    - instig007 2y ago
      > I would kill for some kind of `err_yield(err)` construct that handles propagating the error if it's the caller's problem to deal with. This is called (>>=)[0], but most of the industry is ignorant enough to call it impractical and non-pragmatic (as opposed to their pragmatic `if err`) [0] https://hackage.haskell.org/package/base-4.20.0.1/docs/Prelude.html#v:-62--62--61- https://hackage.haskell.org/package/base-4.20.0.1/docs/Prelu...
dlisboa 2y ago
> It's a language invented in 2009 by some C-people who are apparently oblivious to everything that excited PL design folks for the last 20 years (as of 2009). Is there a term equivalent to "armchair quarterback" in programming? Most programmers are already in armchairs. It's the equivalent of yelling at the TV that the ultra-successful mega-athlete sucks. I can't imagine the thought process that goes into thinking Ken Thompson, Rob Pike and Robert Griesemers are complete idiots that have no clue of what they were doing.
- biorach 2y ago
  No one said they are complete idiots. They made a deliberate decision to design a language that did not take many developments in PL design since the 70's into account. They had their reasons, which make sense in the context of their employer and their backgrounds. Many people, myself included, prefer to program with languages that do not focus so much on simplicity
  - billmcneale 2y ago
    It was not deliberate, it was ignorance. Time and again, the Go team made comments in various forums for years showing they really knew nothing about programming language development past 2000. All they knew was C and that they wanted to create a language that compiles faster than C++. That's all.
    - biorach 2y ago
      You're talking about Ken Thompson, Rob Pike and Robert Griesemers, among others. You're not doing yourself any favors.
      - deleted 2y ago
        [deleted]
      - billmcneale 2y ago
        They're great examples that just because you're good in one field doesn't mean you're good in other fields. Or even open minded.
LinXitoW 2y ago
Thank god I'm not the only one. I can still remember when the Go zealots were everywhere (it's cooled down now). Every feature Go didn't have was "too complicated and useless", while the few features it did have were "essential and perfect". I've really tried giving Go a go, but it's truly the only language I find physically revolting. For a language that's supposed to be easy to learn, it made sooooo many weird decisions, seemingly just to be quirky. Every single other C-ish language declares types either as "String thing" or "thing: String". For no sane reason at all, Go went with "thing String". etc. etc. I GENUINELY believe that 80% of Gos success has nothing to do with the language itself, and everything to do with it being bankrolled and used by a huge company like Google.
- skocznymroczny 2y ago
  I believe most successes of languages happen because of corporate backing and tooling/library ecosystem rather than language. It's not like most people are using Java because they are in love with the language features. Personally I also think that if you removed memory safety overnight from Rust, people will still use it. Rust is appealing not because it's memory safe. For some uses it is, but most people flock to Rust because it offers an alternative to C++ without fifty years of accumulated cruft. Rust is a modern language, with a well working package manager/build tool and a wide ecosystem of libraries for every usecase. Memory safety and other features are just a cherry on the top. If Rust used garbage collection I am sure it would also be very popular just because of those other things. Other languages like D or Nim tried to fit into that space also, but they don't have the budget to really make it. Most of work on those languages is done by unpaid volunteers, so there's little direction and there's a lot of one man projects.
- atombender 2y ago
  I recommend giving it a second chance. You will at least realize that the "thing string" problem isn't a problem, it's just something you find aesthetically displeasing. One thing I've learned over the years is that if you go with the grain — not against it — of a language (or any system, really), the design tends to become apparent quicker. "When in Rome," and so forth. Cultural displeasure tends to disappear if you give the native way an earnest chance rather than resisting it. For example, in the beginning, marking identifiers as public by giving them a capital letter struck me as the ugliest thing ever. I don't mind it now. It's never going to be something I love looking at, but it does have the benefit of making declarations' visibility extremely obvious. I don't think Go's popularity is due to Google at all. Google the company has never really promoted Go (unlike Microsoft with C# and Sun with Java, for example). Go is still treated as a bastard stepchild in many Google projects such as Protobuf/gRPC, Beam, and Google Cloud. The Go team has never seemed very enthusiastic about PR, either. There was that one big redesign of the Go site, but relatively little after that. I think Go grew by word of mouth more than anything. Projects like Kubernetes, Prometheus, Traefik, etc. helped a lot. Don't forget that it took years for Go to become popular. It wasn't taken very seriously by many in the beginning. Go was not popular within Google until relatively recently. For many years the only serious thing written in Go internally at Google, as I understand it, was the dl.google.com backend.
devmor 2y ago
golang feels like someone wanted to write a "web focused" version of C, but decided to ignore every issue and complaint about C raised in the past 25 years It's a very simple and straightforward language, which I think is why people like it, but it's just a pain to use. It feels like it fights any attempt at using it to do things optimally or quickly.
- randomdata 2y ago
  > which I think is why people like it Do people actually care that much about languages? I mean, we're here writing English, which is a complete dumpster fire. Go is undeniable perfection compared to the horror that is English. Clearly you and I don't care that much about languages. I expect people like Go because of its tooling (what also saves English), which was a million miles ahead of the pack when it first came out. Granted, everyone else took notice, so the gap has started to narrow. > It feels like it fights any attempt at using it to do things optimally or quickly. Serious question: Is that because you are trying to write code in another language with Go syntax? Go unquestionably requires a unique mental model that doesn't transfer from other languages; even those that appear similar on the surface. Because of that, I posit that it is a really hard language to learn. It is easy to get something working, but I mean truly learn it. While every programming language requires its own mental model, Go seems to take it to another level (before reaching a completely different paradigm). I expect that is because its lack of features prevents you from papering over "misuse" like is possible in other, more featureful languages, so you feel it right away instead of gradually being able build the right mental model.
  - devmor 2y ago
    The purpose of human language is communication of concepts between two individual thinking people. The purpose of a programming language is literal instruction for a machine. These are not directly comparable just because we use the same term to describe them. To your second point, I wholeheartedly disagree. Go is not a difficult language to learn, nor is it particularly unique compared to the type of language it attempts to emulate. In fact I think it’s one of the easiest languages to learn if you already have experience in C-likes because of how obvious it is what it’s trying to do. I think it is just a bad language. It’s simple to figure out how you need to use it, but it is obnoxious and tedious to do it in that way.
seanw444 2y ago
Man, Go gets a lot of hate on here. It's certainly not the most flexible language. If I want flexibility + speed, I tend to choose Nim for my projects. But for practical projects that I want other people to be able to pick up quickly, I usually opt for Go. I'm building a whole product manufacturing rendering system for my company, and the first-class parallelism and concurrency made it super pleasant. I will say that the error propagation is a pain a lot of the time, but I can appreciate being forced to handle errors everywhere they pop up, explicitly.
- f154hfds 2y ago
  So much of language opinion is based on people's progression of languages. My progression (of serious professional usage) looked like this: Java -> Python -> C++ -> Rust -> Go I have to say, given this progression going to Rust from C++ was wonderful, and going to Go from Rust was disappointing. I run into serious language issues almost daily. The one I ran into yesterday was that defer's function arguments are evaluated immediately (even if the underlying type is a reference!). https://go.dev/play/p/zEQ77TIP8Iy https://go.dev/play/p/zEQ77TIP8Iy Perhaps with a progression Java -> Go -> Rust moving to rust could feel slow and painful.
  - 62951413 2y ago
    I'm curious how one ends up with such ahistorical sequence. I'd expect it to be more aligned with the actual PL history. Mainstream PLs have had a fairly logical progression with each generation solving well understood problems from the previous one. And building on top of the previous generation's abstractions. Turbo Pascal for education, C as professional lingua franca in mid-90s (manual memory management). C++ was all the rage in late 90s (OOP,STL) . Java got hot around 2003 (GC, canonical concurrency library and memory model). Scala grew in popularity around 2010-2012 (FP for the masses, much less verbosity, mainstream ADTs and pattern matching). Kotlin was cobbled together to have the Scala syntactic sugar without the Haskell-on-the-JVM complexity later. And then they came up with golang which completely broke with any intellectual tradition and went back to before the Java heyday. Rust feels like a Scala with pointers so the "C++ => Rust" transition looks analogous to the "Java => Scala" one.
marcosdumay 2y ago
Whatever reasons are there for using or not the language, tokenising and parsing are absolutely not a problem you want to solve with it.
dinosaurdynasty 2y ago
I use golang for work and have done a fair amount of Rust programming. Rust feels like the higher level language. This really shouldn't be the case.
randomdata 2y ago
> But I just almost irrationally hate the language itself. That's the point. It's a rejection of the keyboard jockeys who become more concerned with the code itself than the problem being solved.
- wyager 2y ago
  Golang was created specifically so that Google could mitigate the downsides from lower their hiring standards. It doesn't have any higher design aspirations. "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." - Rob Pike I suppose in a sense this is rejecting the "keyboard jockeys", but probably not in the way you mean. You cannot separate the tool used to solve a problem from the problem itself. The choice of tool is a critical and central consideration.
  - grey-area 2y ago
    I think you're giving far too much weight to that off the cuff quote from one of the creators of Go. Really I think it's more useful to view it as a better C in the less is more tradition, compared to say C++ and Java, which at the time were pretty horrible. That's my understanding of its origin. It makes sense in that context; it doesn't have pretensions to be a super advanced state of the art language, but more of a workhorse, which as Pike pointed out here could be useful for onboarding junior programmers. Certain things about it I think have proven really quite useful and I wish other languages would adopt them: * It's easy to read precisely because the base language is so boring * Programs almost never break on upgrade - this is wonderful * Fewer dependencies, not more * Formatters for code Lots of little things (struct tags for example) I'm not so keen on but I think it's pretty successful in meeting its rather modest goals.
    - wyager 2y ago
      > Really I think it's more useful to view it as a better C But Go is nothing at all like C, and it's completely unsuitable for most of the situations where C is used. I'm having trouble even imagining what you're getting at with this comparison. The largest areas of overlap I can think of are "vaguely similar syntax style" and "equally bad and outdated type system". Pretty much everything else of substance is different. Go is GC'd, Go has a runtime, etc.
tuveson 2y ago
Fast to compile, fast to run, simple cross-compilation, a big standard library, good tooling… As ugly and ad-hoc as the language feels, it’s hard to deny that what a lot of people want is just good built-in tooling. I was going to say that maybe the initial lack of generics helped keep compile times low for go, but OCaml manages to have good compile times and generics, so maybe that depends on the implementation of generics (would love to hear from someone with a better understanding of this).
- klodolph 2y ago
  There are a million little decisions that affect compile time. A big factor here is inlining. When you inline functions, you may improve the generated code or you may make it worse. It’s hard to predict the result because the improvements may come about because of various other code transformation passes which you perform after inlining. After inlining, the compiler detects that certain code paths are impossible, certain calls can be devirtualized, etc., and this can enable more inlining. Rust is designed with the philosophy of zero-cost abstractions. (I don’t like the name, because the cost is never zero, but it is what it is.) The abstractions usually involve a lot of function calls and you need a compiler with aggressive inlining in order to get reasonable performance out of Rust. Usage of generics still results in the same non-virtual calls which can be inlined. But the compiler then has to do a lot of work to evaluate inlining for every instantiation of every generic. Go is designed with the philosophy of simple abstractions, which may come with a cost. Generics are implemented in a way that means you are still doing a lot of dynamic dispatch. If you need speed in Go, you should be writing the monomorphic code yourself. Generics don’t get instantiated for every single type you use them with. They only get instantiated for every “shape” of type.
  - sophacles 2y ago
    > Rust is designed with the philosophy of zero-cost abstractions. (I don’t like the name, because the cost is never zero, but it is what it is.) So when the generated asm is the same between the abstraction and the non-abstraction version, wheres the cost?

by krick 2y ago

pimeys 2y ago

I know, I'm on the same boat. What I realized is I just need to avoid the companies using Go and I don't really need to be vocal about my dislike. It's not my loss if others find the language useful, but for me it either solves problems I'm not interested in solving, or the language and tooling just does not make it for me. But, I can always just write Rust and be happy where I am. Or, to be honest, would not be very unhappy with F#, Haskell or Ocaml either.

meowface 2y ago
>What I realized is I just need to avoid the companies using Go What do you mean, exactly?
- leftyspook 2y ago
  I'd imagine not seeking employment at Google is a big part.
  - tempest_ 2y ago
    Go is definitely used a lot more outside of google as of late. Anecdotally I would say where a lot of companies would have used Java in the past they are now turning to go for their server-side/backend service implementations.
    - danudey 2y ago
      Also it feels like pretty much everything in the k8s/container/etc. space is go-related, which kind of makes sense.
      - guappa 2y ago
        Why does it make sense? You can implement a container in any language that can make system calls.
mistrial9 2y ago
> I just need to avoid the companies using Go and they also will avoid you! A monthly go-lang meetup in San Francisco impressed me as the only meetup I have ever been to where no one (in a crowded venue) seemed to want to talk to anyone outside their clique
- guappa 2y ago
  They don't like hearing that the new exciting feature that the new go has was already in every other programming language 10 years ago.

pjmlp 2y ago

It is worse than that, as Go initially lacked generics (introduced by CLU and ML in 1976), still doesn't do even basic Pascal enumerations (1970) rather the iota/const dance, let alone the 1990's programming language design surface. I only advocate for it on the scenarios where a garbage collected C is more than enough, regardless of the anti-GC naysayers, e.g. see TamaGo Unikernel.

Thaxll 2y ago
So every language have to implement every features released in the last 50 years?
- treyd 2y ago
  I expect it to implement features that have become ubiquitous in every other mainstream language from the last 30 years, yes.
  - Thaxll 2y ago
    That's how you end up with C++ and soon C#.
    - pjmlp 2y ago
      We also end up with C23, Fortran 2023, COBOL 2023, Scheme R7RS,... even those oldies embrace modern ideas.
    - miohtama 2y ago
      When we can call it Go++
    - biorach 2y ago
      No, the person you were replying to was advocating for the intersection of ubiquitous features. C++ seems to be aiming for the union.
    - School-Cotton 2y ago

mattgreenrocks 2y ago

I’m convinced there’s a contingent of devs who don’t like/grok abstraction. And it overlaps partially with stated goals of an easy language to onboard inexperienced devs with. Nothing wrong with that, but it will probably never work for me. Newer versions of Java are much more enjoyable to work with versus Go.

ralegh 2y ago
I guess I’m in that camp. I can come up with a good abstraction after working on a problem for a while and refactor it into my code. Or I can come up with a really simple abstraction (eg a Go interface with 2-3 methods), and that usually works well. But I try to avoid starting a project by defining a bunch of abstractions, since I just end up writing loads of boiler plate. Yes, I’m probably doing some things wrong.
- mattgreenrocks 2y ago
  Sounds about right. Proper abstractions are difficult to get right up front, might as well pull them out only when they're obvious and profitable.
keldaris 2y ago
> I’m convinced there’s a contingent of devs who don’t like/grok abstraction. I am one of those. I grok abstractions just fine (have commercially written idiomatically obtuse Scala and C#, some Haskell for fun, etc.), but I don't enjoy them. I use them, of course (writing everything in raw asm is unproductive for most tasks), but rather than getting that warm fuzzy feeling most programmers seem to get when they finish writing a fancy clever abstraction and it works on the first try, I get it when I look at a piece of code I've written and realize there is nothing extraneous to take away, that it is efficient and readable in the sense of being explicit and clear, rather than hiding all the complexity away in order to look pretty or maximize more abstract concerns (reusability, DRY, etc.). This mindset is a very good fit for writing compute-heavy numerical code, GPU stuff and lots of systems level code, not so much for being a cog in a large team on enterprise web backends, so I mostly write numerical code for physics simulations. You can write many other things this way and get very fast and bloatfree websites or anything else, but it doesn't work well in large teams or people using "industry best practices". It also makes me prefer C to Rust.

guappa 2y ago

I've had to use go occasionally and it feels like the language is designed to stop me from achieving my goals. The standard library is unimpressive (to be generous), it has plenty of footguns like C but none of its flexibility. Also for some reason parenthesis AND \n are required. So you get the worse of C and python there.

aftbit 2y ago
You're intended to run gofmt on every save. golang is designed to be a sort of straight-jacket that forces everyone to write code in the same way (style etc) so that the junior devs can understand it clearly.
- grey-area 2y ago
  And so that people (of any level) don't bikeshed over silly things like tabs and spaces or { and newlines. I really like this about go - that it formats code for you, and miss it in other languages where we have linters but not formatters, which is a terrible idea IMO.
  - School-Cotton 2y ago
    What mainstream languages don’t have formatters nowadays? Rust has rustfmt, C and related languages have clang-tidy, python has Black…
    - grey-area 2y ago
      I mean built in that everyone uses. There are of course third party formatters.
      - School-Cotton 2y ago
        You can force everyone on a project to use a formatter just as easily in any of those languages as you can in Go, with a few lines in your CI job definitions. Whether they're third-party or not is irrelevant.

madeofpalk 2y ago

go’s error handling patterns, while lacking every established feature that makes it ergonomic, is baffling. Embarrassing that developers are still forgetting nil pointer checks in 2024.

ziml77 2y ago
The error handling is one of the worst parts of Go for me. Every call that can fail ends up being followed by 3 lines of error handling even if it's just propagating the error up. The actual logic get drowned out.
- danudey 2y ago
  I would kill for some kind of `err_yield(err)` construct that handles propagating the error if it's the caller's problem to deal with. That said, I discovered that Go has the ability to basically encapsulate one error inside of another with a message; for example, if you get an err because your HTTP call returned a 404, you can pass that up and say "Unable to contact login server: <404 error here>". But then the caller takes that error and says "Could not authenticate user: <login error here>", and _their_ caller returns "Could not complete upload: <authentication error here>" and you end up with a four-line string of breadcrumbs that is ostensibly useful but not very readable. Python's `raise from` produces a much more readable output since it amounts to much more than just a bunch of strings that force you to follow the stack yourself to figure out where the error was.
  - instig007 2y ago
    > I would kill for some kind of `err_yield(err)` construct that handles propagating the error if it's the caller's problem to deal with. This is called (>>=)[0], but most of the industry is ignorant enough to call it impractical and non-pragmatic (as opposed to their pragmatic `if err`) [0] https://hackage.haskell.org/package/base-4.20.0.1/docs/Prelude.html#v:-62--62--61- https://hackage.haskell.org/package/base-4.20.0.1/docs/Prelu...

dlisboa 2y ago

> It's a language invented in 2009 by some C-people who are apparently oblivious to everything that excited PL design folks for the last 20 years (as of 2009). Is there a term equivalent to "armchair quarterback" in programming? Most programmers are already in armchairs. It's the equivalent of yelling at the TV that the ultra-successful mega-athlete sucks. I can't imagine the thought process that goes into thinking Ken Thompson, Rob Pike and Robert Griesemers are complete idiots that have no clue of what they were doing.

biorach 2y ago
No one said they are complete idiots. They made a deliberate decision to design a language that did not take many developments in PL design since the 70's into account. They had their reasons, which make sense in the context of their employer and their backgrounds. Many people, myself included, prefer to program with languages that do not focus so much on simplicity
- billmcneale 2y ago
  It was not deliberate, it was ignorance. Time and again, the Go team made comments in various forums for years showing they really knew nothing about programming language development past 2000. All they knew was C and that they wanted to create a language that compiles faster than C++. That's all.
  - biorach 2y ago
    You're talking about Ken Thompson, Rob Pike and Robert Griesemers, among others. You're not doing yourself any favors.
    - deleted 2y ago
      [deleted]
    - billmcneale 2y ago
      They're great examples that just because you're good in one field doesn't mean you're good in other fields. Or even open minded.

LinXitoW 2y ago

Thank god I'm not the only one. I can still remember when the Go zealots were everywhere (it's cooled down now). Every feature Go didn't have was "too complicated and useless", while the few features it did have were "essential and perfect". I've really tried giving Go a go, but it's truly the only language I find physically revolting. For a language that's supposed to be easy to learn, it made sooooo many weird decisions, seemingly just to be quirky. Every single other C-ish language declares types either as "String thing" or "thing: String". For no sane reason at all, Go went with "thing String". etc. etc. I GENUINELY believe that 80% of Gos success has nothing to do with the language itself, and everything to do with it being bankrolled and used by a huge company like Google.

skocznymroczny 2y ago
I believe most successes of languages happen because of corporate backing and tooling/library ecosystem rather than language. It's not like most people are using Java because they are in love with the language features. Personally I also think that if you removed memory safety overnight from Rust, people will still use it. Rust is appealing not because it's memory safe. For some uses it is, but most people flock to Rust because it offers an alternative to C++ without fifty years of accumulated cruft. Rust is a modern language, with a well working package manager/build tool and a wide ecosystem of libraries for every usecase. Memory safety and other features are just a cherry on the top. If Rust used garbage collection I am sure it would also be very popular just because of those other things. Other languages like D or Nim tried to fit into that space also, but they don't have the budget to really make it. Most of work on those languages is done by unpaid volunteers, so there's little direction and there's a lot of one man projects.
atombender 2y ago
I recommend giving it a second chance. You will at least realize that the "thing string" problem isn't a problem, it's just something you find aesthetically displeasing. One thing I've learned over the years is that if you go with the grain — not against it — of a language (or any system, really), the design tends to become apparent quicker. "When in Rome," and so forth. Cultural displeasure tends to disappear if you give the native way an earnest chance rather than resisting it. For example, in the beginning, marking identifiers as public by giving them a capital letter struck me as the ugliest thing ever. I don't mind it now. It's never going to be something I love looking at, but it does have the benefit of making declarations' visibility extremely obvious. I don't think Go's popularity is due to Google at all. Google the company has never really promoted Go (unlike Microsoft with C# and Sun with Java, for example). Go is still treated as a bastard stepchild in many Google projects such as Protobuf/gRPC, Beam, and Google Cloud. The Go team has never seemed very enthusiastic about PR, either. There was that one big redesign of the Go site, but relatively little after that. I think Go grew by word of mouth more than anything. Projects like Kubernetes, Prometheus, Traefik, etc. helped a lot. Don't forget that it took years for Go to become popular. It wasn't taken very seriously by many in the beginning. Go was not popular within Google until relatively recently. For many years the only serious thing written in Go internally at Google, as I understand it, was the dl.google.com backend.

devmor 2y ago

golang feels like someone wanted to write a "web focused" version of C, but decided to ignore every issue and complaint about C raised in the past 25 years It's a very simple and straightforward language, which I think is why people like it, but it's just a pain to use. It feels like it fights any attempt at using it to do things optimally or quickly.

randomdata 2y ago
> which I think is why people like it Do people actually care that much about languages? I mean, we're here writing English, which is a complete dumpster fire. Go is undeniable perfection compared to the horror that is English. Clearly you and I don't care that much about languages. I expect people like Go because of its tooling (what also saves English), which was a million miles ahead of the pack when it first came out. Granted, everyone else took notice, so the gap has started to narrow. > It feels like it fights any attempt at using it to do things optimally or quickly. Serious question: Is that because you are trying to write code in another language with Go syntax? Go unquestionably requires a unique mental model that doesn't transfer from other languages; even those that appear similar on the surface. Because of that, I posit that it is a really hard language to learn. It is easy to get something working, but I mean truly learn it. While every programming language requires its own mental model, Go seems to take it to another level (before reaching a completely different paradigm). I expect that is because its lack of features prevents you from papering over "misuse" like is possible in other, more featureful languages, so you feel it right away instead of gradually being able build the right mental model.
- devmor 2y ago
  The purpose of human language is communication of concepts between two individual thinking people. The purpose of a programming language is literal instruction for a machine. These are not directly comparable just because we use the same term to describe them. To your second point, I wholeheartedly disagree. Go is not a difficult language to learn, nor is it particularly unique compared to the type of language it attempts to emulate. In fact I think it’s one of the easiest languages to learn if you already have experience in C-likes because of how obvious it is what it’s trying to do. I think it is just a bad language. It’s simple to figure out how you need to use it, but it is obnoxious and tedious to do it in that way.

seanw444 2y ago

Man, Go gets a lot of hate on here. It's certainly not the most flexible language. If I want flexibility + speed, I tend to choose Nim for my projects. But for practical projects that I want other people to be able to pick up quickly, I usually opt for Go. I'm building a whole product manufacturing rendering system for my company, and the first-class parallelism and concurrency made it super pleasant. I will say that the error propagation is a pain a lot of the time, but I can appreciate being forced to handle errors everywhere they pop up, explicitly.

f154hfds 2y ago
So much of language opinion is based on people's progression of languages. My progression (of serious professional usage) looked like this: Java -> Python -> C++ -> Rust -> Go I have to say, given this progression going to Rust from C++ was wonderful, and going to Go from Rust was disappointing. I run into serious language issues almost daily. The one I ran into yesterday was that defer's function arguments are evaluated immediately (even if the underlying type is a reference!). https://go.dev/play/p/zEQ77TIP8Iy https://go.dev/play/p/zEQ77TIP8Iy Perhaps with a progression Java -> Go -> Rust moving to rust could feel slow and painful.
- 62951413 2y ago
  I'm curious how one ends up with such ahistorical sequence. I'd expect it to be more aligned with the actual PL history. Mainstream PLs have had a fairly logical progression with each generation solving well understood problems from the previous one. And building on top of the previous generation's abstractions. Turbo Pascal for education, C as professional lingua franca in mid-90s (manual memory management). C++ was all the rage in late 90s (OOP,STL) . Java got hot around 2003 (GC, canonical concurrency library and memory model). Scala grew in popularity around 2010-2012 (FP for the masses, much less verbosity, mainstream ADTs and pattern matching). Kotlin was cobbled together to have the Scala syntactic sugar without the Haskell-on-the-JVM complexity later. And then they came up with golang which completely broke with any intellectual tradition and went back to before the Java heyday. Rust feels like a Scala with pointers so the "C++ => Rust" transition looks analogous to the "Java => Scala" one.

marcosdumay 2y ago

Whatever reasons are there for using or not the language, tokenising and parsing are absolutely not a problem you want to solve with it.

dinosaurdynasty 2y ago

I use golang for work and have done a fair amount of Rust programming. Rust feels like the higher level language. This really shouldn't be the case.

randomdata 2y ago

> But I just almost irrationally hate the language itself. That's the point. It's a rejection of the keyboard jockeys who become more concerned with the code itself than the problem being solved.

wyager 2y ago
Golang was created specifically so that Google could mitigate the downsides from lower their hiring standards. It doesn't have any higher design aspirations. "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." - Rob Pike I suppose in a sense this is rejecting the "keyboard jockeys", but probably not in the way you mean. You cannot separate the tool used to solve a problem from the problem itself. The choice of tool is a critical and central consideration.
- grey-area 2y ago
  I think you're giving far too much weight to that off the cuff quote from one of the creators of Go. Really I think it's more useful to view it as a better C in the less is more tradition, compared to say C++ and Java, which at the time were pretty horrible. That's my understanding of its origin. It makes sense in that context; it doesn't have pretensions to be a super advanced state of the art language, but more of a workhorse, which as Pike pointed out here could be useful for onboarding junior programmers. Certain things about it I think have proven really quite useful and I wish other languages would adopt them: * It's easy to read precisely because the base language is so boring * Programs almost never break on upgrade - this is wonderful * Fewer dependencies, not more * Formatters for code Lots of little things (struct tags for example) I'm not so keen on but I think it's pretty successful in meeting its rather modest goals.
  - wyager 2y ago
    > Really I think it's more useful to view it as a better C But Go is nothing at all like C, and it's completely unsuitable for most of the situations where C is used. I'm having trouble even imagining what you're getting at with this comparison. The largest areas of overlap I can think of are "vaguely similar syntax style" and "equally bad and outdated type system". Pretty much everything else of substance is different. Go is GC'd, Go has a runtime, etc.

tuveson 2y ago

Fast to compile, fast to run, simple cross-compilation, a big standard library, good tooling… As ugly and ad-hoc as the language feels, it’s hard to deny that what a lot of people want is just good built-in tooling. I was going to say that maybe the initial lack of generics helped keep compile times low for go, but OCaml manages to have good compile times and generics, so maybe that depends on the implementation of generics (would love to hear from someone with a better understanding of this).

klodolph 2y ago
There are a million little decisions that affect compile time. A big factor here is inlining. When you inline functions, you may improve the generated code or you may make it worse. It’s hard to predict the result because the improvements may come about because of various other code transformation passes which you perform after inlining. After inlining, the compiler detects that certain code paths are impossible, certain calls can be devirtualized, etc., and this can enable more inlining. Rust is designed with the philosophy of zero-cost abstractions. (I don’t like the name, because the cost is never zero, but it is what it is.) The abstractions usually involve a lot of function calls and you need a compiler with aggressive inlining in order to get reasonable performance out of Rust. Usage of generics still results in the same non-virtual calls which can be inlined. But the compiler then has to do a lot of work to evaluate inlining for every instantiation of every generic. Go is designed with the philosophy of simple abstractions, which may come with a cost. Generics are implemented in a way that means you are still doing a lot of dynamic dispatch. If you need speed in Go, you should be writing the monomorphic code yourself. Generics don’t get instantiated for every single type you use them with. They only get instantiated for every “shape” of type.
- sophacles 2y ago
  > Rust is designed with the philosophy of zero-cost abstractions. (I don’t like the name, because the cost is never zero, but it is what it is.) So when the generated asm is the same between the abstraction and the non-abstraction version, wheres the cost?