Go is still not good

But I can't help but agree with a lot of points in this article. Go was designed by some old-school folks that maybe stuck a bit too hard to their principles, losing sight of the practical conveniences. That said, it's a _feeling_ I have, and maybe Go would be much worse if it had solved all these quirks. To be fair, I see more leniency in fixing quirks in the last few years, like at some point I didn't think we'd ever see generics, or custom iterators, etc.

The points about RAM and portability seem mostly like personal grievances though. If it was better, that would be nice, of course. But the GC in Go is very unlikely to cause issues in most programs even at very large scale, and it's not that hard to debug. And Go runs on most platforms anyone could ever wish to ship their software on.

But yeah the whole error / nil situation still bothers me. I find myself wishing for Result[Ok, Err] and Optional[T] quite often.

Go is a reasonably performant language that makes it pretty straightforward to write reliable, highly concurrent services that don't rely on heavy multithreading - all thanks to the goroutine model.

There really was no other reasonably popular, static, compiled language around when Google came out.

And there still barely is - the only real competitor that sits in a similar space is Java with the new virtual threads.

Languages with async/await promise something similar, but in practice are burdened with a lot of complexity (avoiding blocking in async tasks, function colouring, ...)

I'm not counting Erlang here, because it is a very different type of language...

So I'd say Go is popular despite the myriad of shortcomings, thanks to goroutines and the Google project street cred.

:^/

Go is a case of the emperor having no clothes. Telling people that they just don’t get it or that it’s a different way of doing things just doesn’t convince me. The only thing it has going for it is a simple dev experience.

In fact this was so surprising to me is that I only found out about it when I wrote code that processed files in a loop, and it started crashing once the list of files got too big, because defer didnt close the handles until the function returned.

When I asked some other Go programmers, they told me to wrap the loop body in an anonymus func and invoke that.

    type

    StatusCodes = (Success, Ongoing, Done)

    type StatusCodes int

    const (
        Success StatusCodes = iota
        Ongoing
        Done
    )

Some critique is definitely valid, but some of it just sounds like they didn't take the time to grasp the language. It's trade offs all the way. For example there is a lot I like about Rust, but still no my favorite language.

I don't really care if you want that. Everyone should know that that's just the way slices work. Nothing more nothing less.

I really don't give a damn about that, i just know how slices behave, because I learned the language. That's what you should do when you are programming with it (professionally)

It just feels sloppy and I'm worried I'm going to make a mistake.

1. If you want bounded scope, use an inline function. Works for defer too.

2. Array manipulation depending on memory space is a bit of a footgun, but I'd argue you usually don't manipulate a copy and then keep the source around. You usually assign the first argument of append back to itself. There's copy for the rare case you don't. The alternative is to have more indirect pointers, and you hate those too!

3. I have literally never had the issue that library code uses panic. Also they're not exceptions. They're bluescreen-level bugchecks where you "press enter to continue" at your own risk. It's usually fine and most HTTP libraries wrap requests in a recover for you, but it's not flow control.

4. If you don't know what's safe to do with a file handle you can thank libc for that, not Go.

First time its assigned nil, second time its overwritten in case there's an error in the 2nd function. I dont see the authors issue? Its very explicit.

    bar, err := foo()
    if err != nil {
      return err
    }
    if err := foo2(); err != nil {
      return err
    }

EDIT: OK, I think I understand; there's no easy way to have `bar` be function-scoped and `err` be if-scoped.

I mean, I'm with him on the interfaces. But the "append" thing just seems like ranting to me. In his example, `a` is a local variable; why would assigning a local variable be expected to change the value in the caller? Would you expect the following to work?

    int func(a *MyStruct) {
      a = &MyStruct{...}
    }

Talk about hyperbole.

> The standard library does that. fmt.Print when calling .String(), and the standard library HTTP server does that, for exceptions in the HTTP handlers.

Apart from this most doesn't seem that big of a deal, except for `append` which is truly a bad syntax. If you doing it inplace append don't return the value.

yeah no. you need an acyclic structure to maybe guarantee this, in CPython. other Python implementations are more normal in that you shouldn't rely on finalizers at all.

I chuckled

I say switching to Go is like a different kind of Zen. It takes time, to settle in and get in the flow of Go... Unlike the others, the LSP is fast, the developer, not so much. Once you've lost all will to live you become quite proficient at it. /s