verdagon

39 ms·

1. 301.▲
   by verdagon 5y ago

   It's because const pointers aren't "deeply" immutable. For example, if we have a const Car*, we can reach into it to grab a (non-const) Engine* through which we can modify things. If there was a "imm" keyword i
2. 302.▲
   by verdagon 5y ago

   That's what this "region borrow checking" solves: if a pure function (or block) regards all previously existing memory as one immutable region, it doesn't matter if there was any mutable aliasing happening before, becaus
3. 303.▲
   Surprising Weak-Ref Implementations: Swift, Obj-C, C++, Rust, and Vale(verdagon.dev)

   8 points by verdagon 5y ago|2 comments
4. 304.▲
   by verdagon 5y ago

   > To summarize, enforcing [Rust's] borrowing rule in C++ is unfortunately not so simple because there is a lot of existing code that creates multiple non-const pointers or references to the same object, intentionally violating the b
5. 305.▲
   by verdagon 5y ago

   Perhaps, but maybe there's a better approach. I prefer having a new language which can build on and speak to other languages in their own paradigms. That's what Swift did for Obj-C and also the direction we're going with Vale
6. 306.▲
   by verdagon 5y ago

   > There are important language features missing from C (and C++) that make it impossible to implement a Rust-style mutex API with the same guarantees I've done some experimenting here, and I think it is possible to add a borrow chec
7. 307.▲
   by verdagon 5y ago

   If the afterword's "region borrow checking" concept interests you, check out the "Seamless, Fearless, Structured Concurrency" article [0], it goes into some detail on that. [0] https://verdagon.dev/b
8. 308.▲
   by verdagon 5y ago

   Two operations can be concurrent, even if they are run on the same thread, as long as they are unsequenced, in other words, there is nothing making one happen before the other. That's what the C++ standard says, linked from the wikiped
9. 309.▲
   by verdagon 5y ago

   I'm not seeing anything in the links suggesting that there's a special different "concurrency" than the one commonly used in programming discussion. The Wikipedia article quotes part of the C++ standard which defines &qu
10. 310.▲
    by verdagon 5y ago

    Two different kinds of concurrency, a twist! If you have a link to enlighten, I'd love to read more about this.
11. 311.▲
    by verdagon 5y ago

    These things are running concurrently with each other though. Concurrent operations can happen one after the other, and Python's threads are more about concurrency than parallelism. If these definitions instead mentioned "simultan
12. 312.▲
    by verdagon 5y ago

    Thanks for the clarification. It's interesting that we see the same definition so differently. The Python example has two concurrent accesses of the same memory (the global counter) where one of them is a write. That seems to meet the
13. 313.▲
    by verdagon 5y ago

    Everyone seems to have their own definition of data race! The article uses the one from the Rustonomicon, and by that definition, the Python example does appear to have a data race. (Edit: Apologies for misreading; our definitions are indee
14. 314.▲
    by verdagon 5y ago

    The feature just makes it run identically to the last run. It's useful for reproducing bugs; if you encounter a bug, just start the program in "replay" mode, supply the recording from the last run, and fire up the debugger, a
15. 315.▲
    by verdagon 5y ago

    The article isn't trying to claim either interpretation, it's just using it as an example to show that the GIL doesn't actually help protect users from concurrency problems. You'd be surprised how many people think that!
16. 316.▲
    by verdagon 5y ago

    Author here, u/skeeto from https://www.reddit.com/r/programming/comments/sxy5q4/pythons... has some good insight into the 3.10 difference: > Ironically, CPython 3.10 has gone the opposite directi
17. 317.▲
    by verdagon 5y ago

    It's tricky but it is possible, if we: 1. Don't allow any undefined behavior or `unsafe` code in the language. 2. Record all inputs from FFI. 3. Carefully track the orderings of interactions across threads. The article goes into t
18. 318.▲
    Data races in Python, despite the Global Interpreter Lock(verdagon.dev)

    85 points by verdagon 5y ago|70 comments
19. 319.▲
    by verdagon 5y ago

    Thanks! This article makes some nice recommendations, but they don't have much to do with Rust, these things have been in a lot of other mainstream languages for a long time. I'm not sure this supports zozbot's claim that the
20. 320.▲
    by verdagon 5y ago

    Thanks for the link. I don't see any occurrences of "Rust" in this document...
21. 321.▲
    by verdagon 5y ago

    This isn't true at all IME. Rust's paradigms are great a lot of the time, but the best C++ code does not necessarily look like Rust code in all situations. There are a lot of patterns in modern C++ which the borrow checker rejects
22. 322.▲
    by verdagon 5y ago

    Alas, doing it gradually doesn't make the cost/benefit any better. It might slightly reduce the short-term risk of the product dying, but it would also increase the medium-term cost of the rewrite. The boundary between C++ and Rus
23. 323.▲
    by verdagon 5y ago

    Thanks for the clarification, yep I meant the web client. We didn't rewrite iOS/Android either, any memory unsafety bugs just cause odd behavior on that user's device, and wouldn't e.g. give an attacker root access to ou
24. 324.▲
    by verdagon 5y ago

    That sounds nice on paper. We all like good coding practices. We all like Rust's benefits, not just the memory safety ones. My argument is a cost/benefit analysis; those nice benefits aren't worth the massive cost of rewrit
25. 325.▲
    by verdagon 5y ago

    An interesting thought, but are you suggesting we could run arbitrary Rust code, unsandboxed, in users' browsers?
26. 326.▲
    by verdagon 5y ago

    I think greenfield projects in Rust make a lot of sense. However, for some existing projects, the math just doesn't check out. I worked on Google Earth for a few years, and the core was in C++. With ASan and modern C++, memory safety b
27. 327.▲
    by verdagon 5y ago

    > If you are interested in helping solve any of these problems, please reach out! Coincidentally, we're working on these problems with Vale [0] by obviating the need for unsafe, while still having single ownership's performance
28. 328.▲
    Seamless, Fearless, and Structured Concurrency(verdagon.dev)

    1 points by verdagon 5y ago|0 comments
29. 329.▲
    by verdagon 5y ago

    Is Google really innovating anymore though? In my last year there I felt like all the small projects were getting shut down to fuel ads/search/cloud.
30. 330.▲
    by verdagon 5y ago

    Is it possible to optimize too much for experts, and sacrifice learning curve too much?