32 ms·

I want off Mr. Golang’s Wild Ride (2020)

• boxingrock 4y ago
• chimen 4y ago
  Before clicking the link I knew "Mr. Rust's Wild Ride" will be waiting for me on that article. Welcome to the hype train, 3rd edition: Ruby -> Node -> Rust. Everything else is just, well, inferior and I'm going to bash its brains out. Needs some "Rust" in the title.
• o_1 4y ago
  is the writer a previous Java developer?
• Zababa 4y ago
  Probably needs a (2020) in the title.
  • andrew_ 4y ago
    Not a "Go guy" but I try to keep up on the news. They've since added generics and cleaned up some of this since 2020 yeah?
    • DrBazza 4y ago
      This submission came up because the article author is on twitter today complaining about golang and posted the submission link.
      • rad_gruchalski 4y ago
        So they wanted out in 2020 and they’re still on in 2022. So either the language isn’t really that bad or they have an attention deficit?
        • richbell 4y ago
          Eh, plenty of people get stuck using technologies they hate. Perhaps the OP is forced to use it for work, or already put the time and effort into building something and cannot afford to rebuild it from scratch.
        • ModernMech 4y ago
          At the end of TFA there's an update from April 2022 that explains the author's current thoughts.
        • erik_seaberg 4y ago
          In https://news.ycombinator.com/item?id=31193260 https://news.ycombinator.com/item?id=31193260 the author clarified that he’s changed jobs twice yet “It doesn't matter that I don't personally write Go anymore: it's unescapable.” I’m also worried about this because of trends at my day job despite having joined a sharp, experienced Scala/Java team.
          • jrockway 4y ago
            I'm someone who wants to write Go 100% of the time at work, and I haven't really found a lot of companies that are doing this. All the cool kids have moved on to Rust. All the legacy code is Python/Ruby/Typescript. There is the niche in the k8s ecosystem, but I've already written all the code I need to integrate with the k8s ecosystem ;) All that's left to do are write 2000 copy-pasted operators for running super legacy apps on OpenShift, it feels like. But even with that in mind, it's not that hard to find. Whatever tech stack you like, there is a company in every industry hiring software engineers to work with that set of tools. There is just so much software in the world, it's strictly a numbers game. And if there's some industry you like that doesn't have the tech stack you want, why not start your own company? You're reading "startup news" after all ;)
      • styluss 4y ago
        Link?
        • fasterthanlime 4y ago
          Here it is: https://twitter.com/fasterthanlime/status/1519455555517136902 https://twitter.com/fasterthanlime/status/151945555551713690... (source: am fasterthanlime). No idea what HN's policy is on posting links to Twitter, but since you asked. Also if the consensus here is that that 2020 rant is "unfair and toxic", that twitter thread is not going to go over well either!
          • LandR 4y ago
            I agree with you about Go. I hate it, but we started it using it at work because it's "easy". It's also easy to walk across a busy road without checking but it's still a fucking stupid thing to do.
          • burnished 4y ago
            I quite like your 2020 rant. I also quite like Go. I think you make your points quite well even if I don't feel compelled to feel the same way you do after reading them. A detailed, finnicky, nitpicky critique like this makes for good insightful reading.
• cfors 4y ago
  Previous Discussions: https://news.ycombinator.com/item?id=25616593 https://news.ycombinator.com/item?id=25616593 https://news.ycombinator.com/item?id=22443363 https://news.ycombinator.com/item?id=22443363
• andrew_ 4y ago
  > It is a minefield of subtle gotchas that have very real implications Perfectly describes my 10+ years with the Node ecosystem. Not that it's a bad thing necessarily. I've made it my niche and the knowledge I've accumulated has made for a great career. But still, I understand the narrative.
  • moralestapia 4y ago
    Could you share a few of them?
    • jitl 4y ago
      - Most Node code I encounter that uses “streams” gets something wrong. Usually minor, sometimes major stuff like forgetting errors exist altogether, or to reject a promise wrapper when an error occurs. - Incorrect use of concurrency stuff like process.nextTick. This function probably doesn’t do what you think it does based on the function name - it won’t “yield to the event loop”. - for years Buffer and friends was totally busted, these days Buffer has deprecated insecure APIs and uses an internal object pool to avoid the worst of performance issues. - until Node 12, async stack traces didn’t work and needed to be copied manually for understandable errors. - anecdotally, whenever I review a popular library I often find some issue where the library papers over incorrectness in order to expose a simpler, more appealing API. For example when I reviewed the popular NPM package execa for executing subprocesses, it put a NodeJS stream based on a Unix pipe into the subprocesses stderr with no way out, even when you request it to connect the parent process stderr directly. This will break with EPIPE if the subprocess writes too much data. But who cares, we get to see stderr in the exception thrown if the command fails, so that’s a nice choice for adoption. For a taste of how easy and common it is to get this kind of thing wrong, look at this issue in execa from 2019 - stream error handling leads to unresolved promise that hangs forever. Very hard to blame a programmer for using this API wrong. It is so easy to use wrong, and so hard to use correctly. https://github.com/sindresorhus/execa/issues/350 https://github.com/sindresorhus/execa/issues/350
      • christophilus 4y ago
• marc_from_ibg 4y ago
  * * *
  • valcron1000 4y ago
    I disagree. I've used Golang just once and I got frustrated with a lot of things mentioned on this post and I don't even write Rust.
  • duckerude 4y ago
    I don't think this article intends to give a full appraisal of Go. It highlights the downsides of a particular philosophical stance Go takes. That stance is very much real, even if it's best described by gesturing at half a dozen examples. And it's nothing new, really. It's just Worse is Better all over again. I think it's instructive to see how it plays out in Go. This rant is one-sided, but it doesn't pretend to be otherwise.
  • jitl 4y ago
    I don’t think this rant is toxic - there’s no personal attacks or rude words of any sort, and the tone is lighthearted - but it is all criticism. Maybe that’s enough to qualify it as toxic. However, the author has real Go bonafides, he wrote many of these libraries: https://github.com/itchio?q=&type=all&language=go&sort= https://github.com/itchio?q=&type=all&language=go&sort= I presume working on the above software burned some deep scars. Their switch from Go to Rust is motivated by this kind of issue. (To be honest, I also stopped writing Go for fun because these kinds of paper cuts build up. I enjoy Go when writing stuff in its sweet spot - dealing mostly with network bytes in a server environment of my choosing. For me, venturing too far out of that domain is joyless, but not exactly painful.)
  • Sparkenstein 4y ago
    I am curious, please do send the fair evaluation, or the mistakes in this post if there are any.
  • zamalek 4y ago
    > toxic The author presents things about the language that they don't like. How on earth is that "toxic?" Have we reached the point where "toxicity" is just "things I don't like hearing?"
• lumost 4y ago
  My Anecdotal Experience: Golang is great for spinning up new services and tools with very little overhead, the language is well designed for the backend - and the lack of <insert programming language feature here> avoids "odd" decisions which other engineers will dislike in the future. If your job is building lots of new things using relatively common building blocks, then Golang looks fantastic! However on mature services, engineers often need <insert programming language here> because they are dealing with something extremely complex. The author of this blog post digs into the scenario for a package which needs to support different non-nix operating systems, but the same can be true of an app which has to manage many different kinds of objects (Kubernetes, or any service with many DAOs). Alternately there are engineers building all kinds of weird software which may do new things in novel simplified ways. Golang occasionally makes expressing these types of applications more difficult. Overall I enjoyed my time writing go, until I tried to write a statistics based application for a startup idea back in 2016. The project didn't get very far, and that was partly due to me getting bored having to deal with all of the different numeric data types, at the time the lack of generics made it so that you either had to use reflection - or implement the same function N times over to support the different numeric data types. This tedium killed my love of the language (I'm sure it's a better experience in 2022).
  • oversocialized 4y ago
    Seems too many devs use go for something it is not meant for. Tried doing math calculations in go - not a good a idea. But for backend stuff like rest api, web servers, networking, sysadmin and devops tasks, it shines.
    • Cthulhu_ 4y ago
      I mean, a lot of developers have or look for a golden hammer, coerce their favorite language in doing a task. And since every programming language is turing complete, it CAN work, but whether it's the most elegant is not guaranteed. I mean for math, similarly, Java and co wouldn't work very well either.
      • 4y ago
• greybox 4y ago
  I've been using go for a personal project for a few months now and it didn't take very long for me to run into the: > It is a minefield of subtle gotchas that have very real implications The generics problem isn't solved with the introduction of generics either. What they have introduced feels limiting in ways that will solve none of the problems that I have had to deal with by using large amounts of code replication to avoid having to use reflection. I like go because it provides a good WebServer STL, besides that, for my next web project I'm going back to using C++ or Erlang.
• deleted 4y ago
  [deleted]
• phoehne 4y ago
  Everything is a question of tradeoffs. I have to deal with cross-platform Go code on a small project at work. The requirements are modest and the Windows file system code is mostly for developer testing. The production system is Linux. Yes, it's sometimes not pretty and Go was clearly designed for Posix style file systems. We chose Go is that it is fairly high level, it gets the job done, and we don't have to worry about what's in the runtime on the box (e.g. library or package dependencies). It suits our needs. The other options we have (e.g. statically compiled, native C/C++, Rust, or more weirdos like Ada) just aren't as fit for the job. I also ran into the same problems using Afero for unit testing. Moral of the story - pick the right tool for the job or abstract it out a layer and make it fit better.
  • akira2501 4y ago
    Engineering is the art of compromise. The compromises I make to work in Go are easily paid off in what Go allows me to do and for the amount of effort it requires. Language wars are silly.
    • samhw 4y ago
      "Language wars are silly" doesn't mean that only negative views are silly, and that we should all be blindly positive about every language. Evaluating our tools properly is a good and desirable thing to do.
• HL33tibCe7 4y ago
  Could this post be unflagged please? I don't think it satisfies any requirement for flagging.
  • gjsman-1000 4y ago
  • carapace 4y ago
    You can try emailing hn@ycombinator.com
  • justinzollars 4y ago
    @dang
    • bob1029 4y ago
      You usually need to send an email to the site administrators to get their attention. This information is available in the FAQ: https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html
  • chernevik 4y ago
    Off-topic, but HN needs review of flagging abuse. Maybe assign flagging privileges only to those with X reputation, and revocation if on review the privilege is abused? It seems that flagging is as much "I don't like this" as "this is not appropriate". Likewise downvoting. Maybe instead display both downvotes and upvotes, so people can see if a comment is found controversial?
    • thrower123 4y ago
      This is how the system already works...
      • chernevik 4y ago
        The FAQ does mention a karma threshold to flag links, so sorry about that. Perhaps that threshold should be raised. It doesn't mention revocation of flagging permission for abuse, and I think that would be helpful.
• badRNG 4y ago
  Why was this post flagged?
  • taneq 4y ago
    I was asking the same question until I scrolled a little further down and it appears that there are some hurt feelings down there.
• CraigJPerry 4y ago
  This should not be flagged, this is a well written article
• gambler 4y ago
  Go has a lot of issues. Some of them would be easily fixable if people promoting and developing Go actually admitted the problems. However, the fanbase usually acts as a cult pretending that issues are features. Thing is, just like broken, hackish dependency "management" had to be fixed (introducing tons of complexity for the sake of not destroying backward compatibility), other problems will have to be fixed as well. It will add even more complexity to the language. For example, Go error handling is shit. People will attempt to fix it with generics now and that will create a lot of inconsistency between different APIs. Because of those inconsistencies the entire language will loose any possibility of elegant, high-level, pre-packaged solutions for certain things (like automated logging, recovery, etc.) This loss will be permanent and the vast majority of users won't even understand why some things are so hard.
  • deleted 4y ago
    [deleted]
  • throwaway894345 4y ago
    I mean, all programming language communities are partial to their language, but among Go there seems to be an unusual tolerance for disagreement and discussion of language issues compared to most other programming languages. But yeah, when you come in guns blazing talking about how certain language features are "shit" and there's no possibility of elegance, people are rightly going to think you're not there for any sort of productive conversation. For example, I regularly have productive conversations with people in the community about error handling and sum types and generics, including my criticism for the way Go does some of those features. A little civility goes a long way, and this isn't particular to the Go community or even programming language communities in general. Note that there definitely are PL communities that generally can't handle any criticism irrespective of civility, but the Go community isn't among them. Indeed, in my experience, Go's critics are very often much more zealous than its proponents.
    • burnished 4y ago
      Huh, I had sort of found the opposite, that the Go community I had interacted with was more aggro and prone to offense. I'm forming this opinion from the reddit and the discord though, so if there is another community you favor I'd genuinely love to hear about it.
• 0xdeadb00f 4y ago
  To say go's simplicity is a lie, then to go and and say this; > This function signatures tells us a lot already. It returns a Result, which means, not only do we know this can fail, we have to handle it. Either by panicking on error, with .unwrap() or .expect(), or by matching it against Result::Ok / Result::Err, or by bubbling it up with the ? operator. What the hell? I'm not a rust dev. I have no idea what half of this means. "bubbling up"? What the fuck even is that?
  • Rygian 4y ago
    "Bubbling up" is the default in C++, when the code you call throws an exception and you don't have a try/catch for it.
    • taneq 4y ago
      Do C++ people actually call it "bubbling up"? I don't think I've used a language where this isn't the default behaviour so I'm not sure I've ever heard it given an actual name, it's just what happens when you don't catch the exception - it keeps going until someone does catch it, or it hits the runtime and demolishes your program.
      • dgritsko 4y ago
        I've heard "propagating" the exception used as well.
        • taneq 4y ago
          Now that you mention it, I think this is the term I've heard for it when it has been mentioned. The exception propagates upwards.
      • NavinF 4y ago
        Yes, but not just in C++. Bubbling up errors is a common phrase in Java and Python.
• gwbas1c 4y ago
  Why is this flagged? I read the first page or so. I don't think I'm going to read it to the end, but it doesn't seem something that should be removed from the HN frontpage.
  • everybodyknows 4y ago
    It was originally posted without the (2020) disclosure, having been posted at least twice in past years. Doing so looks like "karma-farming".
• baby 4y ago
  Golang is great because it was the first to include excellent tooling in addition to the language (strict compiler, linting, non-customizable gofmt, package manager, good html docs, online playground, etc.) It’s undeniable that it brought a lot of good ideas that languages like Rust borrowed. Golang is still undefeated in terms of battery included. Its standard library is top notch and full featured. On the other hand it is more high-level, has a GC, and has made a number of mistakes (no sum types). The biggest trade off it does though: it lacks expressiveness. The new generic will probably help, but the trade off of Golang is deep. It makes writing code harder so that reading is easier.
  • lliamander 4y ago
    Java and Erlang both have phenomenal tooling, especially when it comes to runtime introspection and debugging.
    • Cthulhu_ 4y ago
      I'd say Java and the JVM is the most overcomplete language and ecosystem out there when it comes to available tooling.
    • aarbor989 4y ago
      I've had nothing but negative experiences debugging elixir honestly. In a large project, trying to step debug is just way too slow
  • mongol 4y ago
    What is meant with expressiveness in this context?
    • baby 4y ago
      Generics, sum types, macros, functional programming stuff, basically things that allow you to do more things
  • jdc0589 4y ago
    this is a bit part of it for me. Most of the tools you need for average development, triage, perf analysis, etc... are included out of the box.
• deleted 4y ago
  [deleted]
• rayiner 4y ago
  Relevant: https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html See also Chapter 9 of: https://web.mit.edu/~simsong/www/ugh.pdf https://web.mit.edu/~simsong/www/ugh.pdf
• nmilo 4y ago
  I see this point everywhere about Rust's union types and it always kind of irks me: > The point is, this [Result type] makes it impossible for us to access an invalid/uninitialized/null Metadata. With a Go function, if you ignore the returned error, you still get the result - most probably a null pointer. It's all about framing. You can just as equally say it is "impossible" to access an invalid Go FileInfo, because you'll get a panic for derefencing a null pointer. Or you can just as equally say it is "possible" to access an invalid Rust Metadata, just by doing .unwrap(). Everyone knows an unchecked .unwrap() is just bad Rust code, but then again dereferencing a pointer without checking the returned error is just bad Go code. Anyways the rest of the article seems like just a criticism of Go's file system API, which seems fair but also seems a little niche given how difficult it is to create a good cross-platform file system API. This particular point irks me though: > stat "$(printf "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98")" > fmt.Printf(" %s\n", e.Name()) > It... silently prints a wrong version of the path. What did you want it to do? The author even admits go strings are just byte slices, not UTF8, and then passes a non-UTF8 string to a function that expects UTF8. If there's a chance the file path your program works with might not be UTF8, then you should validate it. I think moving the complexity UTF8-ness out of the type system was a necessary evil.
  • jen20 4y ago
    `Result<T, E>` is just one possible use of enumerations ("union" types as you're calling them). The beauty is that you can make illegal states unrepresentable.
  • shadowgovt 4y ago
    The difference is what the language makes easy to do and how it signals to you you're about to do something dangerous. If you call `.unwrap()`, that's a big yellow flag that you're going to be taking the gloves off and maybe touching something radioactive. Go has the maybe-radioactive thing sitting right there; safely touching it and unsafely touching it look exactly the same. I generally enjoy using Go, but this is one of the pieces of the language design that I was surprised Go went with; we've known as an industry for decades that including bare null / nil / undefined / whatever we want to call it without type-system assistance is leaving a bare third rail lying around.
• earthboundkid 4y ago
  A two year old rant that everyone saw the first time about a language which has subsequently changed significantly is not in any sense "hacker news." It is "old hacker opinions."
  • tialaramex 4y ago
    Which will be why the linked post has a section "April 2022 Update". > I wrote this in 2020, and have changed jobs twice since. Both jobs involved Go in some capacity, where it's supposed to shine (web services). It has not been a pleasant experience either - I've lost count of the amount of incidents directly caused by poor error handling, or Go default values.
• fasterthanlime 4y ago
  Author here: I wrote this in 2020, have changed jobs twice since. Both jobs involved Go in some capacity, where it's supposed to shine (web services). It has not been a pleasant experience either - I've lost count of the amount of incidents directly caused by poor error handling, or Go default values. If folks walk away with only one new thought from this, please let it be that: defaults matter. Go lets you whip something up quickly, but making the result "production-ready" is left as an exercise to the writer. Big companies that have adopted it have developed tons of tooling around it, use all available linters, do code generation, check the disassembly, and regularly pay the engineering cost of just using Go at all. That's not how most Go code is written though. I'm interested not in what the language lets you do, but what is typical for a language - what is idiomatic, what "everyone ends up doing", because it is encouraged. Because that's the kind of code I inevitably end up being on-call for, and I'm tired of being woken up because of the same classes of preventable errors, all the time. It doesn't matter that I don't personally write Go anymore: it's unescapable. If it's not internal Go code, it's in a SAAS we pay for: and no matter who writes it, it fails in all the same predictable ways. Generics will not solve this. It is /neat/ that they found a way to sneak them into the language, but it's not gonna change years of poor design decisions, and it's definitely not gonna change the enormous amount of existing Go code out there, especially as the discourse around them not being the usability+performance win everyone thought they would be keeps unfolding. As I've mentioned recently on Twitter, what makes everything worse is that you cannot replace Go piecemeal once it has taken hold in a codebase: its FFI story is painful, the only good boundary with Go is a network boundary, and there's often a latency concern there. Lastly: pointing out that I have been teaching Rust is a lazy and dismissive response to this. For me personally, I have found it to be the least awful option in a bunch of cases. I am yearning for even better languages, ones that tackle the same kind of issues but do it even better. I like to remind everyone that we're not out there cheering for sports team, just discussing our tools. If you're looking to reduce the whole discourse to "X vs Y", let it be "serde vs crossing your fingers and hoping user input is well-formed". It is one of the better reductions of the problem: it really is "specifying behavior that should be allowed (and rejecting everything else)" vs "manually checking that everything is fine in a thousand tiny steps", which inevitably results in missed combinations because the human brain is not designed to hold graphs that big.
• uuyi 4y ago
  I don't dislike Go myself but it taught me something important purely due to timing. It's the first language I wasn't late to the party for and got to watch grow up. But I also watched people skilfully build the same towers of excrement that exist on all other platforms and languages, yet again, in exactly the same way with very little innovation or thought. The end game is that Go is just another loop in the endless cycle of technology replacement which we fail to improve on. Ergo the language, tooling, wild ride is almost irrelevant and we should look at what we're building with it.
• eklavya 4y ago
  WTF is going on in this thread? How did we become so sensitive, Haskell has had a lot of criticisms here at HN, never saw any flags/downvotes. People argued vehemently but without any animosity. Maybe something to be learned here https://youtu.be/iSmkqocn0oQ https://youtu.be/iSmkqocn0oQ
  • zemo 4y ago
    it's probably the fourth time this article has been posted and people are tired of it
• tmp_anon_22 4y ago
  If you try to use a language for absolutely everything its going to struggle somewhere. You have to use a language for what its good at, and have structure in place to make using a better language for a job practical whether thats by hiring/training or by building in some kind of ABI layer from the ground up. Go is really really good at some things. Its alright at others. Its awful at others.
• klodolph 4y ago
  Yes, the cross-platform stuff sucks on Windows. I’ve seen languages with a few different approaches, I’d like a moment to compare them here. I’m going to talk about some specific aspects of cross-platform compatibility but not attempt to compare one single aspect across many platforms. With C++, you can use the preprocessor to give you a string type which is UTF-8 (nominally) when compiled on Unix and UTF-16 (nominally) on Windows. This is… okay-ish, workable, but I’m unaware of any good libraries that do this for you. Instead, you’re basically on your own. It’s not horrible, it’s not great, you spend some time writing interfaces to work on Windows (if you are doing anything specific). There’s no C++ “mkdir” call, for example. (Maybe there is in C++75 or whatever. They keep adding things. There was no “mkdir” in C++ for, like, 30 years.) As a side note, there is something in C++ called “wchar_t” and “std::wstring” which is basically complete garbage and only ends up being used because somebody, in the past, wrote code that used it and now you are stuck with it. There’s a whole story here. With C# and .NET, the APIs seem to be designed with Windows as the norm, and Unix/Unix-like systems are an afterthought with some shim for portability. You can take a look at System.Diagnostics.Process for one of the worst offenders. Anything involving pipes is just not doable with the .NET process spawning interface, as far as I can tell, because it wouldn’t match the Windows semantics. You also can’t even roll your own process spawner without great difficulty, because you can’t safely call fork() from C# (not a surprise). With Go, the APIs are designed with Unix as the norm, as discussed in the article. With Rust, the APIs are carefully designed to give you a subset of functionality that is present on both Windows and Unix. As a result, the available functionality is (IMO) garbage, kind of like wstring in C++. In short, with OsString / OsStr in Rust, you get a string that is hard to manipulate. In the effort to make it safe and cross-platform, it’s been made into something like an opaque box for strings, and it’s missing 90% of the typical API that you’d find on a useful string class. In an effort to make sure that you don’t pay any unnecessary cost for conversion to/from Rust strings, the subset of OsString that are valid Unicode strings can be typecast at zero cost to Rust String / &str types—but this means that the encoding of these strings doesn’t match the Windows encoding at all. F'ing bizarre. Honestly I do not think that there is any easy out here, at all. If you care about running on Windows, and you care about providing a good experience on both Unix-like and Windows systems, then you should embrace the fact that any cross-platform API that abstracts the differences away will be imperfect, and just ask yourself what tradeoff you think is appropriate to get a better experience on Windows and Unix-like systems. I’ll also add that while macOS provides a fully functional, fully usable POSIX API, that doesn’t mean that this API is the best option for performing low-level tasks on macOS. In particular, you should probably be going through the NSFileManager API when possible if you really care about macOS, because this provides higher-level functionality that is tricky to implement yourself—the “correct” way to do certain operations is different depending on the semantics of the underlying filesystem. I’m just going to finish with the note that if you want to handle the pathological edge cases when using strings in a cross-platform application, you are in for quite the wild ride. Even something really simple as “I want to list all files in a directory and send the result to a client in JSON format” is just, well, a nightmare, if you are committed to handling all the edge-cases.
• b20000 4y ago
  TL;DR use C++
• SAI_Peregrinus 4y ago
  I find it's often useful to analyze the extreme endpoints of something to get a feel for an issue. Making a language too simple makes using it difficult. Too much of the inherent complexity of real problems ends up needing to be written by the users, and re-written every time (or results in massive dependency trees). For the extremes of simplicity, the Binary Lambda Calculus[1], [2] Brainfuck, and similar "Turing tarpits" show that the simplest of languages are extremely difficult to use. Making a language too complex makes using it difficult. When there are lots of ways to do any given thing, you need to know all the ways to be able to read code "in the wild". You end up with languages like C++ that are really 3 or more nice languages standing on each other's shoulders in a trench coat. Or PERL, where "There Is More Than One Way To Do It" makes it into a write-only language. Go errs towards simpilicity, and IMO goes too far. Rust gets things reasonably towards the middle, but there are unfortunately a few areas where "There Is More Than One Way To Do It" is rearing its ugly head. The edition system helps to keep this in check: while the compiler will always compile older code, and you can link older code to newer, a new edition can deprecate old syntax/functions/etc for files written in that edition. [1] https://tromp.github.io/cl/Binary_lambda_calculus.html https://tromp.github.io/cl/Binary_lambda_calculus.html [2] https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck
• jeroenhd 4y ago
  I see Go as a language for some use cases on some Unix platforms. It was clearly designed early in the current iteration of "modern" programming languages and I firmly believe that Rust, for example, learned a lot from the mistakes Go made. My impression is that Go as a language tries to make things simple, but things aren't always simple. Time and date operations are hard and simplification leads to I correctness. If you just want to show a nicely formatted number, you don't want to care about wall time, you want to show a number that's good enough. Go gives you something that's probably good enough. It's not correct, but who cares? For the purposes of the people who made Go you don't need correctness. Same with the permissions. Permissions are hard, especially on flexible systems like Windows. Unix pretends these problems don't exist and Go as a languages tries to pretend Windows is just a weird flavour of Unix. For most use cases, this is fine; read only is normally the only flag you care about as a developer and read only is something the API will give you. If you want something correct, go get a library or something. Then the path issue. Paths are hard. Path separator APIs are hard, especially if your standard library doesn't like using the operating system's standard methods for dealing with paths. Most paths are UTF8-compatible strings. Sure, Windows is UTF-16 and plenty of real-world file systems don't even have UTF support at all, but most file systems used by most users are compatible enough. If your file system shows you weird bytes, that's either a mistake or you're using some kind of complex, incompatible encoding (some Asian languages have these still in use). Go is simple, you're either the common use case or you're wrong. This all makes Go quite simple to work with for many use cases. It simplifies your computer and makes some of the decisions for you. That's not even a bad thing if you're using it as a replacement for hacky shell scripts and messy Python tools, because people usually ignore the real life complexities of computers in there too. For a system that's supposed to be correct, I wouldn't even think about using Go, because it chooses simplicity over correctness. For something that I kind of, sort of, probably want to just work most of the time, the language works fine. Sure, the code looks like drunk Python combined wirh endless checks to see if err is nil, but it works. It's very easy to get productive with Go if you can get over the language itself. Just go in with the right assumptions. Similarly, don't go into C or Rust if you want a simple programming language. Rust is trying to be correct, or even pedantic, more than it's trying to be simple. Writing correct code is verbose and annoying and dense languages like Rust will easily allow you to write an unreadable mess. C, on the other hand, will let you do your own thing: whenever there's any kind of complexity, the language shrugs and says "you probably should check this but if you don't, well, let's just call it undefined behaviour and move on". It could be correct, or it could not be and you'll probably never know for sure. There are tons of simple programming languages, even ones that do the correctness deal better than Go. Take a look at C# and Java (or if you want to feel like you're writing modern code, maybe Kotlin), with platforms made to work on Windows and Linux with their crazy quirks. Go isn't a universal solution because no universal solution exists.
• Mawr 4y ago
  The author fundamentally misunderstands language design. He picks an arbitrary design constraint, in this case correctness, and argues that any language that does not provide 100% correctness is bad. He uses Rust for his examples, a language that has correctness as one of its top design goals, and contrasts it with Go, for which correctness is not that important. So of course Rust will come out on top when the only metric you care about is correctness. As usual with such one-sided rants, the downsides to the supposed clearly right alternative are omitted. How long would it take for me to learn Rust + write a given program vs Go? How long does it take to model problems 100% correctly vs merely well-enough? > It [Go] constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness. Yes, exactly. Optimizing for the 90% case, not simplicity, is the primary design goal of Go. In other words, pragmatism or the 80/20 rule. Go attempts to provide 80% of the benefit for only 20% of the cost. This is pervasive throughout the language: - the author's examples, - a GC, - merely good-enough error handling. The sweet spot Go attempts to strike between speed of coding, correctness, safety, performance, and mental overhead is the reason it's so polarizing. You may like this approach or not, but let's not pretend that Go is all bad or that say Rust is some perfect holy grail that will save us all.
  • sfvisser 4y ago
    The author clearly does understand language design. He probably even agrees with your description of go above, but simply describes it really doesn’t work for him.
  • fasterthanlime 4y ago
    What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctness underpins /everything/, it's not a hobby), I can't help but notice you carefully use the word "attempt" when referring to the promises Go /does/ make. One of the things I'm saying is that Go does not deliver on those. It does not deliver on "speed of coding", precisely because everyone, even seasoned Go developers, keep hitting its many design pitfalls. It does not lower mental overhead, because it prevents you from building abstractions, and pushes complexity out of the language and into your head. There's a lot to be said about safety and performance, which gets bleaker real quick once CGo enters the picture (hence why the Go team likes to remind folks that CGo is not Go). But say we disagree there and you truly find it a breeze to write large amounts of Go code: as soon as you deploy something to production and others start to rely on it: you don't get to choose not to care about "correctness". If you don't, you're just pushing the problem onto someone else. You may be pushing the problem onto ops people, other devs, or your customers, but it does land on someone. And nowadays that someone is often me: my frustration is fueled by years of real world use, I do not, like you seem to imply, enjoy thinking about these things in the abstract, just for the fun of it. Of course, you can choose to ignore that too, and that's fine! But let's please drop the pretense that this kind of response is anything other than "I refuse to think about this".
• kretaceous 4y ago
  I've been learning go over the past 3 weeks. This made me kinda sad in a way. I have similar (and much less angry) complaints with Go as a beginner. My main gripe is not having proper error handling (try-catch maybe) and lack of default parameters. (Anonymous function without parameters when passed as an argument to another function) would be a nice to have too. There are some instances I feel that the makers of Go don't want to share the internals because that would be "unnecessary syntax". Want default parameters? Don't have those. So how does make() work? It's a language construct. Obviously I'm not going to stop learning as I think it's the easiest language to make small/standalone binaries in and, I love the syntax, the native tooling, the performance, the easy concurrency, etc. It's a worthy tool. But I really hope some of obvious language quirks get acknowledged and fixed by the Go community. And I really hope I don't regret. I haven't really learnt it in depth but it has been easier so far than whatever language I've tried learning it in.
• bjourne 4y ago
  A lot of the criticism is fair but not the part about runtime os detection. It is vastly preferable over conditional compilation since it is much easier to test. With conditional compilation you introduce code paths that are only traversed on, say, Windows. If most developers use, say, Linux you will introduce difficult-to-debug system-dependent bugs. This goes for similar things like SIMD-extensions too. If possible, use runtime checking over conditional compilation.
  • DenseComet 4y ago
    What? Even with runtime os detection, you won't be running linux code paths on windows. However you do it, you can't test linux apis on windows or windows apis on linux natively.
    • bjourne 4y ago
      Yes, you can accomplish that using proxies and/or using the Wine libs.
  • jen20 4y ago
    Platform specific code is typically implemented in Go using build tags, which are a less flexible form of conditional compilation.
• 0xbadcafebee 4y ago
  I miss Perl. It has everything I like in a language. Mystic runes that do really complex things with just 1 extra character of code. Switch between procedural, OO, and functional programming anywhere. Rewrite the language itself if you feel like it. C/ASM extensions for speed. Reusable, inheritable, extendable modules rather than quirkily-named modules that nobody can build on top of. Extremely thorough warnings, errors, debugging, and documentation. Hybrid and duck typing. First-class regex support. One-liner conveniences. But an entire generation never really learned the language, and subsequently churned out dog vomit that looked like Perl syntax, so the whole language became a pariah. But I have at least 10x the productivity with Perl compared to any other language.
  • christophilus 4y ago
    What do you think of Raku?
• t43562 4y ago
  "Cross platform handling is bad." That's all I've had the energy to extract. Isn't cross-platform software always a nasty compromise between not being able to do anything useful and being too specific to some OS or another. IMO go write a library if it really annoys you. There are much more unpleasant problems that I've had with the language but I've had more with C++ so ... it's a step up for me.
  • notriddle 4y ago
    Read to the end. It eventually talks about monotonic clock bugs that affect every major platform, including Linux.
• mcculley 4y ago
  I am both bemused and empathetic for those who keep having this realization with Go. It is like an abusive relationship and people stay in it too long before realizing it is not going to get any better. I took a look early on at Go. I tinkered with it and decided it would not work for me. It lacked a lot of things that any new language should have, given the lessons learned in language design over the last few decades. It was clearly the result of a lot of NIH syndrome. It was built by Plan 9 guys to solve their problems on their preferred platform. For their purpose, I am sure it works just fine and is very comfortable for them. To expect it to be adapted to other kinds of problems and platforms is just wishful thinking. For years, I have been hearing that Go will get generics and that it will be easy to add and use. I was working with Java before and after generics and saw what a mess it made to not design it in from the beginning. This made me skeptical that Go with generics would be as good as it could be. Now Go finally has generics and many are not happy. This should not be surprising. This is why I see it as an abusive relationship. That partner you are so fond of is not going to change. Accept that and stay or move on.
  • klodolph 4y ago
    I don’t get the “abusive relationship” metaphor. It just seems like the “abuse” metaphor is an attempt to stir up emotions. Every language has its own weird way of doing things. You decided Go wouldn’t work for you? Ok, I get it. People who stick with Go are in an “abusive relationship”? Seems like an attempt to stir up a flame war more than anything else. I’ve never encountered a language that I’m 100% happy with. It’s always been about cataloguing the tradeoffs. I’ve even designed my own domain-specific languages a few times—languages that are laser-focused on solving a small set of problems that I have. It seemed impossible to design a language that would even solve my narrow set of problems in an ideal way. I was always making tradeoffs, from the syntax to the semantics. I’d make syntax for one thing slightly simpler, and then I’d realize that I introduced some ambiguity, so I can make the parser way more complicated, or I can make the grammar way more complicated, or maybe I try again. Over and over again, “simple” changes in small languages turned out to be diabolically complicated. There are plenty of languages that I’ve personally just stopped working with because I can’t deal, personally, with the design decisions. Java is one. Haskell is one. (And the reason I gave up Haskell is all about finalizers, FFI, and the library ecosystem, it’s not about types or the language itself.) Rust is another, but I check in every once in a while to see if Rust has improved. I’d love to give up on C and C++, but realistically, there are too many existing libraries that I want to work with, and it’s often more fuss working with FFI than to just write C++ in the first place. And just to speak about Go… there’s a small hobby community I’m in. People build their own tools to get things done. There are tools written in Go, and there are people who complain that the tools are written in Go. They think Go is awful, they hate it. But the complainers (in this particular community) don’t seem to be writing any tools themselves. Instead, we keep getting new tools, written in Go. The history of language design is the history of people making decisions about how to design their language, and then discovering that the decision had unintended consequences, like, five or ten years later.
• zemo 4y ago
  ZZzzZzzz I'm so bored of this article and I'm so bored of this author picking out extremely specific arguments about how things aren't exactly perfect for exactly his need, but moreso than anything I'm so bored of this culture of takedown posts being taken super seriously just because they're takedown posts, articles that are thirty pages long when they could be three or four, and the back-and-forth with cartoon characters blog posts. > I've been suffering Go's idiosyncracies in relative silence for too long, there's a few things I really need to get off my chest. this notion that because someone designed a tool in a way that is not exactly the way you wanted it to be is a form of suffering is ridiculous. You're not suffering, you are at best mildly inconvenienced. > Most of Go's APIs (much like NodeJS's APIs) are designed for Unix-like operating systems. This whole angle of attack is frankly absurd. Go's APIs (and the APIs of countless other ecosystems) are Unix-like because the Unix-like ecosystem is structured around interoperability. The reason that Go's APIs for dealing with Windows aren't as good as for other systems is that Microsoft has at every turn made their environments subtly different from other things often for no good reason at all. This whole thing with making a file path with arbitrary byte strings that aren't representable in utf-8 is frankly embarassing. He's spinning a yarn about filesystem APIs and then goes on a tangent about string handling and how great it is that Rust displays one thing and Go displays another, but here's the rub: he used the `%s` format string operator, whose entire function is to print the uninterpreted bytes; if you want to print something quoted in a string-safe manner, you use `%q`. That entire section can be summarized in three lines of code: s := "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98" fmt.Printf("Hello, %s\n", s) fmt.Printf("Hello, %q\n", s) https://go.dev/play/p/NVbLMhb7UkV https://go.dev/play/p/NVbLMhb7UkV His examples are always like this: long, convoluted, and so complicated that people who know what's going on don't bother to interject because it's an impossibly tedious waste of time.
• daviddever23box 4y ago
  Blaming a language such as Go for poor software design choices is like yelling at a garden spade, in ASL. I've seen some well-written library code that is kept up-to-date, and I've seen some crufty libs that, frankly, would barely pass muster on an internal code review. A good litmus test is to check the linting configuration for a given library repository, as well as the frequency by which a given library is updated. And none of these are anything that an experienced developer wouldn't do otherwise, regardless of the code. To the original poster-sorry your life has been beset by having to clean up the messes of others, though you will find this to happen again and again. Grow up a little–some engineers might see this as an opportunity to make their corner of the world a better, more functional place, whereas a younger, more entitled engineer might expect everything to be perfect on day one (HINT: it isn't).
  • fasterthanlime 4y ago
    If your idea of a "grown up engineer" is one who fails to notice systemic problems and diligently, repeatedly hits themselves in the head with a rake because that's the way it's always been done, we have very different ideas.
    • daviddever23box 4y ago
      Systemic problems may be organizational (i.e., a company and/or culture of sloppy code) and may have little to do with the language used.
  • oneepic 4y ago
    https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman
• cosmiccatnap 4y ago
  Seems like he has more of a bone to pick with the windows filesystem than he does GO. Sadly he gets close to the answer but doesn't quite cross the finish line to realizing his issues are a result of limitations of windowsisms.
  • josephcsible 4y ago
    The issue isn't that the Windows filesystem doesn't support all of the UNIX features. The issue is that Go pretends nothing's wrong and just silently does the wrong thing when you try to use said features anyway.
• bawolff 4y ago
  For an angry rant against the language in general, this seem like arbitrary minor critiques, largely involving trade offs where there is no right answer but the author prefers the other one and refuses to acknowledge the trade offs involved. My opinion of go did not change after reading this.
• jeffreyrogers 4y ago
  Go's main selling point is that it is extremely easy to deploy and it has good standard libraries for most routine programming problems. It works really well for providing web services running on Linux, but I can see why you wouldn't like it if you were running on Windows.
  • shakezula 4y ago
    My main takeaway from the blog post was really how much Windows sucks, not that Go is bad haha
• dimgl 4y ago
  I liked the article. I think it was really well written and these are great points. So if not Go, then what's the alternative? I too am starting to feel a bit burnt out by some of Go's deficiencies, but one of the things I really like about Go is its concurrency model. What other languages have great concurrency models? Please keep in mind that I want to keep things simple... having a single binary to deploy is incredibly efficient. I've been wanting to use Crystal. Does anyone have experience running Crystal in production? Without getting into the specifics, the Go parts of my personal project are a websocket server that upgrades when a user is authenticated and authorized, and their actions spawn jobs in a queue. I have processors (written in Golang) that take these tasks and perform somewhat complex async actions. Would Crystal fit the bill here? I'd really like to avoid getting into Elixir/Erlang world or any kind of interpreted language that will complicate the deployment process (like Deno or Ruby).
  • nicoburns 4y ago
    Rust is the obvious language to consider. It’s concurrency model is arguably better than go’s as it actually statically prevents you from misusing types that aren’t threadsafe.
    • dimgl 4y ago
      To be frank I really don't want to deal with Rust's complexity.
  • christophilus 4y ago
    I’ve kicked the tires with a lot of languages, and always end up coming back to Go. It’s a pretty subpar language, but it hits a sweet spot that nothing else does: fast builds, decent tooling, relatively small single binary deployment, pretty good performance out of the box, decent stdlib. I could go on. I want to use Ocaml or a Lisp or a number of other languages, but Go really does the entire package better than anything I’ve looked at.
  • aelzeiny 4y ago
    Nobody will suggest Java, but honestly Java. Java has pretty great flexibility when it comes down to concurrency. It sets the standard which all the other languages have to compete with. Apart from that, I like languages and frameworks that scale out of their box and into the world of distributed systems. Elixir is very cool, because the concept of distribution with message passing is built into the core of the language. Alternatively, Scala's Akka Framework operates on a similar concept of passing messages to Actors. My bias here is that I don't like to deal with very large super-computers, and would rather have multiple smaller machines that are allowed to blackout occasionally. This is especially relevant for websockets because the stateful connection to a client can be made on any single machine in a cluster, but the state itself is (often) global.
• judofyr 4y ago
  This is a long blog post which is a huge rant, and honestly I find the whole tone extremely unproductive. # Point 1: Judging a tool (programming language) out of context (project) For some reason programmers really like to talk about the merits of programming languages without specifying anything about the context you're using it in. This article talks a lot about how Go handles its Windows support, yet the conclusion is not "I'm done using Go for projects that require Windows support". No, the conclusion is "Go is bad". I've seen this "argumentation" so many times: - "I used programming language X on project Y." - "Programming language Z works much better for project Y." - "Therefore Z is better than X." We should talk more about when it makes sense to use a certain programming language instead, and less about trying to declare that a language is "stupid" or "worse than another". # Point 2: Simplicity is about assumptions The article has a nice catchy headline called "Simple is a lie". Ironically it immediately points out that the statement "Simple is a lie" is also a lie: "Or rather, it's a half-truth that conveniently covers up the fact that, when you make something simple, you move complexity elsewhere." Go models the world from a Unix perspective, and it provides a compatibility layer for Windows. This means that … … if you run it on Unix, everything will behave as expected. … if you use the basic functionality on Windows, everything will behave as expected. … if you use functionality which does not make sense on Windows, it will try to fake it and it will kinda make sense. … you can't idiomatically take advantage of Windows-only features. This is a simple model. And there's nothing about this simplification which is a "lie" or a "half-truth": It's simple for a programmer to program against this model. This is of course not a universal model. It's a model which works great if you're only developing against modern Linux and MacOS. It's a model which works if you want to support basic functionality on Windows as well. It's a model which will cause your program to behave weirdly on Windows in many edge cases. And those "edge cases" might be more common in the real world than you think. The article spends a lot time showing how Go's model break apart on Windows. And yes, that is indeed the cost of a simpler model: When you don't follow the assumptions then unexpected things will happen. At this point the conclusion could be "don't use Go if you need Windows support", but for some reason the article instead brings in another language (Rust) and starts showing how Rust is solving this "better" than Go. (Spoiler alert: They introduce their own abstraction instead.) And there's still no context: Are we only talking about programs that need to run on Windows? Are we talking about all programs that you can write in Go? Are they trying to demonstrate that Rust is a "better" language even when I'm concerned about a Unix command-line tool? # Point 3: The monotonic clock Turns out there's really hard for a programming language to guarantee a monotonic clock (see Rust). Go's take a simpler approach: If you need a monotonic clock then it's up to the OS to take care of it. Is it a good solution or a bad solution? I dunno. It seems pretty reasonable to expect that the OS can take care of it. I can't really come up with any project in Go where this has impacted me in any possible way.
• mause_piep 4y ago
  What would be a good alternative to Go, with - large and well maintained standard lib - great runtime characteristics - esp. reasonable memory usage - developer ergonomics - matureness - long term stability - preferably managed memory I really have used a lot of languages. They all have some downsides. I like Kotlin a lot but the JVM is just to cumbersome and resource heavy. Grade is way to complex. Rust is way to cumbersome to write and lacks the standard lib. The only one that comes to my mind is actually .NET Core (C#). But I don't know mature it is on Linux for your standard backend.
  • christophilus 4y ago
    I really like C#, and F# is one of my favorite languages. I just really hate having to manage csproj files, and I miss Go’s compilation speed and compact binaries. C# is pretty decent on Linux, though, so I’d at least kick the tires a bit.
  • mikevin 4y ago
    I'm not up to date on Core but .NET/C# on Windows with Visual Studio is by far the best development experience I've ever had. It's so mature and well integrated. If Core offers 10% of that I'd highly recommend looking into it.
  • kaba0 4y ago
    How is the JVM cunbersome? I do understand your concern about it using more memory (though I feel it is often overblown. Sure, it’s not a hand-optimized C executable, but the performance is top-notch and the memory usage can be very well controlled)
    • christophilus 4y ago
      The binaries you get from GraalVM are bigger than Go's and if you are doing something like hosting a bunch of little services on a cheap VPS, Go definitely is nicer there.
  • andag 4y ago
    I've been tempted to consider kotlin + graalvm as an option as well. Graalvm is getting pretty cool, but it does add some complexity, and it's too tied to Oracle in my opinion... C# might be cool again as well though, haven't really considered that since before .NET core. (And I think Go is ok, but I find coding in kotlin more enjoyable)
• xg15 4y ago
  I'm baffled that the Go designers for a long time basically considered generics to be harmful - but had no problems adding reflection to the language.
  • scottlawson 4y ago
    Reflection is essential for things like code generation and introspection in go. It isn't something you can classify as wholly harmful. It is of course possible to write bad code using reflection, but not having reflection isn't the solution. https://go.dev/blog/laws-of-reflection https://go.dev/blog/laws-of-reflection
    • xg15 4y ago
      I'm a java guy mostly, so I might be biased, but in that language, the vast majority of overengineered, arcane and plain "black magic" code was involving reflection - whereas I almost never had a problem with generics. So I'm surprised that Go considers generics more harmful than reflection.
• AtNightWeCode 4y ago
  The utterly poor decisions made by the GO team over decades tells the story that stupid stubbornness is more important than practical use of the language. How could one not address the obvious problem with the lack of generics directly. Why is the stupid AND ERROR PRONE ERROR HANDLING NOT FIXED? Along with this the GO team make breaking changes for performance. Amateurs basically.
• tastysandwich 4y ago
  Golang has generics now and I'm already using them. They're great! But that's an obvious point. I use Golang professionally every day, and these aren't the sorts of things that I run into. Then again, we run everything on Linux. One thing I wish Golang had was the ability to easily deep clone things. Especially if you have a struct with nested struct _pointers_. Options now are manually doing it field-by-field (error prone, if a new field is added you might miss it); using reflection (yuck!); or marshalling to JSON and back again. Another thing is when reading to/from JSON, being able to differentiate between a field which doesn't exist ("undefined" in Javascript), or is null. Unfortunately some third-party APIs I interact with treat "null" as a command to remove the field. But if you use `omitempty`, you can't have null at all. Other than that though, it's a treat to work with!
• deleted 4y ago
  [deleted]
• deleted 4y ago
  [deleted]
• likortera 4y ago
  I think Go is a great tool, if you use for the problems it was intended to solve. Replacing something you otherwise would have built with C, C++ or maybe Java. The problem is when people try to use it for *everything*, like web applications or just the backend of web applications, where you need a TON of "webby" stuff such as dealing with sessions, authentication, orms, validations, translations, etc.... for these use cases boring and (more dynamic) languages such as Python, Ruby, PHP or JavaScript are much better options. If you use Go because otherwise you'd had to use C or C++ and you're writing a database, a DNS server, a command line application, or some hardcore infrastructure service, it's an awesome tool and a big improvement, definitely go for it, will make everything easier. If you use Go because of hate against other languages and because it is better for everything than everything else and only dinosaurs are using scripting languages, etc, etc (my experience with most people around me using Go) then you're using the wrong tool.
• SanderNL 4y ago
  I can definitely tell the author put a lot of time and energy into this article and is generally more intelligent than I am so I'm absolutely not trying to be difficult here, but I.. how to put it.. well, disagree. Kind of. It's complex. You are raising valid engineering concerns. You rightly point out that the handling of permissions on Windows is subpar and Go really sucks balls when it comes to handling files named '\275\262=\274 ⌘'. I mean, it's hard to disagree here and I don't. It's just hard to shake the feeling these things, in practice, just. do. not. matter. These are issues you solve once with an as ugly-as-needed solution and stow away in a package with a clean interface. I agree, it's not pretty and it would be awesome if the language would have handled this better by default but it just doesn't. Handling of files called '\275\262=\274 ⌘' is not going to convert me to Rust, which while generally awesome also its own - different - set of major issues. Everything is a trade off and Go just sometimes wins, even if it also sometimes sucks. The point is that the stuff it sucks at is usually not important for the domain it's meant to shine in. I'm sorry, handling files on Windows.. I don't know what to say. "I'm sorry" is all I can think of.
• kat_rebelo 4y ago
  Go is interesting because it has a cult like following of advocates who spout the same sound bites all the time, yet seem completely oblivious to the larger world out there. Go seems to be in this weird space where it is not particularly suited for anything that its proponents say it is. As a systems programming language it gets a lot of flack for being garbage collected. As a web programming language, it is not ergonomic at all. The process of simply formatting a string is ridiculous compared to the string interpolation of Python or Scala. Furthermore, if I was a web developer, why would I want to deal with the cognitive overhead of Arrays vs. Slices or pointers? The type system also takes a lot of heat, mainly for generics but that seems like something that is coming soon to the language. Nevertheless, it is sort of telling that Kubernetes decided to implement its own internal type system instead of leveraging the OO paradigm provided by the language.