kimundi

Yes, the macros parse the string at compiletime and generate code that does the formatting as given by them. Here is an example for how the code would look like expanded: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Think of raising an orbit like moving an item from one side of your desk to the other.

You have to put energy into doing it, but the end result is just as much in balance with gravity as the starting point. So if you want it back where it was, you need to spent the same amount of energy to move it in exactly the same way in the opposite direction.

Separating the "get to/from moon" vehicle from the "land on/start from moon) vehicle has indeed been the plan for many years now.

With dynamically sized types like `str`, Rust allows to separate "what kind of pointer + metadata is this" from "what kind of data does it point at". So, for example, you can have the types `str`, `[T]` or `Path`, and can have them behind the pointer types `&T`, `Box<T>` or `Arc<T>`.

If Rust had defined a special struct `Str` for `&str`, then it would have to define special structs for all the combinations possible: Str, ArcSlice, BoxPath, etc.

The github discussion thread where that originates from also contain the language designers optimistically discussing how in the worst case `Pin` just has to be hardcoded to exclude these optimizations. Which wouldn't make it the first type in the std lib that works similary (see interior mutability and UnsafeCell), so I personally intepret that as "unlikely to be an issue".

Fully agree with that, and Rust makes that very easy still. Its 5-10 lines to spawn multiple threads that communicate with each other either via shared state or message passing, and I solve most paralleism problems that way to this day in Rust. :D

The flip will be less extreme in later designs because they will have better/larger RCS control thrusters to rotate it without involving the main engines.

Also the center of rotation can be controlled to be inside the passenger section. Add some seats that can automatically tilt 90 degrees and the forces might be barely noticable.

Affinity is a property of the type in Rust, so any given value is affine or not depending on which type it has.

Note that that is passing by value, so its moving/copying ownership. Its like having a immutable integer variable and copying it to a different mutable variable.

Wasm programs can only crash by triggering a "trap", which has the well defined semantic of aborting the entire (wasm) function stack at that point. It depends on the embedding host how much backtrace or debugging support you get for this.

I'm not sure exactly what you mean with non-JIT platforms, As far as I know, most wasm hosts that generate native code just compile the entire wasm module at once, so its less like a JIT runtime and more like a regular compiler.

If you mean not compiling to native code at all, then you just have the performance of a plain old stack machine bytecode interpreter. Not sure how many there are currently and how well optimized they are though.

About big-endian - afaik little-endian is just the spec for storing to wasm's linear memory - the actual representation of stack values can be arbitrary (since you can not inspect their bytes directly).

I think they just meant that Rust references are like normal first-class generic types. Eg, you can nest them to get a &mut &T for example, since they behave more like a pointer in that regard.

C++ references on the other hand are more like modificators of a type, eg you can have a T or a T&, but having a (T&)& does not make sense. (Outside of templates, where it gets folded down to a T&.)

Rusts references behave like plain raw C/C++ pointers at runtime, without any bookkeeping code running at all.

The magic all lies in the compiletime borrow checker, which roughly works like this:

    - All data is accessed either through something on the stack or in static memory.
    - Accessing data, say by creating a reference to it, 
      causes the compiler to "borrow" the value for the scope in which the reference
      is alive.
    - The references can be alive for any scope equal or smaller than for which    
      access to the data itself is valid.
    - References track the original scope for which they are alive around as a 
      template-paramter-like thing called "lifetime parameter".
      Note that Rusts use of the word "lifetime" is thus a bit narrower than the
      one used in C++, since it just talks about stack scopes, and not the lifetime 
      of the actual value as would be tracked by a GC or ref counting.
      Example:

      let x = true;
      let r = &x;

      Here, r would infer to a type like `Reference<ScopeOfXVariable, bool>`.
      (The actual type in rust would be a `&'a T` with 
      'a = scope of x, and T = bool).
    - Because the scope is tracked as part of the reference type,
      it is possible to copy/move/transform/wrap references safely, since
      the compiler will always "know" about the original scope and thus can
      check that you never end up in a situation where you accidentally outlive the 
      thing you borrowed, say if you try to return a type that contains a reference 
      somewhere deep down.
    - The borrow itself acts as a compiletime read/write lock on the thing you referenced,
      so for the scope that the reference is alive for the compiler prevents
      you from changing or destroying the referenced thing. Example:

      // This errors:
      let mut a = 5;
      let b = &a;
      a = 10; // ERROR: a is borrowed
      println!("{}", *b);

      // This is fine:
      let mut c = 100;
      { 
          let d = &c;
          println!("{}", *d);
      }
      c = 50;

    - The above examples just use `&` for references, but Rust has two references types:
      - &'a T, called "shared reference", which cause "shared borrows".
      - &'a mut T, called "mutable references", which cause "mutable borrows".
    - Both behave the same in principle, but have different restrictions and guarantees:
      - A mutable borrow is exclusive, meaning no other other borrow to the same data 
        is allowed while the &mut T is alive, but allows you to freely change the T through 
        the reference.
      - A shared borrow may alias, so you can have multiple &T pointing
        to the same data at the same time, but you are not allowed to freely change T through 
        the reference.
      - (If those two cases are too rigid there is also a escape hatch that
        a specific type may opt-into to allow mutation of itself through a shared reference, with 
        exclusivity checked through some other mechanism like runtime borrow counting.)
    - Through these two reference types, Rust libraries can abstract with arbitrary APIs
      without loosing the borrow checker guarantees. Eg, the "reference to vector element"
      example boils down as this:

      let mut v = Vec::new();
      v.push(1);
      let r = &v[0]; // the reference in r now has a shared borrow on v.
      v.push(2);     // push tries to create a mutable borrow of v, which conflicts with the 
                        borrow kept alive by r, so you get a borrow error at compiletime.
      println!("{}", *r);

I don't have concrete examples, but in general:

For one, the build system/dependency system is much more easier to handle. Rust uses the cargo package manager, and depending on an external library is as simple as adding a single line to the Cargo.toml config file. Likewise, building, running, documenting and testing is all a build-in matter of calling `cargo [build|run|doc|test]`, which makes prototyping and getting started way easier than my experiences with C++ so far.

As far as the actual language goes it basically behaves like C++ and has a similar feature set, so you get the same sense of how given source code will end up in the compiled binary, and can write fast efficient code with, for example, features like pointers. The big distinction there is that Rust is memory safe per default, (including pointers in form of safe references) and upholds this invariant with compiletime checks and explicit language barriers (needing to encapsulate "unsafe" operations in unsafe {} blocks), so per default you are protected from whole classes of bugs that are possible in C++, like dangling pointers, memory races, iterator invalidation, etc.

Hi, me and a few others in the Rust community kinda hashed out an plan of how you would do safe code un- and reloading Rust. Its nothing official, and has no implementation or official RFC/proposal yet, but the idea goes something like this:

- Rust as-is assumes program code/static memory is always valid/has the 'static lifetime. This assumption is implicit in the sense of function pointers, trait object vtables, static variables etc all having no lifetime bounds on something else than 'static, which means unloading their backing memory would cause unsafety.

- Thus, in order to make safe code unloading safe there would have to be a new, optional compile mode in which the compiler would treat "static" things like function pointers, trait objects, statics etc as non-'static, eg by giving them the new concrete lifetime "'crate". So if you have a "static FOO: T;" in a unloadable crate, you could only get a "&'crate T" to it, and you could only coerce to trait objects with a "+ 'crate" lifetime bound.

- 'crate would be similar to 'static in that it represents memory valid for the lifetime of the crate, but unlike 'static would not imply being always valid, and as such the borrow checker would prevent a bunch of operations for it like subtyping with any other lifetime, or usage with API's that want 'static bounds like thread spawning.

- Because 'crate is distinct from 'static, mixing unloadable and loadable code would be safe since the regular lifetime checking would ensure correct interaction between both. It means unloadable crates need to be explicitly written as such though.

- There are some major complications with generics and other compiler-generated glue code like vtables that are not fully hashed out yet: The issue there is that machine code corresponding to an upstream dependency gets compiled into the binary of the current crate, which means you would have code that typechecked with the assumptions of living in one binary be generated in another. Solutions here include banning generics and trait objects to types from extern crates, re-checking generics at instantiation location similar to C++ templates, or adding a new feature for instantiating generics outside the current crate, similar to "extern template" in C++.

The multi threaded architecture of servo is actually more energy friendly than existing engines for the same workloads, since distributing the same amount of work over more cores means that each core has to do less, and can thus run at lower clock speeds and thus drains less current.

Note that I'm not really familiar enough with versioned symbols to know whether there is much more to it than just a specially formatted name.

The default name mangling of Rust library symbols is already kinda versioned because it includes a hash of the library, so two different versions of a library can coexist at the same time.

As far explicitly using the symbol versioning scheme you mentioned, you can do it with an attribute today:

https://play.rust-lang.org/?gist=92be155702d53c6411b2&versio...

(Disclaimer: I haven't actually compiled this as a dynamic library and checked, but its what that attribute is for, and the names seem to be used verbatim in the ASM output)

That's not a list of Show, that's a list of a single type that instantiates Show.

The difference being that in your code you can only put in a single type at a time, eg [Int] or [String], but not both Int and String under the common Show interface type.

Well, the first two are really just the same thing :P

Yes, though this particular code would not compile because one of the lifetimes is not declared.

Rust actually has two different reference counted smart pointers: `Rc`, which uses non-threadsafe reference counting, and hence is not sendable across thread boundaries; and `Arc`, which uses atomic reference counting and can be send across thread boundaries.

You can definitely create leaking cycles with both though, but Rc and Arc also support Weak pointers to safely break up cyclic ownership trees.