Are you sure? This would only affect C code calling Go functions, right? Apart from that being very rare (the other way around is more common using CGo), from the register proposal it looks like they've discussed and had ways to address the CGo issue. I haven't tried this though.
@benhoyt
From 2/21/2007, 9:17:39 PM till now, @benhoyt has achieved 4381 Karma Points with the contribution count of 801.
Recent @benhoyt Activity
The other replies give the answers: the ABI has always been an implementation detail, and Go binaries are static built from source, so this change won't matter. But just to add to that: I've been using Go for 4-5 years, and have never needed to know or care about its calling convention. It doesn't even affect people that write functions for Go in assembly ... because as the proposal says, "This will remain backwards compatible with existing assembly code that assumes Go’s current stack-based calling convention through Go’s multiple ABI mechanism." So the Go developers have put a fair bit of thought and effort into making this just work, even bending over backwards to make assembly libraries keep working.
I agree with the basic idea in your blog post -- that interfaces should be defined by the consumer, and be small -- but I think it's a bit dogmatic: "it’s wrong". :-)
For one thing, it's easy to work around the issue of "pasting every single function signature into this test file, and making it panic("not implemented") or something". You can simply embed the DB interface in your test struct, and only override the method(s) you need. For example, let's say the DB interface defines 10 methods, but our function under test only need one, GetThings(). We do this:
type testDB struct {
DB // embedded field named DB, so testDB implements DB
things []Thing
}
// but override GetThings method
func (d *testDB) GetThings() ([]Thing, error) {
return d.things, nil
}
The other thing is simply pragmatism: at some point it gets tedious to define all these tiny interfaces. Do you do it at the handler level, where each db sub-interface only has 1 or 2 methods? This blows out the number of interfaces. Or do you do it at the server level, where the db interface has all the methods (what you're opposed to)? Or something in between: have server "sections" grouped by logical feature, such as authDB, projectDB, and so on. Each might have 5-10 methods, and to test each sub-server you'd either do what I've suggested above with an embedded interface field, or just implement a single in-memory test db for each db type.
I do like what you said about interfaces obfuscating the code (it becomes more abstract and hard to follow and navigate), and that testing on the real db if you can is a good idea. Creating a new PostgreSQL db for every test seems like it'd be very slow and unnecessary, though. Why not just one db for each test run?
Go 1.17: Faster software through register-based calling
2 points • 0 comments
I think this is good advice (I've been in both managerial and individual contributor roles over the years).
On the other hand, as an individual contributor, especially if I'm new on the job, I often have imposter syndrome, and keep worrying I'm not doing a good job. (I'm sure I'm not alone in this.) And when my manager doesn't say anything about my performance I start thinking that maybe I'm doing badly. So I feel the need to ask, which is not as nice as them just telling me.
So I guess I'm not disagreeing, as long as if things are fine, the manager does "just go ahead and say that".
You should check out https://pkg.go.dev/modernc.org/sqlite -- it's an (automated) conversion of SQLite's C source to Go so you can use SQLite without CGo. Apparently it passes all the SQLite tests. I've used it in a (toy) project, and it seems to work well.
I haven't used pgx -- can you give some specifics of the issues with dates/times or other rough edges?
Heh, that would be significantly harder. Probably doable, but it'd run quite slowly. Send me the link when you've written it! :-)
Back to basics: Writing an application using Go and PostgreSQL
129 points • 78 comments
Pattern matching in Factor (2009, PDF)
2 points • 0 comments
Nice! My star-struck story is I had lunch with Peter Weingberger (the W) at Google a couple of years back. Neat guy, smart and opinionated. He was working on VSCode's Go integration, if I remember correctly. Asked him what he would change about AWK if doing it again, he said probably the implicit string concatenation syntax by putting two expressions next to each other.
Jessica Livingston (2015)
1 points • 0 comments
AWKGo, an AWK-to-Go compiler
9 points • 0 comments
Improving the code from the official Go RESTful API tutorial
3 points • 0 comments
I suspect it's because Go's general philosophy is that it's better to be verbose and explicit (than terse and magical). Probably falls under "clear is better than clever" from Rob Pike's Go Proverbs: http://go-proverbs.github.io/
I think if this feature was added, it would not be with struct tags, but with an Encoder.SetFieldTransform(json.SnakeCase) or similar setting.
That might be quite a nice feature, actually. You could provide your own function to transform names when marshaling, and for unmarshaling it would strip punctuation and match case insensitively (because it's hard to do the reverse transform, for example should user_id go to UserId or UserID, and if the latter, how does the transform know?).
In any case, it seems like an issue was opened proposing something like that a couple of years ago (https://github.com/golang/go/issues/23027), and Russ Cox responded that the JSON package is basically done, but you could either fork it and add the feature, or use a tool that modifies struct tags like https://github.com/fatih/gomodifytags
Improving the code from the official Go RESTful API tutorial
16 points • 4 comments
The Go grammar/language changes very slowly -- most of the improvements are in the tooling and libraries, so there isn't much. But the best way is the release notes. For the last two years (four versions):
https://golang.org/doc/go1.17: three very minor changes for array pointers and unsafe
https://golang.org/doc/go1.16: no language changes
https://golang.org/doc/go1.15: no language changes
https://golang.org/doc/go1.14: minor change to allow "overlapping interfaces"
Of course, in 1.18 -- coming out in about three months -- there's the huge change to add generics (type parameters). The best way to read about that is in the type parameters proposal here: https://go.googlesource.com/proposal/+/refs/heads/master/des...
Go 1.18 will also add built-in fuzzing support, but again, that's a tooling/library change, not a grammar/language one.
I don't think it's anything like the Python jump from 2 to 3. That changed the behavior of a lot of code (unicode vs bytes, various syntax changes, import changes, etc), and there was no way to automatically upgrade a codebase (2to3 didn't really work).
With the addition of generics to Go, they've been careful to ensure it's fully backwards compatible, so all existing code will still work as is. Major version bumps are for incompatible changes (like Python 2.x to 3.x).
What they're recommending with isolating generic code in existing libraries is so users of older versions of Go (1.17 and prior) can still use those libraries, just not any new functions/types the libraries have added that use generics, and hence require Go 1.18.
Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics? You want to return early (and potentially add context to the error) if there was an error, otherwise continue on. How are you thinking of solving this with generics?
The previous try() proposal added new control flow. That's part of the reason it was criticized so heavily -- it hid a control flow construct in something that looked like a function.
I used web.py heavily in the early days on many small websites and one large website at work (well after it was relatively unmaintained). It was an early "microframework" that was really nice to use, and simple to hack on as needed. I liked its KISS approach to pretty much everything, including database handling (a thin, Pythonic wrapper around SQL, not an ORM). It was quirky in places, though -- I suppose not unlike its original author.
I'd probably use Bottle now, for equivalent simplicity and hackability, or maybe Flask (though that's significantly larger).
site design / logo © 2021 Box Piper