fluffything

> However, what I see is the user of cxx/autocxx saying "I am asserting that this API is sound."

And since the API of this library allows this assertion to be performed in safe Rust code, when it fails, safe Rust code has UB, which according to the Rust language reference makes the API of this crate unsound.

Unsound safe Rust APIs are broken Rust code. The Rust language spec and toolchain make no guarantees about what the behavior of these APIs is.

So that's what I see here. Just another safe Rust API that is broken by design. Maybe with the twist that this crate is actually a factory to generates thousands of those broken safe Rust APIs in masse, which kind of makes it worse than your usual "broken API" bug (which is what these are, these are soundness bugs in Rust libraries).

Rust requires all safe Rust code to not have undefined behavior.

Party A wanting safe Rust to have undefined behavior was wrong. Party A now adds unsafe to their API, so that undefined behavior only happens in unsafe Rust.

I don't see the compromise anywhere. Party B told party A that they were wrong, and party A acknowledge it and fixed their crate.

How is that a compromise?

The unsafe in `unsafe mod ffi { ... }` is literally the proof that all APIs exposed in the block are sound to call from safe Rust.

It would only need to go hand in hand with a comment explaining why each API in the block is sound to call safely, and it allows users to not list unsound APIs in there, but wrap them manually when needed. Along with code that checks the C++ lib version, etc. to make sure that the proof are kept in sync with each version of the lib.

That's completely different from not requiring any unsafe in the Rust side, and doing this en masse via bindgen.

To me they are categorically identical.

Rust code author knowingly exposes unsound safe Rust APIs.

The details are different. Actix did so in their own project and were willing to fix it (the debacle was mostly social, and in some sense even accidental), while here exposing unsound safe Rust APIs is the whole raison d'etre of the project.

AutoCXX doesn't even check that the underlying C++ code does not change. So even if an autogenerated safe Rust API happens to be "accidentally safe", that can change any time without Rust users knowing.

That would completely resolve my concern about cxx.

(i still think its a soundness bug in Rust that `extern { }` does not require unsafe since one can use it to trigger UB in safe Rust code)

We already had this debate many times.

One of the last ones was the actix debacle, which was contained and accidental and ended up badly.

This is IMO infinitely worse.

I agree with you.

But this discussion is about a tool that:

* does not change the C++ code to behave correctly for all inputs

* does not (and technically cannot) generate safe Rust bindings that keep the invariant (the bindings are automatically generated under the assumption that all C++ code is safe for all inputs).

Ralf Jung's views there are perfectly reasonable.

    unsafe  { ... } 

is a soundness proof, it reads "the code within this block is sound".

People lying about having proved safety in their crates accidentally is bad. People doing this intentionally is extremely bad and I wish there was a way to automatically reject being able to depend on intentionally unsound crates in crates.io (or ban their authors are their crates from pushing anything to crates.io since they cannot be trusted).

Code generators that automatically generate thousands of broken soundness proof en masse and by design are IMO the ultimate evil. They completely defeat Rust's purpose. It makes absolutely no sense to interface Rust and C++ in this way, and the people doing this would be better off by just sticking to C++ instead of trying to make safe Rust unsound.

If safe Rust cannot be trusted, Rust value proposition is _dead_ (you cannot hack without feat anymore, refactor without fear, avoid segfaults, ...). This people are writing tools to automatically generate massive amounts of broken Rust code. If crates.io does not protect Rust users from them, we need a different crate repository that does.

Sure, but safe Rust functions can _always_ be used safely. If your function cannot always be used safely, either it is an `unsafe` Rust function, or your program is broken according to the Rust spec.

Publishing safe Rust APIs that are _intentionally_ unsound should at best be warned about to any other crate that depends on it. Ideally, those authors and their crate would simply be banned.

If it does not require `unsafe` to call these bindings, then the code they execute _must_ be sound according to _Rust_ rules.

If this is not the case, then this whole library thing is _unsound_. We really need an "intentially-broken" tag in crates.io to identify crates that lie about their soundness intentionally.

If the C++ they bind to is not safe, then allowing these to be called from safe Rust is unsound.

Those are good points. It would be cool to know the focus of the conferences in advance. Until now most conferences were single track only (the ones you mentioned with two tracks are the exception) but some at least felt pretty well balanced.

Maybe I just know Rust better now and what felt technical back then does not anymore.

I already knew that Rust's community was great.

I guess i was just hoping for more technical content. Maybe I just had the wrong expectations. In the other Rust conferences there were always at least one or two more technical talks.

I skimmed through the talks and the content seems to be more focused at PMs evaluating using Rust than at Rust programmers themselves.

I don't think I learned anything.

This user collected a list with linked time stamps: https://www.reddit.com/r/rust/comments/idecaz/rustconf_is_on...

RustConf 2020 - Opening Keynote

RustConf 2020 - Error Handling Isn't All About Errors

RustConf 2020 - How to Start a Solo Project That You'll Stick With

RustConf 2020 - Under a microscope - exploring fast and safe rust for biology

RustConf 2020 - Bending the curve - a personal tutor at your fingertips

RustConf 2020 - My First rust project - starting a 2d game with amethyst

RustConf 2020 - Controlling telescope hardware with rust

RustConf 2020 - Macros for a more productive rust

RustConf 2020 - Rust for non-systems programmers

RustConf 2020 - Closing keynote

Honestly, i've been hearing the criticism "What you put a lot of work into accomplishing should be free" my whole life. There is a full sub-reddit for these things (/r/choosingbeggars).

> That's cool if you can remember roughly what the command is called. > > [ ... ] > > In a GUI, I'm fairly sure I could find this easily, in emacs it is "go to google" and find out that you want sgml-petty-print or whatever.

I just yank into a new buffer, set it to xml mode, "M-x indent" reveals the command to format xml (indent-region or indent-buffer or something like that), enter, yank it back. Done.

In an editor with a gui, I would just go to "Help -> Search" and do pretty much the same, which would reveal the menu item to click to achieve something. I find emacs ido/helm workflow for this much better. Never need to memorize anything.

> So, the sky isn't falling yet,

Now we are literally only one step away from not being able to run our own software on Macs without paying Apple 100$/year (or whatever amount they want).

They just need to disable adhoc blocking, and require a signed developer. All systems are in place for this. The only thing they need to justify such a change is a "catastrophe". For example, next year, some macos malware might pop up, that could have been prevented with this signing. And Apple could just use that as an excuse to fully lock their platform.

> You stop using Apple and go to a reasonable OS. You and I are not going to help Apple keep their $2T valuation, we are no longer the market not been one for 5 + years for Apple

Or you just buy apple stock and keep using Apple ? That way you are just helping yourself.

Or just disassemble the binary and grep for avx-512 or avx2 instructions ?

Or if SQL server is open source, just go to their github/gitlab/whatever repo, and enter the name of a commonly-used avx512 intrinsic on the search field ?

> may as well not exist if it is not easily discoverable.

But it is easily discoverable ?

I literally just do M-x and can I get a buffer open with _all_ emacs commands and their explanation, and can do a fuzzy search on that, e.g., so if I type "M-x align re" I get only one command highlighted that can just execute "align-regexp".

That's the main thing I like about emacs. I don't have to remember a million shortcuts, just what things are possible, and then I just type a description of what I want to do and hit enter and that's it.

A GUI / having to use the mouse would push me completely out of "the zone".

> It should be free like the Web,

Lots of entitlement here. Apple does not owe you anything.

If you don't like Apple's terms, just don't buy their products. It really is that simple.

> Open Architecture with no black boxes.

> ‘Open’ means that you’re allowed to understand exactly how it works and that there’s no mysteries. It means having the blueprints of the machine, not a free machine.

No, this is 100% incorrect.

The Power ISA, i.e., the software/hardware interface of the CPU, is open source. This means that if you want to build a Power CPU that implements its software interface, you can do so "for free".

That's it. You don't get "the blueprints of the machine", you cannot look into how the CPU work internally and understand it, etc.

That's like having a standard API that anybody can implement, e.g., the C standard library, but which Apple, Microsoft, etc. ship as a black box binary blob, so you can't understand their implementation, search/fix bugs, etc.

So no, your claim is completely incorrect. The benefits of an open ISA only apply to those wanting to build their own CPUs, which for Power is just not even a handful of companies, none of them making their blueprints of their CPUs openly available...

For end users, your machine is as open/closed on a system with an open ISA like in one with a closed one. People paying 10k$ for a Raptor II in the name of openness are throwing their money away.

This is a completely different situation than, e.g., RISC-V, where not only the ISA is open-source, but the VHDL implementation of many RISC-V cores is also open source, and you can buy those cores today.

> These RFCs were closed

Can be reopened after minimal const generics implementation is finished (like the post discussing closure suggests) which it almost is.

> In favor of https://github.com/rust-lang/rfcs/pull/2000

That's the minimal const generics RFC.

> No other designs have been accepted to extend this yet.

A design does not need to be accepted for exploration about such a design to start.

When running a user space program, instead of executing the instruction in the assembly, the CPU will at best raise an exception, and at worse attempt to execute some other instruction. If the process doesn't have privileges to execute that other instruction, then the CPU will just raise an exception (unless if it has a big hardware bug).

I don't see how this could be a security flaw.

There is a Rust RFC for extending Rust's const generics to dependent types.

Part 0 (the minimal const generics) might be stabilized in the near future. Parts 1-3 would hopefully be explored next. Fully dependent types are introduced in part 3: https://github.com/ticki/rfcs/blob/pi-types-ext-2/text/0000-...

Wow, that's insane, thanks for sharing this.

When I had nvidia hardware, I never tried nouveau, so I never ran into this.

No. What I did show is that any multi 10.000 employee FAANG has thousands of projects on flight, some of which are good, some of which are bad.

This contradicts the claim from the OP that suggests that all the projects from one of these companies are all bad.

What hardware does apple use for all of its machine learning training (e.g. for Siri, etc. ) ?

The problem is that ROCm does not support many AMD compute cards, like their top of the line Navi-based one-year-old 5700 family.

Most frameworks do support ROCm though, so the ball is on AMDs court.