Live data from Hacker News

Viewing profile — simonask

simonask

HN member
Joined
Sun, May 06, 2012, 9:03 AM UTC
HN karma
2,134
Public activity
704 items

About simonask

No profile information was provided.

Recent public activity

  1. comment
    Comment #49221980

    > Granted, society benefits most from the work of the exceptional, so it may still be worth it. That's a baffling proposition. I think society benefits overwhelmingly more from the…

  2. comment
    Comment #49221961

    > And then a lot of humans... most humans... drift through life without any sense of purpose. Whoever told you this or gave you that impression? It certainly does not reflect anyon…

  3. comment
    Comment #49219946

    The moat around billionaires isn't money, it's the political apathy of the American working class, which somehow believes itself to not exist. Well, it's also money, because it inf…

  4. comment
    Comment #49219933

    What's unfathomable to me is that so many people seem to believe that a sense of purpose can only be derived from need. Humans aren't like that. They don't deprive themselves of ac…

  5. comment
    Comment #49208854

    Yeah, absolutely. I would be worried about a JSON parser facing the internet that had these kinds of problems, for example. But it's only the very first in a long line of potential…

  6. comment
    Comment #49208803

    C++ can be slow to compile, but as I said, parsing is not the bottleneck. Even for really huge automatically generated C++ files, or old-school concatenated "unity builds", the par…

  7. comment
    Comment #49207955

    I think the second-hardest thing is to accept that CS spent decades optimizing parsing algorithms and grammars, and this is still a significant part of CS curricula in many places.…

  8. comment
    Comment #49180098

    C++ just lets you pass a reference or pointer from one task's stack to another task or thread, with no assurance that the callee task terminates before the caller's stack is deallo…

  9. comment
    Comment #49165593

    Skimming the proposal, that looks like the equivalent of the "executor" (scheduler) and "task" (sender) implemented in Rust async runtimes. I could have missed it, but I don't see …

  10. comment
    Comment #49165525

    Right, of course. Yeah, it's an API riddled with so many double negatives it's hard to keep track.

  11. comment
    Comment #49156413

    I'm very probably missing something, but as a user I would definitely expect `Iterator::Item: Move`, but then also that `&{mut} T: Move where T: ?Move`. But yeah I can see how thes…

  12. comment
    Comment #49155625

    I really want to like OCaml. One day I'll get around to learning it.

  13. comment
    Comment #49155177

    I agree with most of that, but there's one important detail (that I'm sure the designers of this proposal are thinking about): The current contract of Pin in Rust (the only standar…

  14. comment
    Comment #49155049

    I guess `!Move` is largely equivalent to `Unpin` for the purposes of `Pin`, so for example Pin's safe constructor `Pin::new()` can be re-expressed in terms of `!Move` instead of `U…

  15. comment
    Comment #49155008

    Wait, how does it actually change the recursive async story? The problem today is that the compiler-synthesized struct implementing `Future` for each async function cannot contain …

  16. comment
    Comment #49154974

    > and is a major source why people dislike Rust's async It's worth mentioning that there is, in fact, no language out there other than Rust that can even do this in the first place…

  17. comment
    Comment #49154844

    The naïve idea would be to just say that all generic parameters have an implicit `where T: Move` bound, and you have to explicitly opt out of it with `where T: ?Move`, just like wi…

  18. comment
    Comment #49154818

    None. The question is more what happens when you put a `!Move` type into, say, `Vec `, because that's a collection type that regularly moves its elements to a new allocation when i…

  19. comment
    Comment #49152854

    For context, the reason this would be really nice is that it would enable API designs that catch certain kinds of errors. let txn = create_transaction(); // do something with the t…

  20. comment
    Comment #49152333

    The big one is scoped tasks, or structured concurrency. Currently, Rust has scoped threads: Threads that are guaranteed to terminate before the function that spawned them returns. …

  21. comment
    Comment #49126544

    The older I get, the more critical I become of the culture of anonymity in OSS. The obvious-but-hard solution to this, as well as certain other attacks like the xz incident, is a c…

  22. comment
    Comment #49094443

    The post I replied to criticized people’s choice to have “random sex”, i.e. they suggest a behavioral change. Getting tested is great practice, but you can’t rely on partners being…

  23. comment
    Comment #49094313

    Every analysis of the problem I've seen has concluded that the main problem is that rustc generates a lot of input to LLVM. Efforts to reduce compilation times are currently focuse…

  24. comment
    Comment #49084731

    Abstinence has been shown to be an extremely, hilariously, stupidly ineffective strategy in all questions of human sexual health. The HIV/AIDS epidemic would not have been nearly a…

  25. comment
    Comment #49084623

    As we all hopefully learnt from COVID-19, slowing sufficiently is the same as stopping. It’s a numbers game. Slowing transmission below some threshold will eventually mean that the…