> Why does it matter if setting -std29 or whatever breaks ABI when -fno-rtti does the same?
I think it's the distinction between can and must. Right now you can preserve ABI across compiler versions if you want to (and that is indeed a desirable quality for some users). The pushback is against changes to the standard that would require an ABI break.
> Well, Carbon would have been better off if they just made "C with `match` and sane error handling" instead of whatever it is they are building there over at Google.
Perhaps that might be a better language in a different context, but I don't think that language would have have been better for Google given their goals (e.g., bidirectional interop with C++, incremental automated migration, memory safety, etc.)
> and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.
Out of curiosity, would you be able to elaborate on (or link to?) what makes reflection so problematic?
At least as far as public info goes it's still being worked on. The GitHub repo [0] has pretty consistent activity and some recent-ish talks [1], one of which says that they are considering a 0.1 release "early next year".
> It claims to be "sufficiently fast by default", yet "sufficiently fast" depends entirely on the requirements of a specific user project.
I think that's why the "by default" is there; the goal is to offer a safe/convenient API that performs well enough that by default you don't need to reach beyond said safe/convenient API. And if you happen to be in a situation where the default performance of the safe/convenient APIs is insufficient, more advanced APIs will be provided.
It's a mirror of Rust's general design goals, if anything.
But it still depends on the requirements of the specific user project, whether the default is sufficiently fast, ESL. It is still entirely inconsistent. Basic logic 101, clear as day. Why do you even try to contest this?
> It's a mirror of Rust's general design goals, if anything.
Do you claim that "it's a mirror of Rust's general design goals, if anything" to be forced into memory unsafe, extra-difficult Rust code being required, when the going already gets tough regarding performance requirements? That is not a great design goal, and it is not conducive to memory safety nor high quality software.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
> But it still depends on the requirements of the specific user project, whether the default is sufficiently fast
I mean, "by default" means "by default", not "in all cases". Situations that the default doesn't address are not inconsistent with the existence of a default; it's just that said situations are expected to be a relative minority.
Perhaps a more concrete example would help: say the API the devs come up with is sufficiently fast enough for 99 common use cases and not fast enough for 1 uncommon one. I don't think it'd be inconsistent to call said API "sufficiently fast by default" since "sufficiently fast" is an accurate description of the API for "normal" use (i.e., that's the "default" state).
> Do you claim that "it's a mirror of Rust's general design goals, if anything" to be forced into memory unsafe, extra-difficult Rust code being required, when the going already gets tough regarding performance requirements?
No, I think that's a rather... imaginative interpretation of what I said.
> However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust?
I think that will depend on the exact reason(s) C++ with LLVM offload didn't work out? If Rust differs from C++ in a way that addresses pain points/failure modes/etc. from the C++ attempt, for instance, then perhaps it isn't unreasonable to think Rust could succeed where C++ didn't (c.f., Mozilla's pre-Rust attempts to parallelize Firefox's CSS styling engine). Inversely, if Rust doesn't do things differently in the right way perhaps one might expect the effort to also not work out. Or maybe the problems are entirely non-technical and things could work out in either language.
Oil self-sufficiency isn't quite as simple as oil production > oil exports because not all crude is the same and refineries generally aren't completely crude-type-agnostic. IIRC US refineries prefer processing "heavy" (higher proportion of longer hydrocarbons) and "sour" (higher sulfur proportion) crude but most US production is "light" (higher proportion of shorter hydrocarbons) and "sweet" (lower sulfur proportion), so as a result the US still ends up importing/exporting a bunch of crude.
I'm not sure you need to? Rust references don't exist in C, after all.
That being said I wouldn't be surprised if there were other factors that would weigh against considering FFI calls to Fil-C safe by default (e.g., Fil-C's somewhat looser bounds on what is considered a valid pointer access).
> IANAL but is CircuitSeuss not committing a crime here by giving the advice
> "If you are discussing illegal shit, don’t do it around people or devices you don’t completely trust. Retain plausible deniability."
> Or is it legal to discuss "illegal shit"?
The answer to that question is extremely jurisdiction-dependent. That being said, in the US the statement you quote is almost certainly not illegal under current 1st Amendment jurisprudence. The main case of interest is Brandenberg v. Ohio [0], which held:
> Freedoms of speech and press do not permit a State to forbid advocacy of the use of force or of law violation except where such advocacy is directed to inciting or producing imminent lawless action and is likely to incite or produce such action.
I think it's the distinction between can and must. Right now you can preserve ABI across compiler versions if you want to (and that is indeed a desirable quality for some users). The pushback is against changes to the standard that would require an ABI break.