arielby

`Animal::talk(self)` is shorthand for `<Self as Animal>::talk(self)` - i.e. it calls the overridden method. If you want to reuse the supertrait method, you have to implement it as a generic method outside of the trait, and call it from the default implementation:

    pub fn super_talk<T:Animal>(this: &T) {
        println!("{} says {}", this.name(), this.noise());
    }
    trait Animal {
        //...
        fn talk(&self) {
          super_talk(self)
        }
    }

This is Rust's approach to splitting a crate between files - not for splitting to different isolated separately-compiled modules. I must say it works great for that purpose, being much better than dealing with build tools.

Things that don't need any synchronization or interesting state can of course easily go into microservices. This does not mean that application state should be stored in a concurrent model unless you have to.

C's automatic conversions are more problematic than signed overflow itself.

I don't know of any way to compile non-array-ish, non-explicitly-SIMD-ish code into efficient SIMD code. Thinking about it, this seems to be the general case with parallelism - you can take fairly naïvely-written code, maybe add some memoization and hash-table-dictionaries, and it turns into not-too-inefficient sequential code, but I don't know of a way to do an equivalent with parallel code (especially if you add the memoization) - STM promises, but (AFAIK) still doesn't deliver.

Of course, the best way to have an SoA representation is to use an ECS :-).

C's main claim to fame is being "an HLL" (in the classical sense) but still being able to do essentially everything Assembly does. Also, having relatively-simple semantics surely helps (C is the only imperative language to have completely formalized semantics that I know of).

@qznc: I don't know of a way to do it natively in Rust (you must write accessors).

Rust doesn't allow this direct use-case. You can have conditionally-successful initialization by returning an `Option` or `Result`, however.

C matches NUMA and caching just as well as assembly does. Basically the only thing C doesn't really expose is SIMD, but compiling "high-level" (i.e. C-level or above) code into SIMD is an open research problem (AFAIK) - I mean, you can easily compile array programs into SIMD, but the more general case is still open.

SafeStack is essentially an IA-64/SPARC-style two-stack model - there are no pointers to the %rsp stack.

That's what SafeStack (and IA-64) do.

IA-64 had this since it was created - nice to see it coming to x86.

That's just a vanilla "divergence" stack overflow - an essentially harmless consequence of the type-system's Turing-completeness.

Most crashes are in type inference, associated types handling, and error recovery, which are very complicated things, especially in combination. We also basically rushed features in for 1.0.0 (1.1/1.2 should be much better in terms of these).

Most things that have lots of reverse-dependencies require a significant amount of maintenance. Compilers are not much different from "common" libraries, or special-purpose frameworks, in that respect. Also, writing a direct-to-assembly compiler is probably not a wise idea.

1.2 is much less ICE-ey than 1.0 (the annoying "capacity overflow" macro ICE is no longer an ICE - it still prints "internal compiler error: unprintable span" but doesn't crash).

1.2 (which was stabilized today) is also a mostly-quality release (`const fn` and associated constants landed behind a feature gate, but are still not-really-done).

No it doesn't.

The leakapocalypse is rather blown-up - I don't think you could observe it unintentionally. Besides, `thread::scoped` is something no other mainstream-imperative language tries to offer - parallelism with essentially no risk of race conditions.

That's why you mock the IO - to make the IO call return an error.

Its a whitelist. It is "verify the string is a 24-character alphanumeric string".

Isn't this exponential precision = polynomial time?

bytes.upper is the Right Thing when you are dealing with ASCII-based formats. It also has the advantage of breaking in less random ways than unicode.upper.

And I mean, I can't really think of any cross-locale requirements fulfilled by unicode.upper (maybe case-insensitive matching, but then you also want to do lots of other filtering).

Also:

For each key you use, pick 1 format of messages for it to authenticate. Document that format. Version-control that documentation along with the code that uses it. If the format changes in a non-back-compat way, pick a new key (so try to use a backwards-compatible format). Ensure the documented messages make sense (try not to have a "fire this person" message without knowing who is that person) - timestamps and/or nonces can really help here.

If you can't pick just 1 format, you can say have the first 16 bytes of the message be a UUID, and document each UUID-format (with the same documentation rules as if you are not using a UUID).

Seriously, that and "don't mix secret and unauthenticated things" together covers 90% of all vulnerabilities.

Unfortunately that interface is rather dangerous because of the 64-bit nonces - it is essentially only useful for encrypting multiple messages over a single connection.

The C standard guarantees Pointer to Struct ~ Pointer to (transitively)-initial Member (through casts, either directly or via `void*` or via `intptr_t`). It doesn't guarantee Pointer to Struct + offset ~ Pointer to non-initial Member for any value of offset.

> why Linux uses offsetof

Essentially, downcasting with "multiple inheritance" (non-linear subtyping) and thin pointers - objects can be members of several intrusive linked lists, held by different parts of the kernel, and container_of is used to get an object from the LL pointer after you know the type.

> The world currently consumes 20 trillion kWh of energy annually.

> Enough energy to power a single family home for 1.8 billion years or supply energy to a nuclear power plant for 2,300 years.

That's, ..., not the way I would have written it.

C/C++ don't have much of a runtime too (libc's "runtime" component is often not used, and libstdc++'s is rather controversial). Standard Haskell functions (with types like `a -> b`) are pure, unlike (most) other mainstream-ish languages. Of course you can do IO, which of course is impure, but it is cleanly separated from non-IO.

This is the standard style of programming in functional programming languages. While it isn't object-oriented (being its dual), I don't see why is it so bad (I wouldn't like a single `Vehicle` class to have methods handling lane use in each state).

Rust is new here, but it often does its dependency injection on the type-level (see the *_traits crates in servo, or anything involving piston - `https://github.com/piston-developers`).

However, Rust doesn't have an OOP or Unit Test culture, so dependency injection is limited to true dependencies.

Except that an interface's signature is more complicated than a single function.