withoutboats3

30 ms·

1.
by withoutboats3 3mo ago
> I don't remember the details with encryption but it was basically you have to ship a breakable version for the rest of the world, and you generally sometimes ship a backdoored version. I do remember the details: the result of Bern
2.
by withoutboats3 3mo ago
Your anti-semitism is vile and you should be shunned by any upstanding person in society.
3.
by withoutboats3 6mo ago
This is indeed a great quote (one of many gems from Sir Tony) but I think the context that follows it is also an essential insight: > The first method is far more difficult. It demands the same skill, devotion, insight, and even inspirat
4.
by withoutboats3 7mo ago
We can tell you think that when we use your app.
5.
by withoutboats3 8mo ago
Cuckoo filters outperform bloom filters and allow dynamic insertion and deletion (unlike bloom filters, which only allow insertion). The trade off is that insertion can fail if the table is too full and then would need to expand or store th
6.
by withoutboats3 10mo ago
The problem in this conversation is that you are equivocating between "fixing memory safety bugs" and "preventing memory safety bugs statically." When this blog post refers to "memory safety skeptics," it refer
7.
by withoutboats3 1y ago
genuinely so sad to me that you are still grinding this axe. if your fantasy design works so much better - go build it then!
8.
by withoutboats3 1y ago
Initial comments as I write this are all negative, and also responding to something the blog post didn't claim. The only time it says faster than C is when talking about a language targeting the GPU; it is not controversial that GPUs
9.
by withoutboats3 1y ago
The alternative to C++ that I meant was Rust, which statically prevents data races.
10.
by withoutboats3 1y ago
The occurrence of data races depends on the specific non-deterministic sequence of execution of concurrent codepaths. Just because you have 100% code coverage does not mean you've covered every potential execution sequence, and its alm
11.
by withoutboats3 1y ago
This is exactly the attitude this blog post spends its first section pretty passionately railing against.
12.
by withoutboats3 2y ago
The IO aspect is not a surprising flaw but it's disappointing to learn that Erlang lets any process enumerate all the other ones.
13.
by withoutboats3 2y ago
Joe Armstrong goes to lengths to describe the benefits of "privately addressable" actors in his thesis (though he uses different terminology). As far as I'm aware, Erlang actors are also privately addressable. cf: > System
14.
by withoutboats3 2y ago
100%. So tiring that the discourse around this is based on 15 minute demos and not actual understandings of the trade offs. Varun Gandhi's post that you link to is great. Based on my experience with Rust, a lot of what people want to d
15.
by withoutboats3 2y ago
Better newtypes are the answer. Consider Java for example. In Java, interfaces are even more restrictive than traits: only the package which defines the class can implement them for that class, not even the package which defines the interfa
16.
by withoutboats3 2y ago
Implementations are not imported at all because they are not named. Like I wrote, named implementations (ala ML modules) is a valid alternative, but one with a much greater annotation burden. You could imagine having named impls that are
17.
by withoutboats3 2y ago
Your conclusion is correct. I'm very happy with the two that Rust picked and tired of people pretending that there will be a magical pick three option if we just keep talking about it.
18.
by withoutboats3 2y ago
Implementations are not exported or public at all: they are used in functions and those functions are exported. For correctness, you want those implementations to be resolved consistently (this is what coherence is). This post gives the exa
19.
by withoutboats3 2y ago
This post is written by a fan of implicits, so it frames it as "better" than traits, though at the end it admits it is in fact a complex trade off, which is the truth. In my opinion, the trade off favors traits, but others may fee
20.
by withoutboats3 2y ago
[flagged]
21.
by withoutboats3 2y ago
[flagged]
22.
by withoutboats3 2y ago
I freely admit I’m frustrated by the discourse around async Rust! I’m also very frustrated because I feel I was iced out of the project for petty reasons to do with whom I’m friends with and the people who were supposed to take over my work
23.
by withoutboats3 2y ago
To be fair, I’m not sure if there exists any zero cost IOCP library. The main way people use IOCP is via mio via tokio. To make IOCP present a readiness interface mio introduces a data copy. This is because tokio/mio assume you’re depl
24.
by withoutboats3 2y ago
Hmm, because the cancel CQE will have a reference to the CQE it was supposed to cancel? Yes, that could work.
25.
by withoutboats3 2y ago
It's true, there's a necessary layer of abstraction with io-uring that doesn't exist with epoll. With epoll, the reactor just maps FDs to Wakers, and then wakes whatever Waker is waiting on that FD. Then that task does the sy
26.
by withoutboats3 2y ago
My sincere apologies if I read this uncharitably, I interpreted your comment about sarcasm to itself be sarcastic. I will not be publishing any such post. To clarify what you seem not to understand: the code in the blog post depends on a li
27.
by withoutboats3 2y ago
[flagged]
28.
by withoutboats3 2y ago
[flagged]
29.
by withoutboats3 2y ago
If you want the language to encode a liveness guarantee that you do something meaningful in response to an accept rather than just accept and close you do need linear types. I don't know any mainstream language that encodes that guaran
30.
by withoutboats3 2y ago
You're right. Looking at my actual code, instead I stored the accept to be yielded next time you call accept and only cancel an accept call if you drop the entire listener object mid-accept. The solution proposed in this post doesn&#x2

More ›