eddyb · HackerTrans

eddyb

no profile record

Submissions

Rust-101: A hands-on Rust tutorial

ralfj.de

7 pointsby eddyb11 yıl önce0 comments

comments

8 ay öncediscuss

> So what was the screenshot feature of X11?

In case I wasn't clear enough, there was never a screenshot feature. Any X11 client could read any pixel written by any other X11 client.

> Have all the best or most popular apps been updated to ensure no disruption?

I am not familiar with DE-agnostic "screenshot apps" for Linux, they always seemed more common on other OSes, and I've always used the DE-specific apps (which were the first to support such mechanisms, some of them even using more direct DE-specific private protocols instead of XDG Portals).

But I spent a few seconds googling for general screenshot apps, found Flameshot (which makes sense as a cross-platform app), and it turns out that support for the XDG Portal approach was added to it almost 5 years ago:

https://github.com/flameshot-org/flameshot/pull/1272

And if you peek around the diff, you can tell that KDE/GNOME-specific support, on Wayland - using DBus but not the XDG Portals protocol - already existed, in early 2021, in fact...

https://github.com/flameshot-org/flameshot/commit/a5df852268...

That's the commit that added KDE/GNOME-specific Wayland screenshot support.

8 years ago, in a 3rd-party app!

> Why can't the infrastructure include the user simply allowing the app to continue to have access without a specialized infrastructure of app request (that requires updating the app)?

I'd forgotten that this happened, but for screensharing from a X11 client, someone already went through the trouble of emulating it (on top of the XDG Portals + PipeWire infrastructure):

https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/

It's only a temporary hack, and it only matters for X11 clients running under XWayland - if an app can run as a native Wayland client, it should have XDG Portals-based implementations of relevant features.

> What's with the downplaying "just" again? Have all the best or most popular apps been updated to ensure no disruption?

Am I downplaying, or are you describing a vague category of "the best or more popular apps" without giving examples?

I feel like it's too easy for some of this stuff to end up in FUD-like arguments without considering the objective reality (of how far we've come in the past few years etc.).

Anyway, my subjective take is that X11 took a decade or two too long to die, and most (if not all) gripes users might have with Wayland can be traced back to X11 outliving its UNIX Workstation origins and having never been designed as a Personal Computing graphical environment.

8 ay öncediscuss

If you're not familiar, the way X11 works is comparable to "multiplayer notepad" for your pixels ("multiplayer MSPaint"?).

All your monitors are combined into a large canvas where every pixel can be written and read by any X11 client.

Screenshots (and screen sharing) could be silently performed with zero user feedback (or any good way to even detect when apps might be doing this maliciously, AFAIK).

This is one of the big "security implications" that motivated Wayland (and somewhat similarly, the Flatpak sandbox and the XDG Portal infrastructure that has by now outgrown it).

The infrastructure is already there, for 3rd party apps to request these abilities (with the user getting the choice of following through, or denying the request), e.g.:

- https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

- https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

Keep in mind that any action which doesn't require interactivity every time (e.g. restarting the screensharing of a previously-chosen window/display) could have "user gave permission" be remembered, but that seamless case still only applies to that combination (so that client can't peek at anything else than what it was offered).

Anyway, what the blog post is talking about is really just 3rd party apps that haven't been updated (and e.g. might already not function properly inside Flatpak).

> feature parity

If we are being honest, screenshots/screensharing was never a "feature" of X11, it was a big security hole abused as a feature.

8 ay öncediscuss

If your Linux distribution is handling Mesa packages correctly, you will never lack OpenGL/Vulkan drivers.

The reason is that Mesa includes "software rendering" drivers for both OpenGL ("llvmpipe") and Vulkan ("lavapipe"). As the name(s) might suggest, they use LLVM to JIT shaders for your CPU (supporting SIMD up to AVX2, last I checked - although typical compositing shaders tend to get pattern-matched and replaced with plain `memcpy`s etc.).

So you should always be able to run a fully-featured Wayland desktop (albeit limited in performance by your CPU), on any unaccelerated framebuffer, nowadays (and I remember doing this even before Plasma 6 launched, it may be older than usable Wayland desktops tbh - the Mesa code sure is, but maybe distros hadn't always built those drivers?).

2 yıl öncediscuss

Not sure if there's a better section elsewhere, but at least this one touches on it: https://doc.rust-lang.org/reference/destructors.html#tempora...

3 yıl öncediscuss

This is effectively a rustdoc bug, the pattern is very much part of the body of the function, not the signature (and this split is explicitly represented in the compiler IRs, which rustdoc effectively undoes).

While it's not really how it works, the closest valid Rust that comes to mind is:

    const foo: fn(u32) = |mut x| {};

What rustdoc should be doing is stripping binding modes (`ref` and/or `mut`), or even whole patterns - with more complex patterns, like `(a, mut b): (T, U)`, it can be beneficial to keep `(a, b)` as a way to label the two components, but the `mut` is superfluous for documentation.

4 yıl öncediscuss

> So what are you using or recommending?

I am using KDE (aka Plasma5) in Wayland mode, on NixOS unstable.

I would not recommend NixOS, just like I mentioned, and I didn't really want to get into the weeds of why, but while Nix is something that more people should try out if they're already familiar with unfortunate asymmetries (e.g. "git's data model is really nice" vs "git's CLI has sharp edges and some workflows the data model implies are entirely unserviced") and/or like to play around with experimental unpolished software, I would maybe avoid it until they actually come up with a "more declarative"/"less computational" flavor for 99% of usecases.

I've used openSUSE in the past, and while YaST2 might be less relevant now, it was shocking how much similar things were outright lacking back then (a lot of this was pre-NetworkManager to be quite fair).

A lot of people like Arch, and if Debian/Ubuntu package management doesn't get in the way I suppose KDE Neon might be nice? (I keep forgetting KDE's Discover exists, it might also help with not dealing with package management directly)

---

> FF crashing

Quite ironically, if it is https://bugzilla.mozilla.org/show_bug.cgi?id=1743144 that's technically a gtk limitation (not only does it lead to the FF main thread having to poll gtk often enough to keep the Wayland connection from breaking, but when it does break it calls `_exit` so Firefox can't even do crash reporting, and they refused a patch to address this), and it can also happen for Chrome (which also uses Wayland through gtk AIUI).

If you want to check if it is the case, you can look in the logs (e.g. through `journalctl -o with-unit -r`) for "error in client communication".

> middle-click gets in the way a lot and can't be switched off

Are you talking about the feature controlled by System Settings -> Input Devices -> Mouse -> "Press left and right buttons for middle-click"? (that is, if you intentionally press both buttons, does it trigger middle-click?)

AFAIK that's off by default, but I am on a different distro and running KDE/Plasma 5.25.4 and maybe it changed at some point, or maybe it's specific to touchpads? (which I sadly can't test because I only have an older Nvidia laptop, that can't use the Wayland-compatible drivers, or rather I would have to switch to nouveau first and deal with that etc.)

> insists on chromium as default browser

I've had issues with this in the past, some apps provide their own configuration instead of going through XDG mechanisms, or at least have suboptimal defaults.

I would check the settings of the apps which cause chromium to start, and maybe play around with Flatpak/forcing the use of XDG Portal, but that might be too much to ask.

4 yıl öncediscuss

GNOME has kind of always been on the opposite end of the configurability spectrum from KDE, IME.

But also I'm not super clear on how libinput fits into the picture, I think there used to be some Synaptics-specific integration in certain places that I never went back to, to confirm the differences (switched to libinput several years before, and I've completely forgotten since what I was trying to solve back then).

Anyway, I ended up writing a mostly-personal-anecdote below, that would likely not help, so you can probably skip it (if you do want to try anything, KUbuntu and https://neon.kde.org are both on top of Ubuntu, and there's other distros, but I've not kept up with any distro I might recommend)

---

I tried Ubuntu (w/ the GNOME default) once (back in KDE 4 times IIRC) and the lack of almost any flexibility felt like I was stuck in a sandbox (a literal one, like from when we were kids, not that it's easy to remember that far back).

The only other time I felt like that was when a friend gave me their old iPhone (6 IIRC?) "to see what it's like" and I had to give up trying it out because both the OS, and the few apps I could find (for its max supported iOS version), had random chunks of features missing (tbh I should've jailbroken it, then it'd just be one more piece of hardware I have no immediate use for - but I digress)

KDE is far from perfect (switched to Wayland recently, and been tracking a few QoL leaps in the next couple releases), but I can at least try to tweak it - same goes for using NixOS or ZFS tbh (not going to even defend those, but I have done both Gentoo-like shenanigans, and randomly RAIDed a dual-SSD laptop, respectively, quite painlessly despite not preparing for it from the start, and the weirdness budget is personally paid for a thousandfold).

Meanwhile I run into e.g. GNOME apps using libadwaita nowadays needing environment variables (that appear deprecated?) to apply the KDE gtk integration theme so they don't stick out like a desaturated winamp skin.

I've never felt like "power user" applied well to myself, like I'm not doing the equivalent of weight-lifting for computers, never want to be doing sysadmin if I can avoid it, I just want to have enough control to make things seamlessly neat for myself.

Opinionated defaults are great in the same way you'd set up a house for a marketing reel, but if I actually buy it, why would I have to deal with a landlord telling me I can't paint the walls or move/replace some furniture to maximize my comfort?

The "personal" in "personal computing" is supposed to be the same as the one in "personal property", and so I'd have similar expectations of "can screw with it without asking for permision" for both (modulo real estate being seen as an investment, and building codes, etc. - should've picked a smaller example than a house, oh well).

To stretch the house analogy further, just like I have leased (some corporation's) private property as office spaces, I would be fine to doing the same (also for business reasons) with e.g. a cloud platform (most likely through GHA, whenever they announce the paid tiers) - tho be fair to everyone, this applies far more to walled gardens than opensource software like GNOME.

Also, to be clear about the "sandbox" thing: sandboxes (and/or ideally more objcap systems) are great, and I think that the XDG Portal work is incredible for what it allows: the apps are getting sandboxed, the user getting more power over them.

Even without Flatpak (which I keep meaning to try out), I was happy to see e.g. the KDE Wayland screenshare dialog outright has an option for "create virtual screen" (which can further be configured in the KDE settings, and e.g. partially overlapped with a physical monitor, etc.). If the app was in charge, they would barely enumerate some of the windows correctly, let alone provide new virtual screens.

4 yıl öncediscuss

> Maybe it would be called #[expect(deprecated)]

Both this and the reply saying you should open an RFC worry me that it was tongue-in-cheek.

Or maybe it's the obvious name choice, heh, because it literally exists with that very syntax: https://play.rust-lang.org/?version=nightly&mode=debug&editi...

Not stable yet, as you can see, but all the RFC and implementation work has been done, and a stabilization report was even put forward back in July: https://github.com/rust-lang/rust/issues/54503#issuecomment-...

4 yıl öncediscuss

We explicitly support building against librustc_driver-*.so for both "custom drivers" (what we call those binaries I mentioned) and generally "rustc as a library" usecases. We should maybe rename it to librustc and remove as much potentially-confusing "driver" terminology as possible.

Pinning a nightly and installing the "rustc-dev" rustup component are both necessary, the former because internal APIs of rustc aren't stable, but it's a supported usecase.

Both clippy and miri are developed out-of-tree like that, and sync'd using `git subtree` (or `git submodule` but we want to move everything to subtree).

4 yıl öncediscuss

> but also parts of rustc are implemented in a dynamic library ("librustc_driver")

Nit: 100% of rustc is found within librustc_driver-*.so (I mention it in https://news.ycombinator.com/item?id=32329062 - which also touches on stable ABI).

`rustc` just calls into the .so without any custom configuration: https://github.com/rust-lang/rust/blob/e141246cbbce2a6001f31...

(but rustdoc/clippy/miri all have additional configuration, passes, etc. specific to them)

Also, if you look at the `rustc` executable's size:

    $ du -bh ~/.rustup/toolchains/nightly-*/bin/rustc
    17K     /home/eddy/.rustup/toolchains/nightly-2018-01-01-x86_64-unknown-linux-gnu/bin/rustc
    2.9M    /home/eddy/.rustup/toolchains/nightly-2021-12-02-x86_64-unknown-linux-gnu/bin/rustc
    2.9M    /home/eddy/.rustup/toolchains/nightly-2022-01-13-x86_64-unknown-linux-gnu/bin/rustc
    2.7M    /home/eddy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc

17K is what it should be, I'm not sure where the extra 2.7M are coming from - my current suspicion is that it's entirely statically linked jemalloc, which I guess we didn't want to impose on all users of rustc_driver, but it might be worth doing it anyway.

4 yıl öncediscuss

[continued from above due to size limit]

What I'm referring to is incremental recompilation with the following properties:

1. automatic correctness

` - that is, a compiler change not explicitly updating anything related to dependency tracking should at most result in conservative coarser-grained behavior, not unsoundly cause untracked dependencies

` - manual cache invalidation logic is a clear indicator a compiler isn't this - e.g. this rules out https://gcc.gnu.org/wiki/IncrementalCompiler (maybe also Roslyn/C# and the Swift compiler, but I'm not sure - they might be hybrid w/ automated coarse-grained vs manual fine-grained?)

` - the practical approach to this is to split workload into work units (aka tasks/queries/etc.) and then force information flow through centralized "request"/"query" APIs that automatically track dependencies - see https://github.com/salsa-rs/salsa for more information

` - research along the lines of ILC (Incremental Lambda Calculus) might yield more interesting results long-term

` - outside of a compiler, the only examples I'm aware of are build systems like tup (https://gittup.org/tup/) or RIKER (https://github.com/curtsinger-lab/riker) which use filesystem sandboxing (FUSE for tup, ptrace/seccomp-BPF for RIKER) for "automatically correct" build dependencies

2. fine-grained enough

` - at the very least, changes within function bodies should be isolated from other bodies, with only IPOs ("interprocedural optimizations", usually inlining) potentially introducing additional dependencies between function bodies

` - one extreme here is a "delta-minimizing" mode that attempts to (or at least warns the developer when it can't) reduce drift during optimizations and machine code generation, such that some fixes can end up being e.g. "patch a dozen bytes in 200 distro packages" and get quickly distributed to users

` - but even with history-agnostic incremental recompilation (i.e. output only depends on the current input, and past compilations only affect performance, not other behavior), function-level incremental linking (with one object file per function symbol) could still be employed at the very end, to generate a binary patch that redirects every function that grew in size, to additional segments added at the end of the file, without having to move any other function

3. propagating only effective "(query) output" changes

` - also called "firewalling" because it blocks irrelevant details early (instead of redoing all work transitively)

` - example 1: editing one line changes the source byte offsets of everything lower down in the file, but debuginfo doesn't need to be updated since it tracks lines not source byte offsets

` - example 2: adding/removing explicit types in a function should always cause type checking/inference to re-run, but nothing using those type inference results should re-run if the types haven't changed

4. extending all the way "down" (to machine code generation/object files/linking)

` - existing optimizing compilers may have a hard time with this because they didn't design their IRs/passes to be trackable in the first place (e.g. a LLVM call instruction literally contains a pointer to the function definition, with no context/module/pass-manager required to "peek" at the callee body)

` - can be theoretically be worked around with one object file per function, which https://gcc.gnu.org/wiki/IncrementalCompiler does mention (under "Code Generation" / "Long term the plan is ..."), but that alone isn't sufficient if you want optimizations (I've been meaning to write a rustc proposal about this, revolving around LLVM's ThinLTO having a more explicit split between "summary" and "full definition")

5. extending all the way "up" (to lexing/parsing/macros)

` - this is probably the least necessary in terms of reducing output delta, but it can still impede practical application if it becomes the dominant cost - AFAICT it's one of the factors that doomed the GCC incremental experiment ("I’m pretty much convinced now that incremental preprocessing is a necessity" - http://tromey.com/blog/?p=420)

` - outside of "rebuild the world", this also makes a compiler much more suitable for IDE usage (as e.g. a LSP server)

My experience is mostly with the Rust compiler, rustc, whose incremental support:

- started off as coarse skipping of generating/optimizing LLVM IR

- has since evolved to cover 1./2./3.

- while many passes in the "middle-end" were already both "local" and "on-demand", sometimes allowing incrementalization by changing only a dozen lines or so, 4. is indefinitely blocked by LLVM (at best we can try to work around it), and 5. (incremental "front-end") has been chipped at for years with several factors conspiring to make it orders of magnitude more difficult:

` - macro expansion and name resolution being intertwined (with the former mutating the AST in-place while the latter being a globally stateful algorithm)

` - "incremental front-end" used to be seen as essential for IDE usage and that notion started falling apart in 2018 or so (see rust-analyzer aka "RA" below, though RA itself is not itself directly responsible, nor do I hold it against them - it's a long messy story)

` - this work (without the IDE focus, AFAICT) has mostly driven by random volunteer work, last I checked (i.e. without much "official" organization, or funding, though I'm not sure what the latter would even be)

- its design has been reimagined into the "salsa" framework (https://github.com/salsa-rs/salsa - also linked above)

` - most notable user I'm aware of is the rust-analyzer (aka "RA") LSP, which hits 1./2./3./5. (4. isn't relevant, as RA stops at IDE-oriented analysis, no machine code output) - without getting too into the weeds, RA is a reimplementation of "Rust {front,middle}-end", and ideally eventually rustc should be able to also be just as good at 5. (see above why it's taking so long)

I am not aware of any other examples of industrial compilers having both 1. and 2. (or even academic ones but I suspect some exist for simple enough languages) - every time someone says "incremental compilation? X had that Y decades ago!", it tends to either be manually approximating what's safe to reuse (i.e. no 1.), or have file-level granularity (i.e. no 2. - the "more obviously correct" ones are close to the "separate compilation" of C/C++/many others, where a build system handles parallel and/or incremental rebuilds by invoking the compiler once per file), or both.

While 2./5. are enough to be impressive for IDE usage all by themselves, the interactive nature also serves to hide issues of correctness (lack of 1. may only show up as rare glitches that go away with more editing) or inefficiencies (lack of 3. leading to all semantic analyses being redone, may still be fast if only requested for the current function).

Another thing I haven't seen is distro build servers talking about keeping incremental caches around (and compiling incrementally in the first place), for builds of Rust "application" packages (most of them CLI tools like ripgrep, I would assume) - it's probably too early for the smaller stuff, but a cost/benefit analysis (i.e. storage space vs time saved rebuilding) would still be interesting.

4 yıl öncediscuss

No, at most we would've invested more in e.g. ensuring¹ you cannot accidentally (or intentionally) mix-and-match shared objects not built by the same build process, or in ways to reduce the cost² of safe ("full relro") dynamic linking.

¹ via forcing the dynamic linker to eagerly resolve some symbols, global constructors, etc. - see https://github.com/rust-lang/rust/issues/73917#issuecomment-... for some recent discussion

² such as exporting a single base symbol per dylib (with a hash of code/data contents in the symbol name, for integrity), and statically resolving imports (to constant offsets from that base symbol), when linking object files into dylibs/executables - because of how position-independent code indirects through the "GOT", in practice this would mean that the dynamic linker would only need to lookup one symbol per dependency .so instead of one per import (of which there can be hundreds or thousands)

Also, "dynamic linking" in Rust was never really "dynamic" or about "drop-in replacement to avoid rebuilds", it was only about the storage reuse of "shared objects", with the "late-binding" semantics inherent in dynamic linking a negative, not a positive.

For example, rustc, rustdoc, clippy, miri, etc. are all relatively small executables that link against librustc_driver-*.so - on a recent nightly that's 120MiB, with only static linking that'd be half a GiB of executables instead. The relationship is "one .so shared between N executables" not "one .so per library". Also, if we could remove runtime symbol lookup but keep the separate .so (like ² above), we totally would.

---

At the same time, Rust's continued evolution depends on being able to (almost) "never ask for permission" when changing internals that were never guaranteed to be one thing or another.

Rust recently fixed most platforms to use simpler and more performant locks based on futex(-like) APIs (see https://github.com/rust-lang/rust/issues/93740 and PRs like https://github.com/rust-lang/rust/pull/95035), and this meant that e.g. Mutex<T> has a 32-bit (atomic) integer where a pointer used to be.

An even more aggressive change was decoupling Ipv{4,6}Addr/SocketAddrV{4,6} from the C types they used to wrap internally (https://github.com/rust-lang/rust/pull/78802) - that one actually required library authors to fix their code in a few cases (that were very incorrectly reinterpreting the std types as the C ones, without this ever being officially supported or condoned).

Imagine trying to do that in C++. The stories I keep hearing from people involved in the C++ standard are tragic, more and more otherwise-uncontroversial improvements are being held back by poorly-motivated stubbornness around ABI stability. Large-scale users of C++, like Google, have long since migrated from C++'s standard library to their own replacements (e.g. abseil) for many of their codebases, and I kept hearing Google were "forking C++" (over the frozen ABI debacle specifically), long before it came out as "Carbon".

---

The technology to coherently³ avoid today's rebuild-the-world cost in compiled languages⁴ isn't here yet IMO.

³ as in, guarantee identical behavior to the full rebuild from scratch, without introducing inconsistencies that could cause logic errors, memory corruption, etc.

⁴ some/most C libraries of course being the biggest exception - and while it's possible to intentionally design libraries like this in any language that can do FFI, it's fundamentally antithetical to "zero-cost abstractions" and compiler optimizations - nowadays the latter are forced even on otherwise-patchable C dependencies via LTO, in the interest of performance

What I'm referring to is incremental recompilation with the following properties:

...

[oops, hit comment size limit! I'll post the rest separately]

4 yıl öncediscuss

It's a shame LLVM isn't more explicit about calling conventions (especially since the front-end has to lower most of the platform-specific C ABI details, short of the exact list of registers or stack offsets, into LLVM IR anyway).

(if it was more expressive, we could have e.g. specifiers similar to inline `asm!`, but on a function signature, to fully describe its call ABI)

In the meanwhile, I agree - if you need some entry-point to have a custom ABI (especially if you need it parameterized through generics), `#[naked]` + inline `asm!` is the only viable option for now.

Especially with const generics, you can do some cool stuff to make very compact trampolines that e.g. embed immediates directly into instructions (though it's sad that `const` operands in inline `asm!` aren't stable yet).

But for interrupt ABIs I would hope that LLVM can fully support them and avoid any inefficiencies that "whole body is one inline `asm!`" could create by blocking LLVM from doing optimizations, clever register allocation, etc.

(that is, they let the user control when they do something special with inline `asm!` vs regular code that LLVM understands)

4 yıl öncediscuss

Don't you want "interrupt ABIs" for that specific usecase?

IIRC `#[naked]` are only really guaranteed to allow inline assembly, so it's like defining a function in `global_asm!` except for monomorphization and generally interfacing better with the rest of the language.

4 yıl öncediscuss

> For instance `(*role).name` creates a `&mut &'static str` behind the scenes which is illegal, even if we can't observe it because the memory where it points to is not initialized.

Where is this coming from? It's literally not true. The MIR for this has:

        ((*_3).0: &str) = const "basic";
        ((*_3).2: u32) = const 1_u32;
        ((*_3).1: bool) = const false;

So it's only going to do a raw offset and then assign to it, which is identical to `*ptr::addr_of_mut!((*role).field) = value`.

Sadly there's no way to tell miri to consider `&mut T` valid only if `T` is valid (that choice is not settled yet, AFAIK, at the language design level), in order to demonstrate the difference (https://github.com/rust-lang/miri/issues/1638).

The other claim, "dereferencing is illegal", is more likely, but unlike popular misconception, "dereference" is a syntactic concept, that turns a (pointer/reference) "value" into a "place".

There's no "operation" of "dereference" to attach dynamic semantics to. After all, `ptr::addr_of_mut!(*p).write(x)` has to remain as valid as `p.write(x)`, and it does literally contain a "dereference" operation (and so do your field projections).

So it's still inaccurate. I believe what you want is to say that in `place = value` the destination `place` has to hold a valid value, as if we were doing `mem::replace(&mut place, value)`. This is indeed true for types that have destructors in them, since those would need to run (which in itself is why `write` on pointers exists - it long existed before any of the newer ideas about "indirect validity" in recent years).

However, you have `Copy` types there, and those are definitely not different from `<*mut T>::write` to assign to, today. I don't see us having to change that, but I'm also not seeing any references to where these ideas are coming from.

> I'm pretty sure we can depend on things being aligned

What do you mean "pretty sure"? Of course you can, otherwise it would be UB to allow safe references to those fields! Anything else would be unsound. In fact, this goes hand in hand with the main significant omission of this post: this is not how you're supposed to use `MaybeUninit`.

All of this raw pointer stuff is a distraction from the fact that what you want is `&mut MaybeUninit<FieldType>`. Then all of the things about reference validity are necessarily true, and you can safely initialize the value. The only `unsafe` operation in this entire blog post, that isn't unnecessarily added in, is `assume_init`.

What the author doesn't mention is that Rust fails to let you convert between `&mut MaybeUninit<Struct>` and some hypothetical `&mut StructBut<replace Field with MaybeUninit<Field>>` because the language isn't powerful enough to do it automatically. This was one of the saddest things about `MaybeUninit` (and we tried to rectify it for at least arrays).

This is where I was going to link to a custom derive that someone has written to generate that kind of transform manually (with the necessary check for safe field access wrt alignment). To my shock, I can't find one. Did I see one and did it have a funny name? (the one thing I did find was a macro crate but unlike a derive those have a harder time checking everything so I had to report https://github.com/youngspe/project-uninit/issues/1)

4 yıl öncediscuss

I live in Bucharest, Romania and I pay $9/mo for 1Gbps FTTH (fiber into my flat, with an ISP-provided fiber terminal).

This offering is available from digi.ro pretty much throughout most major cities (so city area doesn't matter unless you go outside, into suburbs and villages - not sure how far the fiber penetration reaches).

They announced 10Gbps a few months ago, for only a 25% price increase (someone else linked the announcement already) - but I'm still on the waiting list, and I'm not sure what their deployment progress is like.

I wish I could offer real numbers for 10Gbps - for 1Gbps I remember getting:

* >900Mbps download locally (P2P, fast.com, etc.)

* 300-500Mbps both directions, across Europe (e.g. to Hetzner servers)

* not sure about intercontinental, but I suspect latency could be more of a problem there, depending on your usecase

(Frankly, consumer networking equipment has been getting in the way of reliably maxing out what the ISP offers, in a multi-device environment, and I've been procrastinating getting more professional hardware since the difference is mostly only visible when measuring it explicitly)

As for affordability: you can live here decently for around $1k/mo, maybe a bit more depending on rent, so if you have an international source of income (or a good chunk of savings), you could easily spend years here.

(Most of my monthly costs go towards food, and I don't have good points of reference for that - I can't remember what it was called, but there was at least one website for breakdowns of living costs in various parts of the world)

One downside is you may need to learn a bit of the language, depending on how much you need to interact with the average person that might not know any English (but this has gotten easier with e.g. using delivery during lockdowns).

OTOH, English has been permeating a lot more, starting with millennials, so you could get lucky.

Have fun! (though realistically there are likely more convenient options)

5 yıl öncediscuss

I agree that ARM isn't going anywhere, as long as it can be licensed for less than it takes to design a good-enough RISC-V core, it will get used (with opensource designs slowly lowering the latter on average).

It's really more the small vendor ISAs that I expect to become rarer with time, not the existing ISAs to go away.

Frankly, RISC-V feels perhaps a decade too late, but so does LLVM, and alternate history is such a rabbit hole so I won't go into it (but I suspect e.g. Apple would've had a less obvious choice for the M1, if RISC-V had been around for twice as long).

> But that also seems rather narrowly scoped to those who are willing to design & fab custom SoCs

I'm expecting most of the (larger) adopters are already periodically (re)designing and fabbing their own hybrid compute + specialized functionality - like the WD example you mention (Nvidia replacing its Falcon management cores being another).

I don't know for sure, but I also suspect some of them also want to avoid having Arm Ltd. (or potentially soon, Nvidia) in the loop, even if they could arrange to get their custom extensions in there.

5 yıl öncediscuss

> Or I'm missing something big.

It's the software tooling cost.

There's nothing exceptional in the spec because it's trying to insert itself into the industry as a standard baseline, so staying small and simple is pretty intentional.

Its whole deal is that you can design a 2040's ISA or whatever you want and run 2015 Linux on it.

Everyone is jumping on it because no longer do they have to deal with a GCC/LLVM backend, and a long tail of other platform support: they can focus on the hardware, and put their instructions on RISC-V (with some set of standard extensions).

The other thing, though less impactful on the industry adoption, is that the simplicity allows hardware implementations (aka "microarchitectures") to replicate intricate out-of-order designs that we're used to in high-performance x86 (and ARM) cores, with a small fraction of the resources (https://boom-core.org/).

The real question in the high-performance space is: who will be the first to get an OoO RISC-V core onto one of TSMC's current process nodes (N7, N5, etc.)?

5 yıl öncediscuss

You could look at Cranelift, which I believe uses integer indices, and several datastructures for control-flow vs dataflow.

There is no SSA IR in rustc itself (MIR, regrettably, only lowers control-flow, but uses variables instead of representing dataflow).

6 yıl öncediscuss

Not at all, RISC-V doesn't need extremely clever compilers, and instead it's designed to maximize what the microarchitectures (hardware implementations) can do, and reduce unnecessary overhead.

My reply was mostly aimed at the idea that you can move the complexity from hardware into compilers: it might be possible, but we know how to build out-of-order CPU better than we know how to build smart compilers, so you have to invest a lot more research time, and it's generally a lower priority.

Even innovations from the past decade or two, like VSDG, haven't made their way into "industrial" compilers yet.

As for the size thing:

GCC and Clang are huge (at least when you include their entire change history, which git does), RISC-V is comparatively only a tiny part of them, you should probably look into that further before jumping to conclusions.

You don't even need a whole separate toolchain with Clang or Rust, the whole "need to build GCC yourself to cross-compile" is outdated GNU tradition, not some kind of technical necessity.