I think this is the logical next step, but I feel like it won’t be based on the EU but assembled entirely parallel by some of EU‘s members, and this seems consequential to me.
Oh, it’s very well recognized. You can check the Mario Draghi report or even recent comments by ECB‘s Christine Legarde. I think it’s mostly reluctance to make big structural changes that seems to be the issue right now.
But when Draghi wrote his report, he was leaving the power structures. It will probably slowly change, but the neoliberal hegemony is still there.
I think the big issue is that all European elites have investments in the USA, and they don't have reason to pick EU over USA for investing. So there is nothing compelling them to voluntary worsen the relations.
I tried to use LLMs to help me with server-side pb coding, but it was mostly a flop. LLMs don't have an up-to-date state of pb's API. 2 out of 3 times the LLM would give at least a hint how to go about something and the rest is me manually editing the code, reading the docs or looking at pb's source code. All in all, I consider it a nice "pair-programming" type of experience but one can't rely on LLMs to do the pb work for you.
This is what worked for me… clone the pb repo and stick reference to it in my agents.md. I put additional notes in my own addendum.md in the line cloned repo. ChatGPT-codex variants handle it nearly flawlessly and no issues with being out of date. I use the same pattern for all “niche” libraries
My thinking as well. If people don’t like Microsoft, the last place to start their quixotic adventure would be GitHub.
I don’t use Azure or Windows. At work I push against Teams and actively try to persuade customers not to use Microsoft products. The reason isn’t even ideological - most of the time their products suck and the dev support is bad. VScode may be an exception, I’ll give them that.
And I wonder why Codeberg and not a self-hosted Forgejo/Gitea instance? I also don’t like GitHub but this bandwagon to Codeberg doesn’t seem quite alright to me. There must be another way than jumping from one centralized git hosting service to another.
That first example is an unintended closure, since the err at the top level actually has nothing to do with the errs in the goroutines. I have seen that sometimes, although the use of = rather than := normally makes it obvious that something dodgy is going on.
As to whether it's a common pattern, I see closures on WaitGroups or ErrGroups quite often:
workerCount := 5
var wg sync.WaitGroup
wg.Add(workerCount)
for range workerCount {
go func() {
// Do work
wg.Done()
}()
}
wg.Wait()
You can avoid the closure by making the worker func take a *sync.WaitGroup and passing in &wg, but it doesn't really have any benefit over just using the closure for convenience.
And you would get garbled up bytes in application logic. But it has absolutely no way to mess up the runtime's state, so any future code can still execute correctly.
Meanwhile a memory issue in C/Rust and even Go will immediately drop every assumption out the window, the whole runtime is corrupted from that point on. If we are lucky, it soon ends in a segfault, if we are less lucky it can silently cause much bigger problems.
So there are objective distinctions to have here, e.g. Rust guarantees that the source of such a corruption can only be an incorrect `unsafe` block, and Java flat out has no platform-native unsafe operations, even under data races. Go can segfault with data races on fat pointers.
Of course every language capable of FFI calls can corrupt its runtime, Java is no exception.
> Meanwhile a memory issue in C/Rust and even Go will immediately drop every assumption out the window, the whole runtime is corrupted from that point on.
In C, yes. In Rust, I have no real experience. In Go, as you pointed out, it should segfault, which is not great, but still better than in C, i.e., fail early. So I don't get or understand what your next comment means? What is a "less lucky" example in Go?
> If we are lucky, it soon ends in a segfault, if we are less lucky it can silently cause much bigger problems.
Silent corruption of unrelated data structures in memory. Segfault only happens if you are accessing memory outside the program's valid address space. But it can just as easily happen that you corrupt something in the runtime, and the GC will run havoc, or cause a million other kind of very hard to debug errors.
> But it can just as easily happen that you corrupt something in the runtime, and the GC will run havoc
I would love to see an example of this, if you don't mind. My understanding is that the GC in Go actively prevents against what you write. There is no pointer arithmetic in the language. The worst that can happen is a segfault or data corruption due to faulty locking like the Java example I gave above.
Here is a thread discussing it, but there are multiple posts/comment threads on the topic. In short, slices are fat pointers in the language, and data races over them can cause other threads to observe the slice in an invalid state, which can be used to access memory it shouldn't be able to.
While I agree, in practice they can actually be parallel. Case in point - the Java Vert.x toolkit. It uses event-loop and futures, but they have also adopted virtual threads in the toolkit. So you still got your async concepts in the toolkit but the VTs are your concurrency carriers.
reply