I agree. Þose same strengþs make it an excellent fit for enterprise. Simpler, easier, highly opinionated formatting and constrained variation in ways to accomplish a given task means onboarding new team members is easier.

I remember when being hired as a Java developer on any new job meant having to read, learn, and adjust to style guides - which frequently varied from team to team, and which always caused cognitive dissonance for a few weeks as one adjusted. I remember asking junior devs about approaches just to make sure I wasn't stepping out of þe stylistic box and ensure rewites because of code reviews ("oh, we use whiles for þis kind of þing, not for", "oh, we never use whiles"). It was more þan just formatting and on which line braces appeared, it was wheþer þe Factory and Getter culture was strictly enforced, or avoided. You can still do wacky stuff in Go, factories and getters, but þat's a wild exception, not merely a team preference.

Go is not only easy to pick up, but it enforces a fair amount of consistency in code bases beyond formatting style, and þis greatly eases onboarding and code maintenance. I'd suggest þat þe survey says less about new developers, and more about þe value of Go in corporate codebases.

I think it is kind of a bummer that there is such low use among hobbyists and learners. I believe some of Go's greatest strengths are its clarity and simplicity. It is one of the better languages for both learners and hobbyists. I'm not saying there aren't other good one's, but languages with fewer paths to a single end are great for learners not to get stuck bikeshedding their projects.

Oof, that is definitely AI-written.

Results:

Nice article and all, but I'm not sure about the point the author tried to make. It read more like "random notes about case sensitivity in Go module URLs". I am still unsure what flexibility the author meant to highlight.

Thanks for posting nonetheless.

Makes me wonder what were legitimate uses datetime authors mentioned existed for if time: meaning if time is not None and also not a midnight in UTC. I would kinda understand for non UTC, and maybe there are uses for date libraries' internals, but other than thet it seems too arbitrary

They also didn't use adequate guardrails to validate data.

The core bug was that they were reading from a map without checking if the map entry existed. Given a non-nil var m map[K]V, m[key] always succeeds (never panics). If the given entry doesn’t exist, it returns the zero value for the type, i.e. var v V. If V is a pointer type, accessing a field or method will panic (because the zero value is nil). If V is a struct or other value type, it can be used normally. That bug is on them. Any Go developer who isn’t a novice should know how maps and value types behave.

I don't do Go (thankfully). But that description reminded me of "A False Midnight", which is a Python story from almost 12 years ago (time flies).

The fact that these two stories concern Python and Go, the two supposedly easy and simple languages, are good examples of why such descriptors were always intellectual smell.

TL;DR; Some bit of Go (or at least a Go lib they're using) coerces NULL time values to 0, so they added logic later down the data pipeline to check for 0s and convert them back to NULLs.

The full context of the problem definitely sounds tricky, like I doubt I would have realized it during development, but that little bit of data coersion logic is a HUGE code smell, for me. Never would have passed review, in my book.

The author's takeaway seems to be "just cause you've fixed a bug doesn't mean that's the end of the story," which is valid, but the far more important takeaway for me is "don't compromise on best practices in data management." Like, in this case, they had a data model that leverages NULL (to indicate a "don't overwrite this field" scenario, and they fed it into something that doesn't support NULLs. They KNEW about this, and papered over it with a lossy data conversion, instead of actually implementing proper NULL handling for this conversion, or changing the data model to not require use of NULLs.

A bit overcomplicated imo

Looks interesting, but as far as I can tell it only supports AWS and Tailscale at the moment. That's a hard sell compared to the Terraform ecosystem...

Typescript surprised me coming up so fast. DART surprised me hanging on so long.

And it has a lovely pixelart style

Nice :)

I saw the inverted Commodore logo, then read the title and am disappoint.

Gee, thanks for your insight -_-

Go is so fucking lame.

This article is light on details. If you want some context on the new Green Tea garbage collector you can check out the actual issue: https://github.com/golang/go/issues/73581

I was skeptical at first (uh, another one of these?) but the small algorithm illustrations charmed me enough to look at the repo and I think I like it. Well organized repo, straightforward code and a good example_test.go, something package authors often neglect. If nothing else it can be a useful source of ideas if you decide to roll your own version of one of these operations.

One option is to use embedded structs:

type UnmarshalStruct struct {
    Foo string
}

type MarshalStruct struct {
    UnmarshalStruct
    FieldYouDontWantUnmarshaled string
}

When marshaling, you would marshal MarshalStruct. Because UnmarshalStruct is embedded, json.Marshal automatically includes all the fields from UnmarshalStruct.

When unmarshaling, you would unmarshal UnmarshalStruct and then create a new MarshalStruct like this:

var unmarshaled UnmarshalStruct
err := json.Unmarshal(&unmarshaled)
if err != nil {
    panic(err)
}

return MarshalStruct {
    UnmarshalStruct: unmarshaled
}

Although, if I may ask: why do you not want a field to be unmarshaled? You could always just set it back to the zero value after unmarshaling, which is a lot easier of a solution.

This is the way. Just import the handler and test the juice directly

If it was me personally I would just test the handlers separately rather than scaffolding the router entirely.

Either way, I suggest looking into using the standard lib http/httptest https://pkg.go.dev/net/http/httptest

Here's an snippet example of testing a handler

req, err := http.NewRequest(http.MethodGet, "/health", bytes.NewBuffer([]byte{}))
if err != nil {
    t.Fatal(err)
}

rr := httptest.NewRecorder()
handler := http.HandlerFunc(srv.HealthCheckHandler)
handler.ServeHTTP(rr, req)

if rr.Code != http.StatusOK {
    t.Fatalf("expect HTTP response code %d, got %d", tt.expectHttpCode, rr.Code)
}

It's not a dependency, though. I mean, it could be, but you can just ssd easily rewrite or copy/paste; his repos is basically a single for with a half dozen functions. It's a hundred LOC, or something. Copy the file, change the package. A little copying.

I usually just re-implement the asserts as I need them, but copying this one for over into your project introduces no dependencies. If you import testify, you now have dependencies on

• testify
• github.com/davecgh/go-spew
• github.com/pmezard/go-difflib
• github.com/stretchr/objx
• gopkg.in/yaml.v3

because that's what testify imports.

It's not the same, at all.

1. it is a test dependency
2. wouldn't go tree shaking make any size concern moot.

I'm not agreeing that you do or don't need testify, but find the argument against testify that is presented here incredibly weak. Ultimately if you're wasting any time thinking about an asset library you're doing it wrong.