Ouch. Given how much of SQLite’s value proposition is the literal avionics-grade testing they apply to the C version to verify how it interacts with all sorts of OS edge-cases and hardware faults, I wouldn’t want to rely too heavily on how differing semantics of the Go execution model might undermine that.

It’s similar to Java – JNI is frowned upon from what I remember

And yeah it’s a big reason I’ve avoided Go – I’m supposed to throw out all my C / C++ knowledge and decades of libraries? The sqlite3 thing raised my eyebrows too

It is a big shame, because I would like to use a higher level and faster language like Go or Java/Kotlin, but I stick with Python because there is always a “way out”

Python has different problems, but I can always make it work somehow. With Go or Java it seems like I’ll find myself in a corner with a Catch 22 eventually

I have a rant about the “monoglot anti-pattern” – language designers assuming that every system in the language will be written ONLY in that language. Everybody wants to “own the world”

As a software system becomes more successful and gets to a certain size, the probability of that approaches zero rapidly

I mean Go barely has GUI libraries from what I remember, so if you even add a GUI to your system, now you have this awkward boundary, and a code reuse problem

*nod* And a big part of the reason Pascal lost out to C is that it took so long to step out of the “That functionality would impede its suitability to be a safe teaching language” sandbox.

The function colouring problem exists in no small part because there was a time not too long ago when we hadn’t yet recognized how desirabie asynchronous programming would become as a feature. Go had the benefit of hindsight and chose to willingly walk toward being “Pascal, but for microservices instead of teaching”.

(Thus, “the only good boundary with Go is a network boundary”.)

…and yes, Pascal’s support for things like arrays where the length isn’t part of the type signature and strings that aren’t size-limited by a length field with a range below what available memory allows are a function colouring-esque change that needs to be plumbed throughout a codebase to change things if you chose incorrectly.

The reason I quoted what I did is because I think it’s unfair to say “Javascript avoids this by essentially making everything async and non-blocking.” and then not say the same thing about Go.

Sure, the syntactic sugar is different, but Go and Node.js take the same approach.

The problem is that better is different. Forcing a reimplementation of everything to be in Go to coexist with the Go runtime means that things can be better than C-world by being different, but also things are different and different is bad in itself and often not actually better.

Anyway, Go is a language based on trade offs and some people don’t like the trade offs it makes and some people don’t like the idea of having trade offs at all.

You’re talking about something different than what my comment was about. My comment is basically a criticism of the writing in the article.

You’re talking about the context switching overhead, which this article says (rightly or wrongly) is not significant:

So far I’ve made goroutines sound pretty boring. They are like threads but use same order of magnitude of RAM. They occasionally can be scheduled smartly but I haven’t presented any evidence they can be scheduled/context switched more efficiently than regular threads. The biggest real benefit I see is that I can use lots of goroutines without worrying as much about configuring system resources.

Then the article says:

So why do [goroutines] exist and why are they awesome? […] non-blocking I/O where possible plus integration of the event loop into the go scheduler is, to answer our earlier question, the manner in which goroutines can be more efficient than threads and it’s how go manages to be pretty good at fast networking.

The article distinguishes context switching overhead from “non-blocking I/O”, and says the latter is the significant source of efficiency for goroutines over threads. But it does not say why “non-blocking I/O” is faster.

See your sibling comment and my reply to it. You’re talking about something different than my comment is about :)

Does not seem to be the case in this particular example:

$ go version
go version go1.20.5 linux/amd64

$ git diff a.go b.go
diff --git a/a.go b/b.go
index 3c50a8a..92ea0c9 100644
--- a/a.go
+++ b/b.go
@@ -9,8 +9,8 @@ func main() {
     wg.Add(count)
     for i:=0;i<count;i++ {
           go func() {
+                       defer wg.Done()
                        time.Sleep(time.Second)
-                       wg.Done()
           }()
     }
        wg.Wait()

$ t go run a.go 
real 2.26s
cpu  6.03s (4.95s user + 1.08s sys)
rss  2550.02mb

$ t go run b.go
real 2.58s
cpu  18.02s (17.28s user + 746.47ms sys)
rss  1904.80mb

CPU time is changed from 18s to 6s, which is significant.

I didn’t phrase it well. Ofc we wouldn’t make a million network requests biter did create a million goroutines in a short time span (<30s) and the scheduler had a hard time with them. The cores issue was that the interface wasn’t well defined and the goroutines were used in concurrency control.

Overall I’d argue that goroutines do not come for free and I have the impression that many write like they do.