Видео

23:59 this is exactly what happened to me when i started trying to use compile time rust. I really like the language, i like a lot of the features, and I think learning it has made be better, but I switched back to C++ for my day-to-day because of garbage like this. It felt like the Rust STL and compile time stuff is extremely not-fit for production quite yet, and I'll be following the changes, but I'm still not switching over to it for large projects just yet.

Important clarification: zig currently does not allow allocations in comptime

Why using the O(n^2) loop if you could use sort instead. Implementing merge sort is easy. After you sorted your array, it is easy to extract unique values into result array. Easy in C++14 constexpr.

What about the dead simple approach Ethernet takes: 8b10 or 64b66 for newest faster variants

Interesting. I made the Serial Chinese Room, Interproces, and Telemetry Script, AKA Script2 and the SCRIPT Protocol for RPC, which is hybrid byte encoded and human readable based on contiguous data types.

16:25 I know this is not very rust-like, but do you even need the maybe-uninit? Just initialize everything with zero, you already unwrap everything that is below the current output index, so you don't even use the fact that it's an Option (you also return the number of `Some` values, so it doesn't even help on the consumer side)

"It's O(n^2) but that's the compiler's problem" its not even a problem if your n is small anyway.

20:32 oh no typo on the slides, second loop needs an increment... very good episode tho! I'm in the midst of some compile-time crimes myself, w/ a proc_macro tho, neat to see const fn crimes too :)

Wow this is just like C++ constexpr but more painful. I thought C++ is already too restrictive for when you use vectors in constexpr code but not being able to even use for loops seems annoying as hell to me. Props to you for getting it working.

I dont think most people in my life would und erstand why someone would watch this for and reason but I enjoeyed it nonetheless :)

I'd say, while having async allocator for general purpose might be questionable(since if you plan to schedule other work.while waiting for the allocation, the work might need an allocation too and it all turns onto itself perpetually), you can have a niche applIcation where you want to use Huge Pages but say implement your own allocation on top of them with whatever guarantees yoh like, since bigger page means lesser virtual page table(trivially speaking) and while Linux kernel for example can us free huge pages for general purpose also, if you really want you can and then the global allocator can still do most of the general purpose lifting while you have a clear interface to cooperatively manage "the new thing"

The reason aaui for the file uri is the os-x capability sandbox. Sandboxed applications can't just enumerate the filesystem, instead, to gain access to a file at the user's request they need to perform an NSLookup on the request. This prevents applications from gaining access to files not explicitly shared with the app by the user.

This was super fun! On FP registers: besides the fact that these are sometimes different sizes to gp registers, another reason they are often separate is that adding additional ports to a register file is very costly in space. There's additional circuitry per-register-per-port. Add to that, many implementations duplicate register files to get more fast read ports, but you still need to write to all of the register files whenever you update. Separating out the FP path, then, makes sense for FP heavy workloads. Also, I think POWER predates PowerPC, but I could be misremembering. The thinking was that when IBM, Apple, and Motarola came together to design the RISC they could all standardise on, they ended up starting from IBMs ISA and pruning out COBOL-specific instructions.

This episode had all so many little details that give great perspective on what I was already familiar with. Thanks!

There are a bunch of Power architecture CPU cores with a variable length encoding extension (VLE) in the automotive embedded space. These are like the thumb-only ARM cores, except based on PPC rather than Arm. When I started using them, you couldn't even get an upstream GCC release that supported them. There's also an arch named Coldfire which is the name under which the 68k arch lives on.

6:18 - Saying Siri turned on all of the lights in my house for some reason. LOL. Thanks Amos!

That's quite a lot of advertisement in the first minutes for such a small channel. 👋

Seems brilliant

eliza mentioned, hell yeah

Only 280 subscribers? This guy's underrated, and I bet he's gonna blow up in popularity in a few months.

I don't know how it works on other platforms, (I imagine it is similar though), but at least on wayland, clipboards are implemented as IPC. For example if you run `wl-copy`, it actually forks into the background and *hosts* the specified data under a mime type. (Which is per default determined by xdg-mime.) The `wl-copy` source code is actually very readable and is great for figuring out such details. So any export to a specific mime type can be done at the time of the request of the actual content, instead of at time out the copy.

Recently I discovered how the clipboard works on gnome, no matter if you run wayland or x11. It is really similar to Mac OS It only has those two "clipboards", clipboard and primary, since wayland copies that from x11 and gnome just uses that same format. But it also has different MIME types, it doesn't have the ability to store multiple items, but some mime types like "text/uri-list" just say that URIs are seperated by " ", so in the end you have all files you e.g. copy stored in that format. It also behaves like Mac OS, if you e.g. copy an image, it has a "image/png" mime type, and if it has an associates name also the "text/plain" of the name. the URIs are actual files in case of copied files. So after I heard that what you said about Mac OS, I am not sure if mac invented that, or linux / gnome 🤔 P.S: I use linux since 5 years now and never encontered any clipboard bug, the clipboard is just awesome and if you are a programmer or copy / paste often, you should get a application that serves as a clipboard history, windows has thateveb built in.

Surely, SURELY someone you guys know works at apple and is close to or on the Safari team. I used to be able to just twitter DM a few people, but they all left twitter.

each episode brings something interesting! 😉

So using a u8 pointer or slice has always confused me a bit. You can only free the exact u8 pointer that was allocated, right? Not part of it? So should it not be something like Allocation(NonNull([u8]))?

I read allocators as alligators and was VERY curious

Solving the wrong problem most likely. Would be better if the code could be restructured such that arena allocators could be used and freed all at once, rather than worrying about the lifecycle of every object individually.

My unpopular opinion is that we shouldn't have async anything. Just use a proper thread and stop dealing with ambiguity. It would also eliminate the viral nature of async functions. This is really just another N-cost abstraction where you have to know the internals of how it works to know the actual cost.

9:15 And now i want to allocate SIZE_MAX (or rust equivalent) bytes of contiguous memory.

allocations need to be atomic right. So if async alloc is called twice you might have cases where one of the allocations gets invalidated. eg. freeBlock->next gets set twice. If you're using mutexes for async, might as well block the whole time which is the current interface

How are you allocating a future when you get a allocation error that means oom.

If you are out of memory, then the executor is likely unable to allocate the memory needed to track the future returned from the async allocator. That kind of thing is the big challenge with failable allocation: the fail code path needs to be allocation free and (like with panic mentioned in the video) we don't have a good way to ensure a given code path is allocation free in Rust.

My personal opinion is that async alloc and/or drop should be an optional library thing rather than the default behavior of the language. Async drop for example would complicate RAII a lot since that would mean that now the lifetime of objects must be async, and since the async state machines arent strictly guaranteed to ever complete, any time you drop something you have an issue of "destructor running somewhere on an undetermined scheduler at an undetermined point in time". Which kinda defeats the point of RAII that says that objects are dropped when they exit scope. It would also mean that you have to implicitly schedule a drop, otherwise you cant drop things once they exit a scope. And for a zero-overhead language where scheduling is an explicit action its a definite no-no.

not async, but Zig's allocators are fallible

17:38 basically, C/C++ programming

this is a cool video

Ah, ETX my old friend. Never heard of COBS tho, and that's pretty awesome!

13:46 Polyglot files?

I liked the visual gag :)

Don't know much about rust but this was very relaxing, thanks!