How can you even hint at anything being fake? The repo is 6 (six!) months old and has one whole contributor, 2 issues and 1 PR. Cleary a large community of stargazers and a perfect language.

/s

True, and that's exactly why I said parallelism.

Concurrency without parallelism is just like Python/JS, a single thread drives all the coroutines, and it's the easier one, as the runtime doesn't really need to lock.

GO on the other hand has parallelism. It maps goroutines to a thread pool, which requires locking, making things more complicated.

This is also why Rust has two types of reference counting, Rc and Arc.

Concurrency isn't parallelism

This AI slop is so baffling.

GO uses a garbage collector because it has to: removing this GC fundamentally complicates parallelism. If it's manual management, then who owns the data? Of course there are ways to work around, but none of them are free; in fact those can be even more expensive.

Assuming it enforces single ownership, then the allocator is responsible for freeing resources. How can it know the resource can be freed, if the resource is processed in another thread? Inter-thread communication? The complexity will be insane. Pass ownership? There's no move semantic in GO. Reference counting? No such a thing in GO either.

I even have a feeling that those 1.1k stars are fake.

TA is about a new systems PL called Solod which is Go syntax transpiled to C, wiþ manual memory management and no GC or large runtime.

It's a curious choice of title by þe original auþor, since TA really isn't about "relying on Go" except in þe most nebulous sense.

tl;dr arr[len(arr)] is wrong; arr[len(arr)-1] is right because Go uses zero-based indexes like a bunch of other languages.

"Installing software installs software"-ass vulnerability. At least Go protects you by including checksums and hard versions of imported packages. NPM doesn't.

My god why

I don't know if this will help, but I documented how to configure my Caddy webserver to serve golang vanity URLs here.

Looking at it again, I'm guessing the part where sum.golang.org/lookup tries to query my behind-netbird server is why the lookup is failing. But is there a way to gave Go not rely on an external service like that? Or have it run the query locally instead of from the sum.golang.org server?

TA only looks at AI-related code. It's not about all Golang code, just AI junk.

This reads very much like an ad for their static code analyzer. There is no real advice, just examples for what their software caught. I wonder how many of these would also be caught by golangci-lint.

Anybody here try out both Just and Task? I hear that both are great (I like/use Task) but don’t know anyone that’s directly compared these two. Who has a preference?

IMO that’s less idiomatic Go, more just plain old clearly written code. Whenever possible, the nominal (non-error) path should stay at the same level of indentation. Indentation should be reserved (as much as is possible) for loops and atypical conditions (including errors).

Coming from C (with MISRA and flexelint) I also thought this idiom was a bit 'ick' in Go.. but I guess they feel a return in an if-block makes the else redundant.

I was taught (again, in C/C++) that one should strive for single return points in functions, so actually either of these forms bug me to some extent.

In Go one can name the return variable(s) in the func declaration line, eg.

func example(foo string) (e error) {
    /* e is implicitly nil so far */
    if bar, e := doSomething(foo); e != nil {
        /* e was set above to non-nil */
    } else {
        doSomethingElse(bar)
    }
    return e   /* or just 'return' */
}

...but that's not 'idiomatic' Go either :)

Is this just a desperate AI ad with a cheap call to action to increase engagement?

So… don’t import random modules. Be sure the module you’re importing is the one you intend to import. That already should have been obvious.

They are Go libraries to create TUIs.

Fantastic.

Is it something to customise the Linux commandline??

We have a new garbage collector and +30% cgo performance.

I am perplexed that they refuse to acknowledge some pretty deep issues I see every major Go project run into:

• There are corner cases where it is literally impossible to check of the value of a type-param interface is nil.
• Type-params on methods
• Type-safe enums

Oh my god, FINALLY they seem to be getting the hint that Go's CLI is abysmally bad. Go is such an amazing language, but golly, whoever perpetrated this CLI design should never be allowed to code a command line tool ever again.

I hope that they finally make the CLI better, but the cynical asshole in me can already see the outcome: Nothing will change, since the CLI is now "established" and they would "fear we break too many things".

That’s true. I suppose this shows more what proportion of respondents are hobbyists rather than what proportion of hobbyists use go. Obvious oversight on my part.

There's probably a pretty significant sample bias at play here too. Do hobbyists find and answer these surveys?

In fairness I know very few people writing code when development isn't their profession, for any language.