> Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics.
I do not want to contribute to a project using conventional commits. I have consistently found, that I am unable to decide what the "type" of a commit even is and I feel unnaturally caged in into how I would split up commits, by having them be restricted to types (it doesn't help that the conventional commits I've seen appear to decide the type by fair dice roll).
Discouraging contributions does not "undoubtedly improve contribution semantics".
When I said "you need a runtime implementation of generics" I did not mean "you need dynamic dispatch". I meant "you need a type-checker and at least limited code generator at runtime".
> Similar to what java does.
Yes, if you completely forego the static implementation, you can deal with just one. Then all code is slow.
Java can get away with it, because it has a JIT compiler – so it isn't subject to the same "no runtime code generation" design restriction Go is. That also means, it can run on fewer platforms than Go.
> add a new type of interface that is only for use in generic constraints
Yes, that would be feasible. It has been ruled out, because we really don't want to have interfaces that can not be used as types. They currently exist, but the goal is to remove that restriction, not to add more of the same.
I'll note that either way, at that point we are firmly outside the realm of this particular thread. It's no longer what I was responding to.
I'm not sure what you mean. Perhaps you are referring to the reflect package? In that case, yes, that exists. But it is limited in its power (for example, it doesn't allow to create types with methods – precisely because of the difficulties we are talking about) and a comparatively frequent source of bugs. If anything, it provides pretty strong evidence for the problems with this approach.
More specifically, it is because of interface type assertions – the fact that if you have a value of some interface type (e.g. `any`), you can dynamically assert that it is another interface type (e.g. `io.Reader`). A good example of that is `io.Copy`: https://cs.opensource.google/go/go/+/refs/tags/go1.26.3:src/...
This aspect is what prevents you from statically knowing which interface-implementations you need to generate for a specific concrete type. There could always be new ones added at runtime.
FWIW I found, so far, that bringing up dyn-compatibility to Rust people was very useful in helping them understand why Go's interfaces won't ever have generic methods.
The one additional piece of information you need is that in Go, all interfaces are supposed to be trait objects. The exception are union-elements, but that's really a restriction the Go team is trying to remove, not a model to base more features on.
> but the reason against using runtime reflection is mostly that it's slow.
More specifically, it is that it would introduce surprising performance cliffs – code becoming surprisingly slow due to seemingly unrelated changes.
Though BTQH I think an even more important argument is that you would need to have effectively two generics implementations, one working at runtime and one working at compile time. That's a lot of complexity, with surprising failure modes if these two are not bug-compatible.
> But that runtime reflection is exactly how you would work around it today.
I think the overwhelming majority of people will "work around it" by just not trying to use generic methods.
To be clear, I have no skin in the game here. I thought the point you made sounded plausible and as I have zero experience or expertise, I wouldn't argue against it.
I just thought it's ridiculous - and kind of funny - to deny making the claim you literally made. I'm not sure you have a lot of legs to stand on, accusing others of "anti-science thinking" and a "failure of reading comprehension" when asking us to ignore the clear, textual evidence of that contradiction.
> For it to be a "narrative", there would need to be an additional claim that this specific case and context, which is factual, generalizes to most unrelated cases.
Says who? That seems a very narrow and unusual definition of what makes a "narrative", bent to your purpose. It seems to me, a "narrative" in common parlance just means "telling a story" or "relaying a sequence of events". I honestly have never seen someone use the word to imply generalization (doesn't mean no one ever did, of course).
In any case, given that you responded to a comment talking about the two examples of Texas and Hawaii with an example about California and an "actually", it seems pretty fair to me to say, that you even fulfilled this artificially narrowed definition.
I mean, come on, you have got to admit that you have at least been unclear, if you didn't intend to make this argument. Instead of just defensively flinging insults.
Being quippy is the point. That's how aphorisms work: creating a short, pithy distillation of a complex argument, that you can then use pars pro toto to make a point.
I certainly agree that POSWID is easily (and perhaps frequently) misused. But that doesn't invalidate it in general.
Wow that post is bad. The author clearly never actually attempted to understand what POSWID actually means and where it is coming from. Perhaps, instead of looking at Twitter, they should have opened Wikipedia. Or, better yet, Stafford Beers books (though admittedly, he was a pretty atrocious writer).
The follow-up is slightly better. But still not very convincing, IMO. They get far too stuck on a literal interpretation. Of something that self-describes as a heuristic.
> it's a known problem and civilization hasn't collapsed.
Waiting for civilizational collapse to justify regulation seems like an unhelpful standard TBH. In fact, I would argue that it's one of the main problems we are having right now: that we know our current trajectory will lead to civilizational collapse, but aren't willing to change course.
1. I'm not a driver, much less in a country with toll roads. But is it common to have per-vehicle customized toll prices? I would expect to pay a fixed per-car, per-use fee.
2. How is this dependent on privatization? Every car is registered. So it seems pretty easy to enforce taxes on cars. And to do so based on model, weight, whatever you want.
In other words, from what I can tell, making people pay their fair share seems simpler in a public system, if anything. It certainly doesn't require privatization.
FWIW I have little skin in the game, as I said, not a driver, so I would probably benefit both by having to pay less tax and by reducing overall car usage.
> But, like, this is exactly as easy with every single other language that I can think of.
I mean, not exactly. Rust (or rather Cargo) requires you to declare binaries in your Cargo.toml, for example. It also, AIUI, requires a specific source layout - binaries need to be named `main.rs` or be in `src/bin`. It's a lot more ceremony and it has actively annoyed me whenever I tried out Rust.
> The second part "Running go install at the root ./.." is actually terrible and risky but, still, trivial with make (a - literally - 50 year old program) or shell or just whatever.
Again, no, it is not trivial. Using make requires you to write a Makefile. Using shell requires you to write a shell script.
I'm not saying any of this is prohibitive - or even that they should convince anyone to use Go - but it is just not true to say that other languages make this just as easy as Go.
> Bluesky's architecture was pretty much dictated by the premise that anyone needs to be able to see any post on the entire system, regardless of whether they have any connections with the author. That algorithmic entertainment-style feeds need to exist. You do need that firehose and other expensive infrastructure for that, there's no going around it.
Exactly this (that people want it at least - I don't think that means it needs to exist). And I think there would be a lot less frustration in the discourse of ActivityPub vs. ATproto, if we could collectively agree that you can't get this in a decentralized system. In a dense network, the number of edges scales with the square of the number of nodes. It's just not feasible to have a network that is both dense and has a large number of nodes.
I think "I prioritize virality, recommendation engines and network density, thus accept giving control over the network to a centralized and profit-oriented entity" is an entirely reasonable tradeoff to make. I just don't understand why BlueSky users don't seem to accept that it's the tradeoff they are making.
a) I wasn't replying to the article, but to a particular comment about it.
b) I disagree with that summary of the article. I believe it's first paragraph should be an adequate indication of what it's point is, that's how you usually write articles, and it's distinctively not making that point.
And lastly, c) I also don't believe that this statement, if it were the point, is at all true. At best it's hyperbole, but even on the surface, of the list of 15 design criteria for a GC mentioned in the article, at least 7 are explicitly taken into account and considered an optimization goal for the go GC (not all on equal footing and some in a different way than the author might prefer, but claiming they were ignored is just false). I can definitely say that for pause times, pause distribution, compaction, concurrency, scaling, tuning and portability.
I don't think this is an actual claim made by go developers. Their arguments for choosing the algorithm they did was (at least as far as I remember, feel free to point me to a source) a) go for implementation simplicity, readability and clarity first then b) once you figure out where it needs improvement, do that.
They didn't choose mark-and-sweep because they thought other algorithms are worse, go has special needs or anything else. At least this would be the first time I've heard about it. The same goes, from what I've seen, for most of the arrogance ascribed to them (in this article and elsewhere); it usually hinges on making up or misrepresenting things they've allegedly said.
> I don't agree with Go marketing their GC as if it magically provides no trade offs.
I don't believe this to be true. They always point out painstakingly, that the advances made on pause times come with less throughput, for example.
What the go people are doing (and with which I tend to agree and I believe it's hard to argue against the success they're having), is to say that they believe it's possible to build a GC which is good enough for most modern use cases and doesn't come with a lot of tuneables.
(However, even that comes with tradeoffs; it limits the use cases that go can be used for. For large enterprises, being able to minutely tune a GC might be an important thing)
I do not want to contribute to a project using conventional commits. I have consistently found, that I am unable to decide what the "type" of a commit even is and I feel unnaturally caged in into how I would split up commits, by having them be restricted to types (it doesn't help that the conventional commits I've seen appear to decide the type by fair dice roll).
Discouraging contributions does not "undoubtedly improve contribution semantics".