I literally said on here two days ago that I thought that in the past the Project was hostile to gccrs: https://news.ycombinator.com/item?id=46219460

I have been a fan of gccrs the entire time.

This move started before Fil-C existed.

I don't know where I've lied about this, supposedly. Unless you say that, because of this implementation exception (which is based on target, not std vs no_std by the way) as meaning that "there's no UB in safe Rust" to be a lie.

I would still stand by that statement generally. Implementation issues on specific platforms are generally not considered to be what's being discussed when talking about things like this. It's similar to how cvs-rs doesn't make this a lie; a bug isn't in scope to what we're talking about 99% of the time.

In context, I'd have no reason to deny that this is something you'd want to watch out for.

You and your parent are talking about slightly different things. You are both correct in different ways.

Your parent is saying that, while what you say is true for Rust and Go code themselves, in practice, it is less true for Rust, because Rust code tends to call into C code more than Go code does, and Rust doesn't always statically link to that C code by default.

Oh that makes more sense! That's a bit of a blindspot to me for the pretty bog-standards ways I'd been using Rust and Go.

Well, given that this has been going on for years, you can already start to empirically evaluate that question.

> (So far, it's a not-very-complete client. But watch this space!)

Yes, it's a beginning not the end.

Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.

Rust has no malloc in the language whatsoever. In embedded, you don't even include the libraries for dynamic allocation in the first place, unless you want to. And it's very normal not to.

Not your parent, but I'd expect they mean https://en.wikipedia.org/wiki/Defunctland

His recent videos on Imagineering's animatronics and "Living Characters" was incredible.

Using Rc doesn't sound like an intrusive list to me. Personally I find tons of Rcs to be messy, so I'd agree with you.

> what performance cost Rust code pay due to inability represent cyclic structures efficiently?

You can still write the code you'd write in C with unsafe. There's no inherent loss left on the table.

Furthermore, a lot of C folks reach for intrusive lists because it's easy in C, but that doesn't mean that it's always the most performant. See https://bcantrill.dtrace.org/2018/09/28/the-relative-perform... as an example of this phenomenon.

It's being worked on! https://github.com/rust-lang/rfcs/pull/3470

Not just that, the author is the Project Editor for WG14.

This doesn’t mean that it’s impossible to make mistakes, but still.

It means he can edit LaTeX. Of course, JeanHeyd is very qualified, but being project editor for an ISO standard does not require this.

I mean, you're closer to the committee than I am, but while that is true in a literal sense, I'd assume that you all would not let someone who knew how to edit LaTeX but not know anything about C hold that position.

Assuming we have some choice. Not many people volunteer their time to this work, which is quite a lot and not much fun. Companies also do not invest a lot of resources into C.