dbaupp

90 ms·

931.
by dbaupp 11y ago
Implementations will do that, e.g. https://github.com/rust-lang/rfcs/pull/1513 .
932.
by dbaupp 11y ago
Even supposing that Rust and C++ have the same level of complexity, the style and consequences of their complexity are wildly different. A lot of the various pieces of complexity of C++ needs to be held in the head of a human who is writing
933.
by dbaupp 11y ago
> Each object gets to define its own control structure syntax. This is true in every language: types get to define their API, and languages with first-class functions (or something similar) get to define things that act like a control
934.
by dbaupp 11y ago
> In a strict language, a lazy thunk can be represented as a single mutable cell. In ML, thanks to type abstraction, the mutation is confined to the module that implements laziness, and, in the rest of the program, there's no way t
935.
by dbaupp 11y ago
I suspect the author was talking about defining methods for individual variants of an enum, something like enum Foo { A, B } impl Foo::A { fn method_on_a(&self) {} }
936.
by dbaupp 11y ago
A C header is not needed at runtime, it is purely a way to easily describe the symbols in a library that exist in a (somewhat) type-safe way. It's the lingua franca for describing libraries, and tooling (such as Rust's bindgen, or
937.
by dbaupp 11y ago
I believe they're equally expressive, but the existing trait approach has a different run-time/memory profile. The issue linked in the parent comment has some info/links, and, http://smallcultfollowing.com/bab
938.
by dbaupp 11y ago
> Personally, I've always thought that type safety provides the most benefit at boundaries between codebases: you have people composing pieces that they don't understand, and the types serve to guide how those pieces can be co
939.
by dbaupp 11y ago
I was more focusing on implementing the internals of mmap, since that's what I assumed the question was. For that task, the actual memory/pointer returned is essentially a black-box (i.e. it's never read nor written by mmap i
940.
by dbaupp 11y ago
You've hamstring the type system at the interface , internally you still get all the benefits. In any case, a typical use-case for a shared library like this is embedded into other applications, which may not be written in Rust at all
941.
by dbaupp 11y ago
> How would mmap be any different if it was implemented in Rust rather than in C? You need unsafe to implement it! The safety mechanisms are practically useless at such a low level. They're definitely not. The power of Rust is not
942.
by dbaupp 11y ago
> No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others. It's not; as soon as code uses (for instance) references, you're running the memory-unsafety ga
943.
by dbaupp 11y ago
Rust code exposing a C ABI (e.g. as a slot-in replacement for an existing C library) behaves like any other upgradable shared library.
944.
by dbaupp 11y ago
Only `proc` closures were boxed , `|...| -> ...` closures were pointers into the stack. However, it is true that all closures were type erased, and were hence equivalent to certain trait object types (`Box<FnOnce(...) -> ...>`
945.
by dbaupp 11y ago
Rust's lambdas are structs containing (references to) exactly the data from the parent scope that their bodies refer to, no more, no less. It's fine for that set to be empty, resulting in an empty, zero-sized value. As we discusse
946.
by dbaupp 11y ago
Yeah, it should be able to handle that easily, since both bits and scores have static length 7. Note, however, that the loop version does no more or less [] indexing than the iterator/fold version.
947.
by dbaupp 11y ago
> Hopefully the setup of closures that probably won't be executed isnt't too expensive. Do those require a heap allocation and release when not used, or is this all on the stack? Creating a closure with |...| { ... } is liter
948.
by dbaupp 11y ago
> Not importing the entire library will result in faster compilation. Unless rust has a concept similar to precompiled headers, etc. I apologize at this point. I'm not sure what Rust does in that respect, but my initial thoughts we
949.
by dbaupp 11y ago
As we discussed on IRC, "data race freedom" is equivalent to guaranteeing memory safety, and so, in a kind-of pedantic way, data race freedom is the core guarantee. That said, the original comment would've been better phrased
950.
by dbaupp 11y ago
> The Andrei guy says that Rust places too much emphasis on "clerical" memory management. This is not like a person who learned PHP from a couple w3schools article deciding that Lisp is "weird". The criticism is not
951.
by dbaupp 11y ago
I strongly disagree: the goal with Rust is to offer safe, low-level programming, not to be a test-bed (or whatever) for some programming paradigm. The "discipline" is just a tool to reach the goal. You can see this in the evolutio
952.
by dbaupp 11y ago
I wrote a comment a while ago that has some code examples: https://github.com/rust-lang/rfcs/pull/243#issuecomment-8220... (and the following two comments)
953.
by dbaupp 11y ago
You might be thinking of different start-ups, but I was under the impression that start-ups are using Rust not because they want to learn system programming, but because they need the low-level control but aren't confident using C++ an
954.
by dbaupp 11y ago
Rust's memory management strategy has been described before as "you have to think about it, but you don't have to worry about it", which I think applies to the language more broadly in terms of a comparison vs. C++. Th
955.
by dbaupp 11y ago
Yeah, the Cargo.lock file means that * constraints aren't a problem until you need to update a library, e.g. to get an emergency bug fix. And, you are right that cargo update's --precise option allows manually getting the same ben
956.
by dbaupp 11y ago
(Life will be easier for you in future if you avoid * constraints, by using things like `router = "0.1"` instead. This means authors can make breaking changes to their crates without breaking you, e.g. router might make a major ch
957.
Yet another blog post about how parallelism is not concurrency(composition.al)
38 points by dbaupp 11y ago|7 comments
958.
by dbaupp 11y ago
> 1) After some soul searching, it seems like the really important invariant to me is that all alive objects should be reachable from the stack(s) at any given moment. So I'm kind of okay with failing to run destructors due to dead
959.
by dbaupp 11y ago
Concurrency/parallelism is sometimes described as "abstraction piercing", i.e. you can't tell if something is safe for use in a concurrent code by just looking at its interface, the internals of the type and the implemen
960.
by dbaupp 11y ago
The grandparent was looking for concrete evidence/examples for the "high performance" label, not just another assertion of high performance.

More ›