I don't think that's what that word means.

really?

The same way linux isn't. It's easy to start, all the base modifications/configurations are fairly simple, and if you find yourself deep into custom ways of using it, it's open source and fairly well documented with a large community.

So, where can I buy a handful for personal use?

I think that a "minimal viable baseline" type implementation should not break the ODR.

In Rust these types of proposals are common, in C++ less so. The incredibly tedious release process encourages everyone to put in just as much complexity as they can safely get away with.

This is begging the question. Yes, but why did they do that over dedicated syntax?

(My personal theory is that early go had a somewhat misguided idea of simplicity, and preferred overloading existing concepts with special cases over introducing new keywords. Capitalization for visibility is another example of that.)

//go:xyz is dedicated syntax that is compatible with both the language spec and other toolchains that don't know about it.

It's an overloaded comment. I am personally quite fine with it, I don't think it's bad. but it is an overloaded comment.

I'm no longer sure what you're saying. You asked why they didn't go with dedicated syntax, I listed two advantageous aspects of the chosen syntax. We know it's an overloaded comment: that's literally one of the advantages.

Well, I've been unable to follow you as well, then. Obviously if they'd used a different type of syntax (e.g. using # for annotations), those would also be compatible with the language spec, and other implementations would still be just as capable of ignoring all unknown annotations.

(Though for the record, talking about alternative implementations when discussing Go is kind of a funny joke.)

Is gccgo a joke to you?

Maybe? It's stuck at 1.18 without generics and no one has replaced its maintainer, Ian Lance Taylor, who seems to have moved on after leaving Google.

But to be fair to alternative toolchains, TinyGo and TamaGo are also a thing.

Ian Lance Taylor is in the recent commit history for the main Go implementation. He's not working at Google any more but he's still active.

I meant gccgo specifically, I don't doubt he's still active with Go in general.

Good luck compiling on a toolchain that doesn't know about //go:embed or /* */import "C" comments.

This is such a silly response when "You've gotten better at using them and know how to work around their flaws now." is right there and seems a lot more plausible.

I used Manjaro for a few years.

That's how I learned a pretty important lesson about software engineering that still informs how I work to this day.

"A layer of abstraction on top of a stateful legacy system often doesn't result in a simpler system, it just introduces exciting new failure possibilities. This especially applies when the owners of the legacy system have no responsibility over the abstraction layer."

This comment made a lot more sense to me once I realized we weren't talking about an aggressively marketed weight loss drug.

It's still true. Your metabolic system is probably not simpler after taking terzepatide. Although, just because it's not simpler doesn't mean it can't be better. I'm very glad for the C++ abstraction layer over assembly, even if the stack is more complicated than if it were just assembly

The word "legacy" doesn't seem needed there.

Can you explain it for those out of the loop?

Manjaro sells itself as "Arch, but more approachable". In reality, you'll often end up with "Arch, but with additional weird package management upgrade issues that are a byproduct of Manjaro's own repositories interacting with the arch on your system."

Instead of just having to track the arch repos, you suddenly have those and Manjaro's own stuff (and own package manager tool etc.), which is another point of failure. Every new bit of technology is another part that can fail.

I think a lot of the really old school people don't care, but a lot of the younger people (especially those disillusioned with C++ and not fully enamored with Rust) are in fact quite happy for C to evolve and improve in conservative, simple ways (such as this one).

The tradeoff Go made is that certain code just cannot be written in it.

Its STD exists because Go is a language built around a "good enough" philosophy, and it gets painful once you leave that path.

> The tradeoff Go made is that certain code just cannot be written in it.

Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something.

> it gets painful once you leave that path

Still less painful than being zero-day'd by a supply chain attack.

> > The tradeoff Go made is that certain code just cannot be written in it.

> Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something.

What code can you not write in C?

Might be painful for some(many) cases, but there is nothing you can't write in C.

SIMD code.

And if you are going to point out compiler extensions, they are extensions exactly because ISO C cannot do it.

> What code can you not write in C?

This falls under the "selling somthing" angle I mentioned. Yes yes yes, generality and abstraction are tradeoffs and higher level platforms lack primitives for things the lower levels can do.

That is, at best, a ridiculous and specious way to interpret the upthread argument (again c.f. "selling something").

The actual point is that all real systems involve tradeoffs, and one of the core ones for a programming language is "what problems are best solved in this language?". That's not the same question as "what problems CAN be solved in this language", and trying to conflate the two tells me (again) that you're selling something. The applicability of C to problem areas it "can" solve has its own tradeoffs, obviously.

not really in-topic but constant-time crypto primitives are considered hard for any compiled language with a lot of optimizations

Bad news, John Google told me they already quantized it immediately after the benchmarks were done and it sucks now.

I miss when Gemini 3.1 was good. :(