dbaupp

102 ms·

871.
by dbaupp 10y ago
A "zero-cost abstraction" really means that abstraction doesn't impose a cost over the optimal implementation of the task it is abstracting. Some things—like chaining a dynamic number of (arbitrary) closures—fundamentally req
872.
by dbaupp 10y ago
I'm not sure variance is at all related to this particular feature (maybe you could expand on your thinking?), but I also don't think the classical inheritance techniques for solving this problem are appropriate. I assume you&#x27
873.
by dbaupp 10y ago
I'm... curious about why you think LLVM isn't used to the sort of code that results from these sort of zero-cost abstractions: C++ code is also very aggressive about templates that inline away to nothing, and modern C++ especially
874.
by dbaupp 10y ago
It's an error if that would be unsafe, or else it compiles fine: the future compiles down to an enum/struct that stores everything inline and it can be returned/move up the stack/stored in global memory the same way that
875.
by dbaupp 10y ago
Most of the build process is in Rust[0], but something needs to kick it off: instead of assuming/requiring that install the correct version of Rust (for the right platform) themselves and then invoke cargo in the right place to get the
876.
by dbaupp 10y ago
I wasn't giving examples of Mozilla doing exactly what Chrome is doing, just counterexamples to your implication that working on Rust means no work on improving memory management in Firefox. That said, it's not even like a single-
877.
by dbaupp 10y ago
Rust doesn't ignore field size nor does it align to any particular boundary. E.g. struct Foo { x: u8 } is one byte and has alignment 1, and similarly struct Bar { x: u8, y: i16 } is 4 bytes and has alignment 2. The compiler doesn'
878.
by dbaupp 10y ago
Mozilla has also put significant effort into improving their C++ GC in Firefox, e.g. switching from a non-generational one to a generation GC[0] and then to a compacting one[1]. Just like Google can both improve Chrome and work on Go, Mozil
879.
by dbaupp 10y ago
Java's collections don't (and can't, without high cost) make any guarantees that they will throw such an exception whenever they are modified concurrently... for one, data races can have weird consequences that aren't ea
880.
Inside the fastest font renderer in the world(medium.com)
3 points by dbaupp 10y ago|0 comments
881.
by dbaupp 10y ago
> The pocket calculator is doing a huge amount of computation to find those results, an amount which would be impractical for the human to do (hence the use of slide rules instead of laborious pen-and-paper arithmetic). It’s just a diff
882.
by dbaupp 10y ago
He didn't say he was "testing" with nightly: some experimental features only work on nightly (which, being experimental, the features may change in breaking ways, but that's why people have to opt-in to using a nightly)
883.
by dbaupp 10y ago
> Changing the size of int shouldn't be a breaking change in Go since pointer arithmetic isn't allowed and everyone should use fixed-size variables when you're relying on this behavior. Theoretically one should be usin
884.
by dbaupp 10y ago
Last time I installed Firefox (a month or two ago) it in fact did pop-up a button asking if you wanted to send telemetry back to Mozilla.
885.
by dbaupp 10y ago
> If data structures require unsafe operations, doesn't this make Rust's safety a 90/10 solution, and leave a small but credible threat of what are effectively buffer overflow attacks? Somewhat gibly, every solution is
886.
by dbaupp 10y ago
They're different types. isize is ssize_t (well, intptr_t), in that it is tied to the size of the address space, while C's int is not constrained. In fact, it is usually 32 bits, even on 64-bit architectures, where isize is 64 bit
887.
by dbaupp 10y ago
Hm, I'm interested to hear why you think 0.1.0 -> 0.1.1 being considered just as dangerous as 0.1.0 -> 0.2.0 is more useful than treating 0.1.0 -> 0.1.1 as "semver-safe" and having only 0.1.0 -> 0.2.0 be breaking.
888.
by dbaupp 10y ago
You may be interested in the discussion on this topic from when the survey was posted: https://www.reddit.com/r/rust/comments/4ikawg/launching_the_...
889.
by dbaupp 10y ago
To be clear, you're saying moving from 0.x.y to 0.(x+1).z is valid to be a breaking change, right? (For other readers, Rust/Cargo uses a---more useful---variant of SemVer where an upgrade from one version to another from assumed t
890.
by dbaupp 10y ago
I literally cannot share the source, I wish I could but the reality is my job does not let me. You're being unreasonable given how ridiculously simple the benchmarked section of the code is: it would not take long for even a Rust beg
891.
by dbaupp 10y ago
I'm really really sorry (I want to keep my job), but seriously, the code I benchmarked was a trivial reimplementation of your code. The get_max_cost_small2 function that is benchmarked is so small and simple that someone else doing it
892.
by dbaupp 10y ago
That comparison is misleading for exactly the reasons others have said: the algorithms differ, as can be easily seen in their very different data structures. A naive, line-by-line port of your fast variant to safe Rust (which I unfortunatel
893.
by dbaupp 10y ago
The interface will have to be `unsafe`, yes (that is, there are conditions that the code calling the functions must satisfy to avoid memory unsafety), but the internals can control this unsafety and avoid having more: libc's have vulne
894.
by dbaupp 10y ago
The C code is forced to use a function pointer and hence do dynamic virtual calls for each comparison, while Rust and C++ can use generics/templates to get static dispatch (and hence inlining, constant folding etc.). You can see C vs.
895.
by dbaupp 10y ago
> Really? I was able to call the intrinsic I sloppy patched into the auto generated files fine via extern platform. Err... yes, that is exactly my point. You needed an `extern` block to call the functions. It is much nicer if the `extern
896.
by dbaupp 10y ago
The JSON file exists because there's more than one place that needs to know about the intrinsics---they allow generating the corresponding `extern` blocks---and because there's classes of very similar functions that can be factore
897.
by dbaupp 10y ago
> Languages which bake in automatic bounds checking at every access rely on optimization to recover the performance hit. The performance hit is generally negligible, especially with abstractions like iterators in Rust that avoid them e
898.
by dbaupp 10y ago
> There's a reason languages like Rust and Go rely heavily on static linking and stack allocation This is untrue: Rust certainly does not do any optimisations linking statically by default, nor is there a difference between puttin
899.
by dbaupp 10y ago
I wrote something on the memory leak vs. memory unsafety confusion a while ago, for those interested in exploring it more: http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-...
900.
Memory Leaks Are Memory Safe(huonw.github.io)
2 points by dbaupp 10y ago|0 comments

More ›