15 ms·

I've written a bit of code in Go, and the problem I have with it is primarily it feels really outdated for a "modern" language - every time I use it I feel like

• dcow 5y ago
  If you’re the type of engineer who prides themselves on the raw amount of code you write, then Go is for you. If you’d rather focus on solving problems creatively and expressively, Go is not your tool. I don't mean this as slight against those people that really enjoy writing lots of (Go) code. It’s just my observation after being in a few different contexts where Go was the language of choice. Personally Go is too verbose for me and this is especially painful/apparent when you get to writing the multitude of tests required to ensure your code works since Go’s type system/compiler doesn't lend you much in the way of helping ensure code correctness. Go is essentially the new Java.
  • tacitusarc 5y ago
    This feels largely like a mischaracterization, and does not align with my experience. I'd change it to say, if you are focused on solving the problems creatively rather than using the language creatively, Go is a viable option. But if you're interested in creative usage of the language itself, Go is not right for you.
    • axaxs 5y ago
      I agree with this. Go works like my brain, and I don't mind that. Sure you can do X in some fancy way in other languages, but that just leads to feature creep. I've never read Go code I didn't understand at first glance. I cannot say that about a single other language.
      • dcow 5y ago
        And this is totally fine if you're okay reading and writing noticeably _more_ code to solve the same problems. There's nothing wrong with favoring verbosity over expressiveness, it's just not my style. I disagree that expressiveness lends to feature creep, I've personally never seen that happen, but that's another topic. For me, the verbosity of Go would be a lot more justified if it aslo had some sort of memory safety system in place (similar to Rust) that could help prevent concurrency related errors. I understand that you're supposed to used channels for everything in Go, but last time I wrote a channel heavy concurrent server the compiler did nothing to prevent me from mutating shared state across different go-routines and I was unable to land on a pure channel based implementation (I needed a run_once to initialize some shared state and a WaitGroup to track active listeners, and this was the case in all the other impls I audited/referenced as well). I just don't feel like I'm getting a lot of value in exchange for the verbosity when writing Go.
        • axaxs 5y ago
          That's a completely fair assessment. I don't fault 'you guys' at all because I don't expect your brain works like mine. Read: I don't think you're wrong and I'm right...never. What I fear myself is feature creep. A design by committee that ruins the language for me, and is never good enough for you.
• kortex 5y ago
  It feels like Option types could be done quite easily - basically slices with a hardcoded capacity of 1. Could compile down to a pointer type. But it would make linting way easier. Of course, the real power of Option comes from Map. Give Go a map and option and I'll be a happy gopher.
  • mixedCase 5y ago
    At that point why not use something F# or Rust? Both can provide comparable or better runtimes, very decent ecosystems, and they are already much better languages.
    • cdogl 5y ago
      Because Go as an ecosystem has some really attractive properties that few other languages offer in the same combination: portability, stability and a strong compatibility guarantee, quick onboarding for new learners, a robust and scaleable runtime with GC that rarely gets in your way, minuscule startup footprint, reasonable direct control of memory layout when you really need it, a fairly large developer base and corporate backing/funding that's not going away any time soon
      • mixedCase 5y ago
        So I have to repeat the question: why not F# or Rust then? None of that is too uncommon, with the notable exception that Go is better at the "quick onboarding" part since it goes out of the way offering no new concepts or syntax that have to be learnt; something that the comment I was replying to would like to change by introducing Optionals and Functors.
• flowerlad 5y ago
  > Errors as values is a far superior approach to exceptions. Why is that? I have never seen a cogent explanation for why this is the case. I can tell you why exceptions (as implemented in Java) are cool: You can write code as if every function call is successful, as opposed to adding a line (or more) of error handling code after every function call, which makes it harder to follow the logic.
  • tacitusarc 5y ago
    I think it's a little bit complicated to explain but mostly it boils down to this: errors are real. Java methods kind of let you ignore them through declaring exceptions, with this idea that, well, somebody else will deal with it. Golang functions make errors feel more present. They force you to think about how you're going to handle the errors up front, and to question whether or not you even should error in a particular instance. It's actually helped change the way I think about functions. There are many behaviors that in Java I would not have even considered making them idempotent but in golang making them idempotent is both easier and, as it turns out, more robust. The patterns for error handling the golang have introduced are admittedly verbose, but they do lend a certain element of confidence that once the code is written, the errors should be handled. Of course a programmer can ignore the errors explicitly but doing so is different than forgetting to catch a thrown exception, because the programmer must go out of their way to write code ignoring the error. It feels like there's more agency around the decision.
    • flowerlad 5y ago
      > Java methods kind of let you ignore them through declaring exceptions, with this idea that, well, somebody else will deal with it. Sure, you can write sloppy code in Java, but I am sure you can write sloppy code in Go too.
      • Mawr 5y ago
        The difference is that with exceptions sloppy code is the default. As you write code in a language with explicit errors, the language makes you acknowledge that the code you call can error out. This makes you stop and think what to do about the error. You can choose to ignore it, but that's a conscious decision that the language forces you to make. With exceptions, there's no such feedback mechanism from the language/compiler. In order to write robust code you yourself must have the discipline to add exception handlers around the appropriate calls. In short, defaults matter. It's simply easier to write correct, robust code when you don't have to go out of your way to do it. See https://devblogs.microsoft.com/oldnewthing/20050114-00/?p=36693 https://devblogs.microsoft.com/oldnewthing/20050114-00/?p=36...: > It’s really hard to write good exception-based code since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it. ... which leads us straight to favorite exceptions-caused bug: https://nedbatchelder.com//blog/202001/bug_915_solved.html https://nedbatchelder.com//blog/202001/bug_915_solved.html: > Inside tempfile.NamedTemporaryFile, the error handling misses the possibility that _TemporaryFileWrapper will fail.
• _will_cham_23 5y ago
  >> the problem I have with it is primarily it feels really outdated for a "modern" language It's mostly not about the language. An exception is of course when moving from a dynamically typed interpreted language to a statically typed compiled language. The success of projects depends much more on other things than the programming language. It's about - Processes and standards, like following a well defined structure, testing, documentation, ... - Maintainability of code. It must be easy to read, to understand syntactically and to build a mental model of the code - Long term reliability and stability of the eco system - Easy and reliable tooling - Developer efficiency, e.g. compile times Go shines in many of the aspects. Especially in maturity, stability, amazing standard lib and tooling. As you mention Rust: This is exactly where Rust falls short. Rust is a great language with amazing people behind it. But there are reasons why its adoption in the broad real world is very, very small. The reasons are not the language. So I always feel it's a bit invasive when Rust promoters enter Go or Java threads by telling how much better Rust as a language is. In this example Go has additional benefits being statically typed and compiled, very fast and with build in concurrency support.
  • siscia 5y ago
    Sorry but I need to disagree. The stability of rust is exceptional. Old code always compiles. The stdlib of Rust, I find it superior, very much so, to the one of go. Even though this is mostly due to the different type system. The tooling around rust, it is just great, what tool you feel missing in Rust? Few years ago, rust was lacking libraries, but they are really catching up quickly. They are different languages that shine in different scenarios, but maturity, stability and stdlib is not where Rust is lacking behind.
• takeda 5y ago
  Yeah, I have mixed feelings about it as well. There are some good things, but there are also ugly warts. For example if you try to use some numeric types that are not int, int32, float64 (for example float32 or uint16) you'll be in a lot of pain due to constant casting back and forth. Yes generics could solve this one too. I also couldn't make myself enjoy programming in it. I think it's because it tried to be simple, so anyone can learn it. Because of it is kind of rare to say that you created with a creative way of solving specific problem. That's very different to for example C, to which Go (at least early on) was compared to.
• jhoechtl 5y ago
  > I've written a bit of code in Go, and the problem I have with it is primarily it feels really outdated for a "modern" language Go is a language to get the job done. It's for the masses. It's this type of language you write a blog post on how you have done this and that and why instead of a scientific paper. It's really the boring mortar. OTOH it will pay your rent.
  • theshrike79 5y ago
    Exactly this. Go is the language you use when you need to get shit done, reasonably performant and easily distributed to different operating systems. The language actively hinders any attempts to be fancy or "expressive". You write (or copy/paste) the same pattern(s) over and over again. On the other hand, you can pick up pretty much anyone's Go codebase and quickly see how it works. No need to figure out what flavour of metaprogramming or other fancy crap the original author was a fan of at the time of writing. It's boring, it pays the bills. You can be expressive with other languages on your own time.
• DrBazza 5y ago
  It's a language designed with a couple of things in mind: easy to use cheap concurrency (or parallelism, or whatever you want to call it). Then there's Rust designed around low-level code and memory safety, and a much more complex syntax. I think it just goes to show that any language (modern or otherwise) is a consequence of its design decisions (or lack of).
• forgotpwd16 5y ago
  >Errors as values is a far superior approach to exceptions. Can you elaborate on that? Usually the argument on which one is better is that it depends on use case.
• skohan 5y ago
  Go isn't for programmers, it's for managers. Because of the simplicity of the language, it's easy to get people onboarded with, and it's fairly difficult for a single team member to go astray and move the codebase in a direction which will be unmaintainable. It's a kind of lowest-common-denomenator language which is easy to read, debug, and maintain, even for a mediocre programmer. That said, I think you are right about explicit nullability. A language like Go with this feature, as well as named arguments and limited ADT's could be very compelling for Go's use case.
  • danesparza 5y ago
    "Go isn't for programmers, it's for managers" I completely disagree with this statement. Some of the most high-performance modern platform-level code written is currently written in Go. It was a Google presentation that examined their efforts to convert their download site to Go (from C/C++) that got my attention. It's easier to read, has a simpler mental model, and faster than its C/C++ cousin.
    • skohan 5y ago
      I'm not sure that the points you raise contradict my thesis. Could it not be the case that a language designed primarily for making large software teams easier to manage would also lead to high-quality software at large organizations?
      • rob74 5y ago
        If the thesis is that "Go is for managers", then yes. I would wholeheartedly agree to something like "Go is not for developers who want to write clever code that others (or they themselves in a few months' time) may have trouble understanding". But Go also works for large teams (communities) of open source developers who don't have what you would usually call "management", so saying it's only for managers is definitely too narrow a statement...
        • skohan 5y ago
• pmarreck 5y ago
  > Errors as values is a far superior approach to exceptions No, it's not. Unhandled errors that aren't noticed just lead to undefined/nondeterministic behavior and some really nasty bugs. And moreover, I literally cannot understand how it is possible for any programmer to not realize this (compare: elixir's approach, which instead embraces errors and restarts processes instantly).