9 ms·

I hesitate to say I thought this was a good article because it was highly negative and I don't think it focused enough on the positives (of which I think there

• slimsag 4y ago
  so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc. I've heard they're great languages (haven't used them much myself), but I probably wouldn't choose them for say an early-stage startup. Go's value is in being a mundane, repetitive, boring language. It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable. There's a theoretical gradient of programming languages where one side is "has a single expression for exactly your problem, a single unique expression you've never heard of exists to solve every possible problem" and the other is "requires thousands of expressions to express your problem, but only a thousand are available" - or something like that. My point? There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language, the real devil / tradeoff is in the fact that conformance to a single language (or set of languages) is such a strong social phenomena. I think that's why people end up so angry with viewed-as-subpar languages like Go gaining so much traction: it limits personal choice of which language to work in. I'm positive linguists aren't happy with English becoming the global language either, but you've gotta admit - having a global language is valuable.
  • halfmatthalfcat 4y ago
    Having written a lot of Scala, I generally agree until you can form a team that knows what they're doing or has a background in Scala. After that, Scala shines as the codebase(s) scale.
    • ttfkam 4y ago
      Substitute Scala for any other programming language and the statement still holds. Experienced developers and those with specific language expertise excel when implementing in that language. Who would have expected that? /s
      • halfmatthalfcat 4y ago
        The point is the barrier to entry for Scala is higher but once you have a skilled team working in Scala, you probably get more velocity than others due to the language ergonomics.
        • sidlls 4y ago
          I don't think there are any (many?) studies on this subject. Much less that confirm this particular bias you've shown.
  • Thaxll 4y ago
    Scala and Haskell are pretty much "dead" language, I worked with Scala in the past, it was impossible to find poeple willing to work with it so everything was re-written in Java.
    • pjmlp 4y ago
      I bet plenty of universities will keep using them beyond our lifetimes. From that point of view they are doing quite well.
      • 4y ago
• monkey26 4y ago
  You sum up my 3-4 years writing in Go. I’m going to have to point people to this comment. Thanks.
• karmakaze 4y ago
  > highly performant lightweight threads with full blocking semantics via goroutines If you've ever tried to doing any actual high-performance work using the Go mantra "share by communicating" with channels, you'll quickly find that it isn't high performance. Any Go program that actually needs high performance will break all the rules for thee and use undocumented things like sync/atomic.
  • kgeist 4y ago
    Interestingly, even though Go is most popular for writing web services and promotes channels, we almost never use channels in our microservices written in Go because they are not persistable. If you care about not losing your data on power loss or a panic, your work queues have to be persistable and retriable. Channels IIRC are just in-memory queues with mutexes under the hood and provide nothing of that. We only use them for a few tricks/hacks like listening to signals to safely stop goroutines.
    • tptacek 4y ago
      That makes sense: channels are a way of organizing concurrent programs, not a way of organizing distributed systems. They're a tool you might use to build a persistent work queue (or, like many programmers, including people working on the Go stdlib, you might use other synchronization constructions), not a work queue themselves.
      • kgeist 4y ago
        When I first learned Go, my impression (and also tutorials usually imply that) was that they are a nice elegant way to build concurrent pipelines where goroutine A sends work items to goroutine B which can, in its turn, send some work items to goroutine C etc. But in practice for robustness we prefer persistent queues for such pipelines because on power loss, a panic, or if your application is simply being killed on redeploy, your program can lose data or end up in an inconsistent state, because whatever was the in the channels is completely lost (and the work is already half done). So it leaves us with only a few use cases where they're really useful such as basic goroutine coordination. I think what you are saying is that they're a synchronization primitive akin to mutexes, atomics etc., no more no less, and I'm fine with that, but then it's not clear why then channels have a special syntax and why they are sold as one of Go's strong points, if it's just a niche synchronization primitive. The only useful case I found for them was to send an empty struct to a goroutine to signalize that there's a new work item in the persistent queue, to avoid having to poll the external queue too often. I wonder if other web devs have experience similar to ours, or maybe there are other use cases for channels we are not aware of.
• _0w8t 4y ago
  The sad part of lack of sum types in Go is that the select operator is kind of a typical sum type operation to pick up one of sum type branches. So the language has this notion, but it is extremely limited.
  • nu11ptr 4y ago
    Yep, and multiple return types are like tuples, minus the ability to compose them and actually use them as a single type. Map and lists were generic, but a special kind the user couldn't make (fixed now I think w/ generics in 1.18). 'range' worked over a magic iterator, but not one you could ever make. Their "enums" are variable bindings minus the ability to be sum types or any other decent property of an enum. Nil is nothing more than "None" or "Empty" in an Option type, but since they didn't use the type system you can get a classic null pointer exception. Their "attributes" are just comments, but now you need to remember their special formatting since each one is effectively arbitrary text. In so many instances, they made things "special" to avoid bringing in a concept, but you have to learn that concept anyway, but now as a special case. It is almost as if they said "we can have 5 features and I don't care what #6 does..it is out...we must make a language with 5 features!". Instead of saying: "What is a reasonable set of features that compose well, are logical, expressive, and relatively simple such that people can both easily learn and scale their code bases". A great example is Brainfuck. Everyone would agree it is 'simple' and it only has 8 constructs, but it is not 'easy' to write programs in. 'simple' is not the right metric for a language.
    • maleldil 4y ago
      Go is a great case for why simple doesn't mean easy.
  • throwaway894345 4y ago
    This is one of the warts I wish Go would fix (implementing Rust-like enums, and ideally getting rid of zero values and nils, but these things won’t happen). Even still, Go is the most productive language I’ve used because it turns out type-systems (cool though they are) are overrated—you only need enough of a type system to keep things documented for humans and tools. 95% type safety seems to be the sweet spot (peak productivity) after which productivity begins to rapidly diminish. It’s more important to have decent performance, good tooling (simple with sane defaults), small learning curve, great deployment story, etc.
• typesanitizer 4y ago
  > I don't think it focused enough on the positives (of which I think there is some - for example, it has very nice and highly performant lightweight threads with full blocking semantics via goroutines). I've tried to focus on things that I ran into. I haven't had the chance to write a lot of concurrent code in Go, that's why I didn't comment on this aspect. Most of the code I've been working on has been serial, with concurrency and parallelism managed at a different layer than the one I was working on. That said, the same point applies for a bunch of negative points that you may seen in other articles criticizing Go. I didn't mention them because I didn't run into them in practice.
• lmarcos 4y ago
  > I think I would say overall that I like the idea of Go better than I like Go itself. I like the idea of a simple language, but not the choices they made. I like the idea of simple tooling, but don't find their tooling simple to use I think I just had a revelation moment. This is exactly how I feel about Go. I keep trying to use it for side projects and I think I'm lying to myself... It's not Go what I like, but the idea of it.
• matthewmacleod 4y ago
  Yeah, I think your view here is pretty close to the way I feel. It's unfortunate, because I think Go generally gets a lot of stuff really right. But it too often feels that it prizes simplicity in implementation or specification over simplicity of how code is read and written. Writing Go feels like having a little rock in my shoe. I think it comes from that situation where you know some property of the code you are writing (e.g. "this thing cannot be null"), but there is no method to assert this to the computer. And so instead of my very fast and logical computer with lots of memory enforcing this for me, I have to carry that knowledge around in my own lossy memory as a little bit of baggage and hope I never put it down and forget about it. And I find that this comes up in Go all the time. That sucks because Go is still—despite all this—probably the best overall solution for the kind of apps I end up writing a lot. I really do think that there's still a space in there for a language sitting on the complexity scale between Go and others around the level of Java/Swift/Typescript, which can benefit from both some excellent design decisions of the former, and some of the expressiveness- and correctness-enhancing features of the latter.
• dap 4y ago
  It’s a funny thing about simplicity. It’s easy to make something simple by foisting the complexity on the consumer. A lot of Go’s features are simple in that they take few words to explain, but using them uncovers so many edge cases that they wind up being quite complex.
  • tptacek 4y ago
    You say "a lot". What's your third example?
• twblalock 4y ago
  > I like the idea of a simple language, but not the choices they made. That’s the problem with simplicity, and it’s why kitchen-sink languages like Java will always be popular. People complain about the complexity of Microsoft Office too — they only use a subset of the features. Why does it need to be so complicated? Because every customer uses a different subset of the features, and what you end up with is the combined superset of what everyone wants.
  • chakkepolja 4y ago
    > That’s the problem with simplicity, and it’s why kitchen-sink languages like Java will always be popular. Java is not kitchen sink. Scala is. And Go is quite popular than Scala or Rust, which would count as more kitchen sink. I believe what matters is immediate applicability for some purpose, which oftwn means some amount of 'kitchen sink'.
• More-nitors 4y ago
  regarding null: google's Dart recently got type-level null-safety. Maybe that's planned for Go too? I mean, they're both made in google, so...
  • deleted 4y ago
    [deleted]
• parasense 4y ago
  > I think I would say overall that I like the idea of Go better than I like Go itself. I like the idea of a simple language Agree. I'm new to GO, and I keep bumping into language issues that upon further inspection where unilateral "opinionated choices" made by some secretive cabal. Don't get me wrong, I see plenty of public discussion, but ultimately some core GO team person abruptly closes the issues. Perhaps I'm exaggerating a bit, but there have been several times I've tracked an issue report to find the issue closed without sufficient discussion. For example, The whole thing with exported vs unexplored things using the uppercase first character. This is both brilliant, and simultaneously prejudicial. The brilliant part is one need only to look at a variable's name to understand it's exported, rather than exhaustively searching for the declaration where something like "exported" reserved word was used... Instead the first character carries that information. But... many languages do not have the concept of upper/lower case... Or the related issue of variables declarations or aliases having to be a Unicode "letter", and the designations of Unicode letters being narrowly defined in ways that prevent folks using their native language. To elaborate, that means there is no possibility to write GO in a world language like Chinese, Japaneses, Arabic, Hindi, Russian, etc.. The language must have the properties of 1) being letters, not having any non-letter modifiers, and having upper case letters. The problem is many languages have funky characters that are technically symbols (not letters) in Unicode, but are used in combination with Unicode letters to modify the meaning of a word. Similar to accents, or whatever hats go above some Latin characters, other languages have a whole other symbol left or right of the character to do similar things. But variables may only contain "letters". So to rephrase this issue, GO is an English programming language, which ironic because one of it's creators was purportedly one of the people involved with creating UTF-8 as a replacement for ASCII, and yet GO is saddled with issues similar to how ASCII limited C way back in the days. So it's like these neck-beards propagated their biases and prejudices into the GO language. Another criticism I've got pertains to GO's understanding of numbers. I'm so tired of numbers being an emergent property of the underlying hardware architecture. You know, when we went from 16bit to 32bit, and again from 32bit to 64bit... GO has perpetuated the silly idea of tying number types to the underlying architecture hardware architecture, and that has silly effects on writing portable software. In the year 2008 (GO's approximate inception) or the year 2022 it's entirely feasible to have numbers mean one thing always, and the runtime does the needful to ensure that number just works with respect to the underlying hardware. In your lifetime, there is a very real chance we may see the emergence of 128bit architectures, if anything for the expanded arithmetic,or expanded register size, less so for the absurdly huge memory address space. But now we are locked in to how GO was conceived at it's inception.... I would really like to use a language like the idea of GO, but not GO itself. It's seem s evident GO will not break the compatibility promise/contract to improve the lang or reverse bad choices, and the utterly brilliant people designing & implementing GO apparently hold bad opinions. I've seen this before in so-called meritocracies, you tend to see brilliant ass-holes fizzle to the top. Don't get wrong, nobody on the CO core team is an ass-hole, I'm obviously exaggerating to convey my point... it's a variation of reduction-absurdum fallacy.