• [GO] Who uses Go and what do you like/dislike about it?

    From Vasco Costa@21:1/5 to All on Sun Apr 10 14:30:08 2022
    Ever since it came out more than ten years ago it caught my attention.
    Back then I was using C/C++ as my goto compiled languages and Python for scripting or anything more high level. Go hits the perfect balance
    between these two worlds. It's easy enough to learn and use, thanks to
    its minimalist approach which I appreciate, free of boiler plate noise,
    very similar to bare C, but crucially comes with batteries included, in
    the form of an excellent standard library. Being a compiled language its performance is much better when compared to something like Python.

    Performance isn't really what I value the most about Go however, instead
    what really makes it shine for me is its minimalist set of keywords and
    simple approach. I love Python and everything it brings, but if for some
    reason I stay away from it for a while, I tend to forget some of its
    idiomatic patterns, whereas I can more easily remember Go's equivalents.

    Something else I must mention on this initial post about the language is
    how I tend to favour Go's error handling over try/catch blocks from
    other languages. In my experience, although initially a bit verbose, it
    helps me tackling any possible errors where they happen. Somehow in
    Python there's the odd exception that I forget about or don't handle
    properly, resulting in a runtime crash, whereas with Go I seem to never
    have such issues.

    On the other hand, sometimes the syntax can look a bit weird, but well, nothing's perfect ofc. There's much more to say about Go, but before I'd
    like to hear from anyone here who actually uses the language. I know
    there's a dedicated go-nuts Google Group, but I love USENET and somehow
    miss discussing Go here.

    --
    Vasco Costa

    AKA gluon. Enthusiastic about computers, motorsports, science,
    technology, travelling and TV series. Yes I'm a bit of a geek.

    Gemini: gemini://gluonspace.com/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From meff@21:1/5 to Vasco Costa on Mon Apr 11 22:35:54 2022
    On 2022-04-10, Vasco Costa <vasco.costa@invalid.invalid> wrote:
    Ever since it came out more than ten years ago it caught my attention.
    Back then I was using C/C++ as my goto compiled languages and Python for scripting or anything more high level. Go hits the perfect balance
    between these two worlds. It's easy enough to learn and use, thanks to
    its minimalist approach which I appreciate, free of boiler plate noise,
    very similar to bare C, but crucially comes with batteries included, in
    the form of an excellent standard library. Being a compiled language its performance is much better when compared to something like Python.

    Performance isn't really what I value the most about Go however, instead
    what really makes it shine for me is its minimalist set of keywords and simple approach.

    I find that Go's performance is always "good-enough" for me. At work I
    work on high availability, low-latency systems and while we don't use
    Go that much, Go has had very little trouble scaling. It's GC
    throughput is lower than Java's but its low-latency and ease of use
    usually trumps anything that we need to twiddle with GC with. In
    general if I predict we'll be fighting GC a lot (meaning we can't just preallocate to avoid GC pressure) then I prefer using a GC-free
    language to begin with (like C++ or Rust.) These cases are few and
    far-between for us at work and in my hobby work is almost non-existent.

    Something else I must mention on this initial post about the language is
    how I tend to favour Go's error handling over try/catch blocks from
    other languages. In my experience, although initially a bit verbose, it
    helps me tackling any possible errors where they happen. Somehow in
    Python there's the odd exception that I forget about or don't handle properly, resulting in a runtime crash, whereas with Go I seem to never
    have such issues.

    With errors there's a bit of essential complexity that you can't get
    around. A lot of Go haters tend to point to Go's highly verbose error
    handling syntax as a negative. My experience using languages like
    Rust, Scala, or Haskell which use type stacks to encode errors has
    been "safety" with no provenance: an underlying call will fail and
    propagate up the call-stack because of type semantics but the cause
    for failure will be masked because these languages do not encourage
    chaining errors. Exception-based languages like Python (and I guess
    C++ but that's another thing altogether) do abort early and complain
    loudly. However I find their unpredictability to be vexing and I'm
    really over getting paged at 0200 due to some `IndexError` that
    bubbles up. Go's `fmt.Errorf` encourages error chaining and I find the
    effects heartening in my code and production code I've shipped.

    That said I find Go's `nil` value to be a bit maddening. I've
    certainly been bit by having `nil` values for pointers that I
    overlooked, causing a panic (usually from a library.) I realize that
    the historical lack of generics probably burnished this design
    decision but I haven't always been happy with it. Even if you train
    yourself to check `if thing != nil`, it'll slip through code review
    one day and there goes the barn. Fuzz testing should help, but I've
    never used it and can't weigh in either way.

    On the other hand, sometimes the syntax can look a bit weird, but well, nothing's perfect ofc. There's much more to say about Go, but before I'd
    like to hear from anyone here who actually uses the language. I know
    there's a dedicated go-nuts Google Group, but I love USENET and somehow
    miss discussing Go here.

    I love working with Go. I'm usually quite busy in my own life due to a combination of work, housework+repairs that I like doing, and general householding with my partner. With Go I can go from idea to
    implementation quickly, efficiently, in a readable way. I've even been
    able to make initial work on ideas while intoxicated and have the
    style hold up to sober scrutiny afterword.

    I also find that Go generally helps me focus on the problem I'm
    solving and that there's less temptation to solve a problem in an
    /elegant/ way. While that produces code that's certainly more
    repetitive than constructs from more /elegant/ languages, I find that
    it keeps me focused on the end goal of my program rather than the act
    of coding itself. If you're the type that likes to code to express
    themselves then Go is probably not your language. The lack of
    abstraction in Go does make it easy to paint yourself into an
    unergonomic corner and probably does lead to more eager refactoring
    than a language with a larger abstraction toolbelt would.

    If you're interested I can post stuff that I've worked on with
    Go. Most recently I've been working on an NNTP frontend for Reddit
    which grabs Reddit posts from the API, drops them into a sqlite
    database, and serves them up to a newsreader. As a victim of its own
    success, I've stalled in adding new features to it as it's useful
    enough for my own regular usage. I have a few more NNTP commands I
    need to support and it should have full READER capability support. I'm
    also contemplating a simple SIP registration proxy so I can use SIP
    phones on private networks that I run and I haven't seen anything else
    that does what I'm looking for without a huge manual and configuration
    surface.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vasco Costa@21:1/5 to meff on Tue Apr 12 11:09:00 2022
    On 11/04/2022, meff <email@example.com> wrote:
    I find that Go's performance is always "good-enough" for me. At work I
    work on high availability, low-latency systems and while we don't use
    Go that much, Go has had very little trouble scaling. It's GC
    throughput is lower than Java's but its low-latency and ease of use
    usually trumps anything that we need to twiddle with GC with. In
    general if I predict we'll be fighting GC a lot (meaning we can't just preallocate to avoid GC pressure) then I prefer using a GC-free
    language to begin with (like C++ or Rust.) These cases are few and far-between for us at work and in my hobby work is almost
    non-existent.

    Go's performance is also good enough for me. It's not worth the extra
    trouble of using C or even Java, which I also like. Some people often
    mention how heavy the GC is, but honestly, for my use cases this isn't
    even something I would obsess about. It would be interesting to hear
    from someone where performance is so critical that this could hurt.

    That said I find Go's `nil` value to be a bit maddening. I've
    certainly been bit by having `nil` values for pointers that I
    overlooked, causing a panic (usually from a library.) I realize that
    the historical lack of generics probably burnished this design
    decision but I haven't always been happy with it. Even if you train
    yourself to check `if thing != nil`, it'll slip through code review
    one day and there goes the barn. Fuzz testing should help, but I've
    never used it and can't weigh in either way.

    Yes, I forgot to mention on my original message that I've also had
    runtime issues with nil. Talking about generics, I haven't tried them
    yet in go, now that they're available. Anyone using generics out there?
    I would like to know if it improved your workflow.

    I love working with Go. I'm usually quite busy in my own life due to a combination of work, housework+repairs that I like doing, and general householding with my partner. With Go I can go from idea to
    implementation quickly, efficiently, in a readable way. I've even been
    able to make initial work on ideas while intoxicated and have the
    style hold up to sober scrutiny afterword.

    Hah, exactly the same here! Housekeeping tasks and time with my partner represent an important slice of my time and crucially interrupt my daily
    flow quite a bit, meaning I rarely have a "lot" of time in a row to
    code. With Go I can implement new features in small steps and fully test
    it quickly. I certainly take less time than using most other languages,
    so this often helps me avoiding putting something on hold while I solve
    some other issue at home.

    If you're interested I can post stuff that I've worked on with Go.
    Most recently I've been working on an NNTP frontend for Reddit which
    grabs Reddit posts from the API, drops them into a sqlite database,
    and serves them up to a newsreader. As a victim of its own success,
    I've stalled in adding new features to it as it's useful enough for my
    own regular usage. I have a few more NNTP commands I need to support
    and it should have full READER capability support. I'm also

    This is absolutely amazing and something I've also considered doing but
    never really took off. Reddit, in a way, is the spiritual successor to
    Usenet, at least it's the closest thing I can think of. Please share,
    I'd be willing to help if possible.

    --
    Vasco Costa

    AKA gluon. Enthusiastic about computers, motorsports, science,
    technology, travelling and TV series. Yes I'm a bit of a geek.

    Gemini: gemini://gluonspace.com/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Spiros Bousbouras@21:1/5 to meff on Tue Apr 12 17:52:08 2022
    On Mon, 11 Apr 2022 22:35:54 -0000 (UTC)
    meff <email@example.com> wrote:
    With errors there's a bit of essential complexity that you can't get
    around. A lot of Go haters tend to point to Go's highly verbose error handling syntax as a negative. My experience using languages like
    Rust, Scala, or Haskell which use type stacks to encode errors has
    been "safety" with no provenance: an underlying call will fail and
    propagate up the call-stack because of type semantics but the cause
    for failure will be masked because these languages do not encourage
    chaining errors. Exception-based languages like Python (and I guess
    C++ but that's another thing altogether) do abort early and complain
    loudly. However I find their unpredictability to be vexing and I'm
    really over getting paged at 0200 due to some `IndexError` that
    bubbles up. Go's `fmt.Errorf` encourages error chaining and I find the effects heartening in my code and production code I've shipped.

    Can you explain what "use type stacks to encode errors" and
    "error chaining" mean ?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From meff@21:1/5 to Vasco Costa on Tue Apr 12 22:38:20 2022
    On 2022-04-12, Vasco Costa <vasco.costa@invalid.invalid> wrote:
    This is absolutely amazing and something I've also considered doing but
    never really took off. Reddit, in a way, is the spiritual successor to Usenet, at least it's the closest thing I can think of. Please share,
    I'd be willing to help if possible.

    Definitely. Should I just follow-up in this thread? I'll clean up a
    few things first. Right now the invocation of the program is muddled
    between command flags and a config file so I need to clean that up. I
    also need to add some functionality to trim older posts so that NNTP
    header data is still available but the article body has been
    removed. I'm also planning on eventually separating the Reddit
    crawling portion from the sqlite serving portion so that other web
    forums can be slotted into the architecture (say Hackernews or
    Lobsters) without changing the underlying NNTP serving and sqlite
    spool code.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From meff@21:1/5 to Spiros Bousbouras on Tue Apr 12 22:34:23 2022
    On 2022-04-12, Spiros Bousbouras <spibou@gmail.com> wrote:
    Can you explain what "use type stacks to encode errors" and
    "error chaining" mean ?

    Sure. Let's take Haskell as an example for "type stacks" (not because
    I think it's the best implementation or anything, just because I'm
    familiar enough with it not to make mistakes.) Let's say we want to
    return a `String` from a file if it exists. A type signature I'd see
    for this kind of function would be `String -> IO Maybe String`. Look
    at the result type: `IO Maybe String` is a sandwhich of types. The
    outermost typeclass, `IO a`, marks that this operation is an IO
    operation. The return type of the IO operation, in this case `Maybe
    String` is a typeclass of `Maybe a` which means that the value is
    either type `a` (in this case type `String`) or is empty (think of
    this as a `nil` value in Go or `NULL` in C or `nullptr` in C++.) In
    this case, we've encoded the possible errors in the type stack: An IO
    operation ocurred (which may have failed) and that returns either a
    String or nothing at all (if the file did not exist.)

    If we're doing something similar in Go, error chaining looks something
    like this:
    ```
    ok, err := lineInFile(f, "myline")
    if err != nil {
    return nil, fmt.Errorf("error finding line in file: %w", err)
    }
    ```

    What the above does is takes the underlying error returned by
    `lineInFile` and then appends "error finding line in file" to the
    returned error. What results is the toplevel program returning a chain
    of errors which helps the author understand the control flow which
    ended up causing this error.

    There's nothing stopping Haskell (for example) from having this
    chaining behavior as well, but due to the culture around types in
    Haskell and its do notation, errors are often bubbled up without
    context, so you may end up getting an error like "error: buffer too
    small" but you have no idea where the error was generated from.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vasco Costa@21:1/5 to meff on Wed Apr 13 22:03:39 2022
    On 12/04/2022, meff <email@example.com> wrote:
    On 2022-04-12, Vasco Costa <vasco.costa@invalid.invalid> wrote:
    This is absolutely amazing and something I've also considered doing but
    never really took off. Reddit, in a way, is the spiritual successor to
    Usenet, at least it's the closest thing I can think of. Please share,
    I'd be willing to help if possible.

    Definitely. Should I just follow-up in this thread? I'll clean up a
    few things first. Right now the invocation of the program is muddled

    I think it deserves a thread of its own.

    --
    Vasco Costa

    AKA gluon. Enthusiastic about computers, motorsports, science,
    technology, travelling and TV series. Yes I'm a bit of a geek.

    Gemini: gemini://gluonspace.com/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)