centril

6 ms·

1.
by centril 7mo ago
xD Using the same module written in Rust, we can do even better on the same machine, 165k+ TPS.
2.
by centril 2y ago
Excited to see where this goes. It's just the beginning!
3.
by centril 6y ago
> I think they actually make a fair point because in this case "hard to do" probably equates to "makes the compiler a lot slower". They are wrong in this case. When considering whether to allow `foo<T>();` in Ru
4.
by centril 6y ago
Off the top of my head: Poor error messages, any type checking is run on the generated code so harder to enforce properties, and if code generation is not in-language, then the base logic can diverge for different types, which is bad when y
5.
by centril 7y ago
Thank you! I tried hard to make this blog post easy to read so it's nice that it feels that way. :)
6.
by centril 7y ago
An interesting example is the addition of `{-# LANGUAGE LinearTypes #-}` to GHC. The primary interest for this "experiment" is not from academia but from industry (tweag IO). Another example is `QuantifiedConstraints` which was qu
7.
by centril 7y ago
With faster builds, would probably reduce the queue latency and land more PRs. We'd probably also allow more toolchains to be tested and whatnot.
8.
by centril 7y ago
We aggressively use rollups to merge PRs into rust-lang/rust to mitigate the effect of the 4 hour build times. But it would sure be nice to bring it down to less. It would certainly make my life as the maintainer of the bors queue easi
9.
by centril 7y ago
https://github.com/rust-lang/rfcs/pull/2442
10.
Announcing Rust 1.35.0(blog.rust-lang.org)
246 points by centril 7y ago|105 comments
11.
by centril 7y ago
Note that in Rust, `.match` would itself provide the general way: let number = foo.bar().baz().match { it => it + 1 };
12.
by centril 7y ago
I think it's not a good idea to talk about them as one thing and the use cases also differ. `const fn`s are deterministic ("pure") functions that can be evaluated at compile time if all arguments provided also can. `const A
13.
by centril 8y ago
I don't think the Go 2 generics proposal amount to type classes; From what I inferred from the proposal, contracts are structurally typed rather than nominally such that you don't have a location at which you explicitly denote tha