frankmcsherry

HN wants me to stop posting, so this will be the last one. You two know how to find me elsewhere.

What I should have written is: "you will not fall victim to memory unsafety unless there is a bug in the language or in the standard library, or you explicitly opt out of safety". Using `unsafe` in C# is opting out of its safety guarantees (and requires the `/unsafe` flag); I'm pretty sure none of the C# team would say "guaranteed memory safety" of unsafe C#. I expect the same is true of Java, and have no clue about Python.

To the extent that we are talking about unsafe C#, I think you are right; it's mostly the same as Rust. But, no one would claim that unsafe C# has "guaranteed memory safety" where the guarantee is "as long as your code and all the code you bring in don't have memory safety bugs". At least, I hope not.

My original point was just meant to be that there is the risk of harm when you try and quantify a language as "more safe" because there are fewer regions where unsafe operations are permitted. People might read "guaranteed memory safety" and misunderstand what it means, as evidenced by me not actually knowing what it means.

I really don't have a position on C++; I don't use it, and don't really want to make supportive or limiting statements.

I have used other memory safe languages, and I find their guarantees qualitatively different from Rust. I would say of them "you will not fall victim to memory unsafety unless there is a bug in the language or in the standard library" with no mention of other dependencies. The standard library is then fairly thoroughly audited.

By comparison, you have e.g. the `memmap` crate, which I like and use, written by serious people known to you, where `unsafe` is used in construction of the memory map. It is then on the user to ensure that there are no concurrent writes to the backing file for the lifetime of the map, at the risk of (as I understand it) UB. Would you describe such a program as "safe"? Or at least, can you understand why I might not? If a concurrent modification happens, is the bug to be found in the `unsafe { MmapMut::map_mut(&file)? }` block, or perhaps farther away where you safely open and modify the file before dropping the map?

I'm sorry if this comes off as quibbling; I do actually care about getting these things right, as I want to rely on them and do more interesting things (e.g. de-abomonate mapped memory).

I would say that Rust has a different memory safety story from say C#, which distinguishes between "is safe" and "contains unsafe code outside the CLR itself". I find that very-binary distinction more helpful than Rust's memory safety story.

I don't use C++ anymore, but I am not clear on how Rust has better memory safety guarantees than C++. I do like its story more, for sure, and I could see how they might turn in to guarantees (but I could also believe that someone could identify a similarly safe fragment of modern C++, and don't want to start that).

Edit: will rust-lang.org take a PR changing "guaranteed memory safety" to "memory safety story"? ;)

I don't think you are correct, unless the language has changed substantially.

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

Among other things, you need to opt in to unsafe with the `/unsafe` compiler flag. I'm pretty much 100% certain that the `unsafe` keyword applied to scopes does not mean "treat the contained scope as if it were safe, but permit the use of unsafe operators" which is how it works in Rust.

Edit: to put some more words here, I think what you may be saying is "the unsafe fragment of C# behaves like Rust", which sounds sane to me: `unsafe` decorates regions and the compiler will complain at you if you use unsafe things outside such scopes. When I said "C#" I meant the larger language in which programs are either "safe" (verifiable) or not, and for which `unsafe { .. }` forces you into the unsafe fragment.

Rust doesn't have safe and unsafe language fragments; there is one language which follows rules similar to (as you say) unsafe C#, but which advertises itself as safe. In that language, `unsafe` moves you back in to "safe" code (or we could agree that it was never safe in the same sense that languages like C# are).

C#

> Basically, I find the "there's always unsafe code somewhere at the bottom and therefore it's the same as 100% unsafe" to be overly reductive.

I totally agree; it's not the same. However, I think there is disagreement about whether saying only "there's always unsafe code somewhere at the bottom" is better or worse than saying "it's 100% unsafe".

I tend to write some sketchy unsafe code, and the only thing I can say with a straight face is "please don't use this if you care about safety", i.e. treat it as if "it's 100% unsafe". I'm slightly weirded out that Rust has a keyword that amounts to "I understand UB really well; tell others to trust me on it transitively".

I'll be less weirded out when the UB story gets shaken out more, or if cargo gets an "audit-unsafe" option that shows you all unsafe blocks you transitively depend on (does that exist yet?). Still like Rust, but letting randoms write unsafe code is scary.

In many other languages `unsafe` taints the block of code it is in, which propagates upwards. Rust is the other way around, where `unsafe` means "I'm doing something unsafe here, but let's not tell anyone who doesn't look". It can be a lot harder in Rust (than other languages I've used) to know whose code you have to trust: language implementors (probably ok) or random crates (urk).

There is a surf spot in Morocco (Killers) named for the Orcas spotted there. They apparently show up periodically. Water is plenty warm.

I've been using it in Rust, but librdkafka had (has?) a bug that's been fixed in tree that cut the read throughput to about 10MB/s using loopback (edit: cuts throughput to 10MB/s in many settings, which hurts especially in loopback). With that fixed, it seemed pretty pleasant for my use cases (framed bytestreams at line rates, nothing fancy or web-scale).

Edit: crate I was using, and enjoy (which brings in librdkafka): https://github.com/fede1024/rust-rdkafka

> Wired recently deployed a team of experts to deconstruct Apple’s code and found its differential privacy practices to be lacking, a characterization that the company strongly disputes.

If by "deployed" they mean "interviewed about their work". I don't understand Time crediting Wired with the research[0], which does a disservice to their actual sources of funding.

https://arxiv.org/abs/1709.02753

> Is there anything I am missing?

Like, lots, I think.

I don't own property in Switzerland, but you write as if property transactions are in cash up-front. Instead, you put some money down (why the GP mentioned leverage), and the amount you don't make back by investing in stocks is this opportunity cost. The amount saved in rent is also subject to compound interest; unless you are worried that this person is a serial home purchaser those savings will be invested in the market.

I'm sure you can come up with more details and that the market probably wins, but you asked what you were missing.

My understanding of the field-reordering work is that it applies to tuples. From http://camlorn.net/posts/April%202017/rust-struct-field-reor...:

> The 2000-foot version: Rust structs, enums, and tuples are now automatically smaller in some cases. It's possible for the compiler to work with types whose in-memory field order doesn't match that of your source code.

This would mean (again, as I understand it) that you cannot rely on the order of elements in a tuple, if for example you wanted to pass a `&[(T1,T2)]` to some other code (even other Rust code, but built separately).

Edit: serious follow up: You've been working with Servo, and I'm assuming at various moments you (pl) need to map in shared libraries that Servo wasn't built with (e.g. codecs, whatever). Do you avoid Rust types in these FFI interfaces, do you rewrap everything, or have pervasive repr(C) type analogues instead?

It might be that I'm the only person in the world trying to do Rust-to-Rust FFI, but it feels like (i) it isn't that far from being really tasteful, but (ii) it has a bunch of issues that make it seem that no one has ever tested it (e.g. default allocators being different, weak guarantees about layout).

I've had a bunch of issues getting clean statements about the ABI that actually result in usable guarantees.

For example, while you are advised to put `#[repr(C)]` on types you want to have a known layout for FFI, to the best of my understanding this decoration isn't included for generic types like tuples, slices, or `Vec`. Afaiu, Rust reserves the right to change the layout of `(T1, T2)` for `#[repr(C)]` types `T1` and `T2` on a build-by-build basis, which makes a lot of the core types unsuitable for FFI.

Anyhow, that's my issue with it as a "systems" language. I can't (yet) write code that compiles down to the minimal operations I believe the computer can do, without re-inventing a non-trivial hunk of the standard library. Or, if I can, I can't find the language in the spec that ensures I won't have to fix things.

Some minor pedantry that winds me up a bit, and that I thought I'd try to correct:

> Note that one of the co-authors of this paper, Amit, is the author of https://www.tockos.org/

The definite article "the" precludes the existence of other authors, who (from personal experience) can get wound up by language like this.

You may have meant "author of the web site", in which case I have no opinion, but if you meant "author of the project" I'd totally use the indefinite article "an".

Also all of the work is very interesting and people should read it.

> What bothered me about your comment was that it sounded a bit like "wow, I found that RDBMSes suck at this specific type of computation that they're not built to deal with, therefore query optimizers suck in general", which seemed like an over-reaching argument.

Gotcha. Yes, it was more "I have some things I need to do, and RDBMSes can't do some of those things, which rules them out as a solution". There is for sure lots of great stuff in query optimization, and it makes some queries lots better.

> I guess what I took away from his claim was that the contribution of MR itself was not the problem, but the fact that while creating that model, they ignored a lot of other learnings: e.g. blocking operators can be detrimental, indexes are handy to have. Plus the fact that everyone /else/ who didn't have Google's reasons to forego all those niceties still dove head-first into "let's use MR for everything".

They did not ignore them, they just weren't building a database. MR was much more a scalable HPC replacement than a data management product.

The main reason that the DB community took a huge step backwards is that they (incl Stonebraker) had doubled-down on mediocre compute abstractions, and found they needed to revisit much of what they'd done, because it just didn't work.

> Ah, for me the main question and discussion above was "are RDBMS techniques even relevant at this point", to which my answer is yes, absolutely. That doesn't mean you have to take every concept from it wholesale: many techniques that developed in one context are applicable in others, regardless of Stonebraker's opinions.

I totally agree with you that they are relevant (and am active in the area). Stonebraker takes a much stronger position, and the appeal to his authority was what triggered me. I didn't mean to point that at you as much as it may have turned out.

Stonebraker has done a lot of fine work, but also has a lot of false negatives; he got down on recursive queries, on data-parallel compute, and generally most other things that he's not directly working on. It ends up with an in-crowd of folks who think he is great, and an out-crowd of folks frustrated by his constant unfounded dumping.

I've personally found it is hard to take him seriously when he says a thing, and you should first check which company he is currently flogging. Doesn't mean he is wrong, .. but check.

> Indeed, when I look at the emptyheaded paper for example, I see SIMD parallelism, query compilation join optimization, all stuff that was first developed in the context of RDBMSes.

The main contribution of EH is not the use of SIMD, it is the implementation of new WCO join execution strategies that hadn't been developed in the past 40 years of RDBMSes.

If you wanted that behavior, with its orders-of-magnitude performance improvements, you could not get it from an existing optimizing RDBMS---not HyPer, nor MonetDB, nor anything else in your list---but you could get it from a more programmable data-parallel system.

> Well, if computation's all you need ...

It is a thing I need, which is exactly the point. If the RDBMSes don't provide the performance (or anything within 100x) you can get from a more programmable system, you need a different solution.

Stonebraker's claim was that MR was a huge step backwards, which is BS to the extent that RDBMSes weren't solving the problems Google (and others) had. No amount of fantasy query optimization was going to take SQL to the performance of MR or MPI codes (even circa 2009, Vertica still had no support for UDFs).

You are of course welcome to list other things that RDBMSes are good at, and that's great. However, Stonebraker's claim isn't that RDBMSes have some value (which everyone I know agrees with), his claim is that MR was a shit model and everyone should be using RDBMSes instead (preferably his).

> If you're saying RDBMSes are bad at graph computations, then sure. That's unsurprising. But that's not what we were talking about! :-/

Remind me what that was, then? It seemed like we were talking about whether there was a heavy pro-RDBMS bias in the redbook, which I think is (i) fair, and (ii) fine. I also think Stonebraker is wrong in his claim that MR set things backwards because (as I referenced) RDBMSes weren't there to be set back from. If anything, it prompted a great deal of new work that led to improvements in areas he was blind to. A concrete example of this (e.g. iterative computation) seems totally on-topic.

It's a stream processing language:

http://hirzels.com/martin/papers/spe16-river.pdf

For further reading about the high quality of database query optimization, and how far back MR et al must have set things, recent SIGMOD work managed to get to within 1000x of a single-threaded implementation (and so, not quite within that of data-parallel systems):

https://github.com/frankmcsherry/blog/blob/master/posts/2017...

I don't use databases because they are really quite bad at computation.

In my opinion, the main recent novelty in query planning has been the work on worst-case optimal joins, stuff like EmptyHeaded[1] and the recent FAQ work[2].

[1]: https://arxiv.org/abs/1503.02368

[2]: https://arxiv.org/abs/1504.04044

This probably runs afoul of your "at least not in a satisfying way" constraint, but:

It is pretty easy (an exercise) to implement the "opposite of a Bloom filter" if you start from a summary of the complete set of events and support deletion, rather than starting from the empty set and supporting addition.

What makes everything seem hard is the (often unstated) requirement that you start from an empty set and support addition, which is roughly as hard as implementing a Bloom filter that starts from the complete set and supports deletion. Neither of the links make this requirement explicit (though, it is implicit in their "motivation" sections).

I am a bit torn with this, because while I love people reading and then writing up things, there are so many changes I think they should make but I don't want to just barge in and make pull requests.

E.g., they largely miss DryadLINQ (disclosure: not an author, but worked with them), which I would rate as the second most important paper after MapReduce in the "batch compute" space. It shows up only as what you should use to write Dryad programs, because Dryad's programming model "is less elegant than MapReduce"; harsh.

The streaming section (disclosure: Naiad co-author) dances around and then suggests that Google Dataflow is somehow a unification of previous work, which is .. well, you can read the Google Dataflow paper

    http://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf

and do a search for "Naiad"; it's not even on their radar.

It feels a bit like the critiques are perhaps too-credulous readings of the related work sections of other papers.

I'm not sure a great way to get to a consensus understanding of the position of the works in the historical record, or whether it is even possible with sensitive authors (hi), but it would be cool to have. Any recommendations would be great.

I suspect affine is fine, but I'm not an authority. The distinction (as I understand it) is only that linear types require that you consume all instances, whereas affine allow you to leak if you want. Leaking doesn't seem to lead to dangling pointers, but I've been wrong before.

Ownership / affine types?

It's hard to say, because some folks will jump up and down and say "reference counting is GC!", and then some folks could just as justifiably say "regions are GC!"

As they describe in the paper, if you want that behavior you can get it, but it comes at a cost. If you would like the softer guarantees (could be exception or not, but never invalid data), you can get better performance.

What they describe is a knob that lets you trade off static assurance against dynamic assurance, for performance. If you have good static tools (e.g. something like Rust's borrow checker, or various C++ tools I know nothing about) you can confidently not care one way or the other and take the performance.

!#$!@# I was going to go try that out. ;) When doing the Chaos/Order stuff, the decompression was about half the CPU cycles, so thinning that could help.

Fwiw, the encoding I used wasn't VByte; because I was doing strict increments, I knew `0` wasn't a valid value to see, and used it to encode variable byte lengths (number of zeros: number of valid data bytes). Not smart, but easy to hack up, and gave me back 128-255 in one byte. I'm curious to check this out, now!

When I was grinding away on the 128B edge graph on my laptop, literally 85% of the time was parsing integers. Get your data to native binary as soon as you can (edit: or out of plain text at least, per parent).

This example isn't about branch prediction (not exactly), but it might still be interesting:

https://github.com/frankmcsherry/blog/blob/master/posts/2015...

It's about how sorting + random access can be faster than random access, because you introduce locality of reference. And in this case, it absolutely is faster to sort the data first and then do the work, even counting the sorting.

Edit: Aw crap, adrianN beat me to this a few screenfuls down, sorry! But, it is a different post, so maybe this is still helpful. :D

I think that is the ethical thing to do, yes.

Differential privacy does statistically disclose information about you, and whether the quantitative bound used is up to your standards is a decision you should make before it happens. Given that user-level understanding of DP is so low, I don't think defaulting people in to levels chosen by others is a good idea. I 100% guarantee Mozilla doesn't have the background to make this choice responsibly, and doesn't have near the DP expertise the RAPPOR team has / had (who I also wouldn't trust to chose things for me).

Ideally, the use of differential privacy would make you more willing to opt in (when you have a choice) rather than being a smokescreen for organizations that simply want to harvest more data (which was Mozilla's stated motivation).

Edit: fwiw, there are some cool "recent" versions of differential privacy that let the users control the amount of privacy loss on a user-by-user basis. So, you could start at 0 and dial it up as you feel more comfortable with the tech. This incentivizes organizations to be more transparent with what they do, as it (in principle) increases turnout.

Edit2: For context, Apple's "default" values appear to be (from this paper) epsilon = 16 * days. That means that each day you are active, the posterior probability someone has about any fact about you can increase by a factor of exp(16) ~= 88 million. So, numbers matter and I am (i) glad Apple made it opt-in, (ii) super disappointed they aren't at all transparent about how it works, and (iii) thankful that the paper authors are doing this work.

Yes, I think you've misunderstood.

The text you've quoted is about how a random subset of the population is already immune to the issue of repeated queries, not that subsampling the population helps in any way. If you don't interrupt the quotation mid-sentence, it reads:

> Even so, some randomly-chosen users need not fear such attacks at all: with probability (1/2 f)^h, clients will generate a Permanent randomized response B with all 0s at the positions of set Bloom filter bits. Since these clients are not contributing any useful information to the collection process, targeting them individually by an attacker is counter-productive.

The whole of section 6.1 is not about how it only protects a single question, it is about how one ensures that the single-question protections generalize to larger surveys, concluding that

> This issue, however, can be mostly handled with careful collection design.

I think the big difference there is that Mozilla was proposing opt-out differentially private data collection, whereas I believe Apple has historically been opt-in (with the default being no data collection).