4 ms·

Go seems like a really great balance between speed, ease of code and safety. I keep trying to get into it, but I keep bumping into half finished/abandoned libr

Go seems like a really great balance between speed, ease of code and safety. I keep trying to get into it, but I keep bumping into half finished/abandoned libraries for basically anything I try to do. Tried to use it for machine learning: couldn't find a parquet library that supported compression and after going around that couldn't find any good lib for Dataframes and even after that, couldn't find anything good enough for gradient boosting. Tried to use it to manage some GPG encrypted utils I use for work and create a TUI. Well, the GPG lib was outdated and wouldn't do what was needed. I'm eventually going to try a go at go (pun intended) again, but I'll be more weary this time arround.

peddling-brink 3y ago
To a certain extent, you’re trying to do things that are not strengths for the language ecosystem. The available libs and its intended purpose line up nicely when you go to create little system utilities, tools, backends, etc. You generally have to define your own data structures and implement your own algorithms. For the above activities, I’d go to Python. To create a tool from the ground up, Go.
- alternatex 3y ago
  No bias against Python but it's an odd suggestion in a thread about performance. I'd imagine devs springing for Go aren't picking it because of its massive ecosystem, but because they want the performance it offers. Especially devs commenting on a thread about its performance benefits.
  - imachine1980_ 3y ago
    Edgedb use python, you can have perfotmant c code wrapped in python
    - pjmlp 3y ago
      Yeah, but then it is C code wrapped in Python, not Python.
paholg 3y ago
I don't have a ton of Go experience (intentionally), but I don't find it very good for ease of code or safety. It's a simple language to a fault, but I would not call it easy. There are so many footguns in the language itself and the standard library. I just reviewed a PR that added a bunch of `defer response.Body.Close()` calls after http requests to fix leaks. I don't know why Go is allergic to RAII, but I hate it. I also find it very hard to read. There's so much boilerplate sprinkled throughout everything, it's hard to follow what code is actually doing. While I am very in favor of a good static type system, I think dynamically typed languages like Ruby or Python win over Go by any metric except speed.
- benhoyt 3y ago
  I think those are worthwhile criticisms ... right up until you said "Ruby or Python win over Go by any metric except speed". As someone who has written a ton of Python and a ton of Go (and likes both languages), I still prefer Python for small scripts due to its terseness and beautiful syntax. Side note: Go's static typing is so much better than Python's type annotations. Python typing is difficult to use and a mess: it's constantly changing ("improving"), Pyright and MyPy never agree, Pyright doesn't agree with itself between versions, and much more. The bolted-on, late-in-the-game nature of Python's typing really shows. One place where I have a real side-by-side comparison of the two languages solving the same problem is: I wrote a streaming websocket client with both Go and Python. Go's was so much easier to reason about due to the simplicity and ubiquity of io.Reader and io.Writer. Compare that to the mess that is Python "file-like objects" (https://docs.python.org/3/library/io.html https://docs.python.org/3/library/io.html). Should I use BufferedIOBase, or TextIO, or maybe RawIOBase, and what do I override in my subclass? It was quite painful. My take is that, in addition to its speed, Go wins on its type system, I/O interfaces, concurrency, package management, and test/benchmark tooling. Python wins in its beautiful syntax, [list|dict|set|generator] comprehensions, and quantity of 3rd party libraries.
whateveracct 3y ago
If you don't count learning curve (as it's a static "ease of use" cost), Haskell also fits the bill. I've used both Haskell and Go extensively and tbh they are more similar than different. They each could afford to absorb the other's strengths.
- tome 3y ago
  Which Go strengths would you recommend Haskell absorb?
  - whateveracct 3y ago
    There's nothing quite like interfaces in Haskell. Or rather, there's a bunch of ways to encode them. But even so, the Go structural typing there is nice. In industry, I have found this means Haskellers (especially beginners who just do that big Haskell book) don't program against interfaces. Which isn't a scalable way to write a large software project and results in a lot of unnecessary coupling, which in turn means compile times don't stay fast. The Go GC is also pretty nice as far as latency-focused ones go. But Haskell already got a latency-oriented GC.
    - dllthomas 3y ago
      > There's nothing quite like interfaces in Haskell. What are the differences you care about between programming against an interface in go and programming against a typeclass in Haskell? From my industrial Haskell experience, programming against a typeclass is natural and common, and the differences that come to mind (no need to declare instances, pervasive ability to fallibly downcast) don't seem to support a claim that Haskellers "don't program against instances" except in the useless sense (that I don't think you intend) that what they program against aren't exactly go interfaces.
      - whateveracct 3y ago
        Hm well there just isn't a simple way to do it? Your equivalent options are - Record of functions - mtl classes - extensible effects - other weird hand-rolled things I work in a normal boring "ReaderT IO" backend-y codebase and it's like pulling teeth to write neat code against interfaces. Doubly so to get less experienced Haskellers to do it. Tbh if we used proper extensible effects (any of them), that would qualify and accomplish what I'm talking about. But even seasoned "simple" Haskellers push back on that for being to "fancy."

peddling-brink 3y ago

To a certain extent, you’re trying to do things that are not strengths for the language ecosystem. The available libs and its intended purpose line up nicely when you go to create little system utilities, tools, backends, etc. You generally have to define your own data structures and implement your own algorithms. For the above activities, I’d go to Python. To create a tool from the ground up, Go.

alternatex 3y ago
No bias against Python but it's an odd suggestion in a thread about performance. I'd imagine devs springing for Go aren't picking it because of its massive ecosystem, but because they want the performance it offers. Especially devs commenting on a thread about its performance benefits.
- imachine1980_ 3y ago
  Edgedb use python, you can have perfotmant c code wrapped in python
  - pjmlp 3y ago
    Yeah, but then it is C code wrapped in Python, not Python.

paholg 3y ago

I don't have a ton of Go experience (intentionally), but I don't find it very good for ease of code or safety. It's a simple language to a fault, but I would not call it easy. There are so many footguns in the language itself and the standard library. I just reviewed a PR that added a bunch of `defer response.Body.Close()` calls after http requests to fix leaks. I don't know why Go is allergic to RAII, but I hate it. I also find it very hard to read. There's so much boilerplate sprinkled throughout everything, it's hard to follow what code is actually doing. While I am very in favor of a good static type system, I think dynamically typed languages like Ruby or Python win over Go by any metric except speed.

benhoyt 3y ago
I think those are worthwhile criticisms ... right up until you said "Ruby or Python win over Go by any metric except speed". As someone who has written a ton of Python and a ton of Go (and likes both languages), I still prefer Python for small scripts due to its terseness and beautiful syntax. Side note: Go's static typing is so much better than Python's type annotations. Python typing is difficult to use and a mess: it's constantly changing ("improving"), Pyright and MyPy never agree, Pyright doesn't agree with itself between versions, and much more. The bolted-on, late-in-the-game nature of Python's typing really shows. One place where I have a real side-by-side comparison of the two languages solving the same problem is: I wrote a streaming websocket client with both Go and Python. Go's was so much easier to reason about due to the simplicity and ubiquity of io.Reader and io.Writer. Compare that to the mess that is Python "file-like objects" (https://docs.python.org/3/library/io.html https://docs.python.org/3/library/io.html). Should I use BufferedIOBase, or TextIO, or maybe RawIOBase, and what do I override in my subclass? It was quite painful. My take is that, in addition to its speed, Go wins on its type system, I/O interfaces, concurrency, package management, and test/benchmark tooling. Python wins in its beautiful syntax, [list|dict|set|generator] comprehensions, and quantity of 3rd party libraries.

whateveracct 3y ago

If you don't count learning curve (as it's a static "ease of use" cost), Haskell also fits the bill. I've used both Haskell and Go extensively and tbh they are more similar than different. They each could afford to absorb the other's strengths.

tome 3y ago
Which Go strengths would you recommend Haskell absorb?
- whateveracct 3y ago
  There's nothing quite like interfaces in Haskell. Or rather, there's a bunch of ways to encode them. But even so, the Go structural typing there is nice. In industry, I have found this means Haskellers (especially beginners who just do that big Haskell book) don't program against interfaces. Which isn't a scalable way to write a large software project and results in a lot of unnecessary coupling, which in turn means compile times don't stay fast. The Go GC is also pretty nice as far as latency-focused ones go. But Haskell already got a latency-oriented GC.
  - dllthomas 3y ago
    > There's nothing quite like interfaces in Haskell. What are the differences you care about between programming against an interface in go and programming against a typeclass in Haskell? From my industrial Haskell experience, programming against a typeclass is natural and common, and the differences that come to mind (no need to declare instances, pervasive ability to fallibly downcast) don't seem to support a claim that Haskellers "don't program against instances" except in the useless sense (that I don't think you intend) that what they program against aren't exactly go interfaces.
    - whateveracct 3y ago
      Hm well there just isn't a simple way to do it? Your equivalent options are - Record of functions - mtl classes - extensible effects - other weird hand-rolled things I work in a normal boring "ReaderT IO" backend-y codebase and it's like pulling teeth to write neat code against interfaces. Doubly so to get less experienced Haskellers to do it. Tbh if we used proper extensible effects (any of them), that would qualify and accomplish what I'm talking about. But even seasoned "simple" Haskellers push back on that for being to "fancy."