5 ms·

I'm amused by posts like this because it shows that Go is finally slowly moving away from being an unergonomically simplistic language (its original USP?) to ad

• eptcyka 1y ago
  How is the boxed interface problem enabling better ergonomics for Go? I find that most quirks listed here are not making the language any better.
  • OvervCW 1y ago
    In this specific blog post I suppose only "Ranging Directly over Integers" counts, but I was more generally referring to the introduction of features like generics.
• 0x696C6961 1y ago
  If you think Go and C are that similar then you don't know either.
  • quietbritishjim 1y ago
    Go and C have partially shared origins. Two of the three creators of Go (Ken Thompson and Rob Pike) were involved in the early days of C. Ken Thompson is even the creator of B, the predecessor of C. There are obvious huge differences between the language but in a more subtle way they're actually quite similar: C is an "unergonomically simplistic language", just as the parent commenter describes Go.
    • 0x696C6961 1y ago
      Pike was not involved with the design of C. He was involved with Newsqueak and Limbo which inspired Go's concurrency model.
  • OvervCW 1y ago
    They are similar in the sense that there are very few abstractions, relying on the programmer to reimplement common patterns and avoid logical mistakes. You have to put thought into such things as: - Did I add explicit checks for all the errors my function calls might return? - Are all of my resources (e.g. file handles) cleaned up properly in all scenarios? Or did I forget a "defer file.Close()"? (A language like C++ solved this problem with RAII in the 1980s) - Does my Go channel spaghetti properly implement a worker pool system with the right semaphores and error handling?
    • 0x696C6961 1y ago
      > Did I add explicit checks for all the errors my function calls might return? You can easily check this with a linter. > Are all of my resources (e.g. file handles) cleaned up properly in all scenarios? Or did I forget a "defer file.Close()"? (A language like C++ solved this problem with RAII in the 1980s) You can forget to use `with` in Python, I guess that's also C now too eh? > Does my Go channel spaghetti properly implement a worker pool system with the right semaphores and error handling? Then stop writing spaghetti and use a higher level abstraction like `x/sync/errgroup.Group`.
      • OvervCW 1y ago
        >Did I add explicit checks for all the errors my function calls might return? You can check anything with a linter, but it's better when the language disallows you from making the mistake in the first place. >You can forget to use `with` in Python, I guess that's also C now too eh? When using `with` in Python you don't have to think about what exactly needs to be cleaned up, and it'll happen automatically when there is any kind of error. Consider `http.Get` in Go: resp, err := http.Get(url) if err == nil { resp.Body.Close() } return err Here you need to specifically remember to call `resp.Body.Close` and in which case to call it. Needlessly complicated. >Then stop writing spaghetti and use a higher level abstraction like `x/sync/errgroup.Group`. Why is this not part of the standard library? And why does it not implement basic functionality like collecting results?
        • 1y ago
• pjmlp 1y ago
  Unfortunely given that the authors are also related to C's creation, it shows a common pattern, including why C is an insecure language. > Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own. From https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist... Go grew up from the failed design with Alef in Plan 9, which got a second chance with Limbo on Inferno. https://en.wikipedia.org/wiki/Alef_(programming_language) https://en.wikipedia.org/wiki/Alef_(programming_language) > Rob Pike later explained Alef's demise by pointing to its lack of automatic memory management, despite Pike's and other people's urging Winterbottom to add garbage collection to the language; https://doc.cat-v.org/inferno/4th_edition/limbo_language/limbo https://doc.cat-v.org/inferno/4th_edition/limbo_language/lim... You will notice some of the similarities between Limbo and Go, with a little sprikle of Oberon-2 method syntax, and SYSTEM replaced by unsafe. https://ssw.jku.at/Research/Papers/Oberon2.pdf https://ssw.jku.at/Research/Papers/Oberon2.pdf
• deleted 1y ago
  [deleted]
• petralithic 1y ago
  More like, let's throw away the last 75 years of programming language theory advances, only to rediscover them again ourselves, with much hardship.
  • DarkNova6 1y ago
    Sounds Like „Tell me about Generics in Go without telling me about Generics in Go“
    • OvervCW 1y ago
      No need to talk about generics when we can talk about something simple like the inability to implement type safe enums in Go.
• DanielHB 1y ago
  I remember when I first got out of uni and did backend Java development, I thought I was incredibly productive because of the sheer amount of typing and code I had to pump out. After doing a bit of frontend JS I was quickly dissuaded of that notion, all I was doing was writing really long boilerplate. This was in the Java 6 days, so before a lot of nice features were added, for example a simple callback required the creation of a class that implements an interface with the method (so 3 unique names and a bunch of boilerplate to type out, you could get away with 2 names if you used an anonymous class).
• liampulles 1y ago
  As a Go developer, I do think that I end up writing more code initially, not just because of the lack of syntactic sugar and "language magic", but because the community philosophy is to prefer a little bit of copying over premature abstraction. I think the end result is code which is quite easy to understand and maintain, because it is quite plain stuff with a clear control flow at the end of the day. Go code is the most pleasant code to debug of all the languages I've worked with, and there is not a close second. Given that I spend much more time in the maintenance phase, it's a trade-off I'm quite happy to make. (This is of course all my experience; very IMO)
  • miohtama 1y ago
    How much is premature in time? 10 years? 20, 30 years?
    • liampulles 1y ago
      So for me, the question is: are these two things intrinsically the same or coincidentally the same? If it is intrinsically the same, then an abstraction/centralization of logic is correct. If they are coincidentally the same, then its better to keep them separate. Its premature if I don't know the answer to that question with my current information, which is a common scenario for me when I'm initially writing a new set of usecases. If I get a 3rd copy of a thing, then its likely going to become an abstraction (and I'll probably have better understanding of the thing at the time to do that abstraction). If I don't get a 3rd copy of that thing, then its probably fine for the thing to be copied in 2 places, regardless of what the answer to my question is.
      • ted_dunning 1y ago
        On the other hand, when your abstraction has more configuration options than methods, it is a sign that (years ago) it really wasn't an abstract at all.
        • liampulles 1y ago
• deivid 1y ago
  C at least has const ptr. In go I've seen pointers mutated 7 levels down the callstack. And of course, the rest of the sphagetti depended on those side effects. C is so limited that you would try to avoid mutation and even complex datastructures. Go is "powerful" enough to let you shoot yourself much harder. Go with `const` and NonNull<ptr> (call it a reference if you need) would be a much nicer language