moldavi

6 ms·

1.
by moldavi 2y ago
Do Apple's chips (M1 etc) change this at all, since they share memory with the GPU?
2.
by moldavi 4y ago
You know nothing of what I'm programming. You don't know when, whether, or how my program accesses or deletes data. You don't know what domain I'm in, whether I'm on a team, or what our priorities must be. And yet,
3.
by moldavi 4y ago
GP was confused about why the doubly linked list case was so important, so I enlightened, it's an example of an entire class of the borrow checker's problems. Your response isn't really relevant in that context, and instead e
4.
by moldavi 4y ago
It's not just doubly linked lists. They're just a basic example of borrow checking not being able to handle a lot of easy patterns that are perfectly safe in other languages.
5.
by moldavi 4y ago
I've experienced this as well. Any disagreement always comes down to "you just haven't used it enough". I let myself take that gaslighting for years before I decided to just not go to the Rust servers any more. And then
6.
by moldavi 4y ago
Single ownership often introduces bugs of its own. In Java, I never need to create an Err if the thing my ID is "pointing" to isn't around anymore in whatever hash map the borrow checker made me store it in. It's good in
7.
by moldavi 4y ago
Pony is a great example of fearless concurrency without the borrow checker's difficulties.
8.
by moldavi 4y ago
That absolute claim is simply not true. That's like saying that people need to avoid shared mutability in every program, which simply doesn't make sense for a lot of programs, especially if you have a garbage collector already. It
9.
by moldavi 4y ago
Easier than C or C++ for sure. But I definitely wouldn't say that Rust as easy as a GC'd language like Java or Go. They have strictly less constraints to deal with, they can let you use the simplest pattern for the situation, and
10.
by moldavi 4y ago
Can we please not do this? It's fine to give a different viewpoint, but it's surprisingly common that whenever someone says anything bad about Rust, a Rust user comes in to say that they just haven't used it enough. It's
11.
by moldavi 4y ago
I'm sometimes a bit confused when people say that Rust has less cognitive load. I assume that's compared to something like C or C++, right? I've used Rust and (imperative-style) Scala a lot, and I have to say, Scala is way ea
12.
by moldavi 4y ago
Rust will never be used as widely as GC'd languages like Java, Go, C#, etc. It's incredibly well-designed, but you can't design away the inherent complexity of writing safe, secure, fast code. There's no way to make that
13.
by moldavi 4y ago
I've seen both sides of this, as a Rust user and as a Go user. Rust users are generally friendly to one another, and to people who are interested in Rust. Hoever, some Rust users are toxic when talking to people outside the community o
14.
by moldavi 4y ago
For a single player turn-based game, I'm not so sure the tradeoff is as obvious as everyone says, after coding one in C++ and another in Rust. It's turn based, so I don't need AAA game multi-threaded performance. It's si
15.
by moldavi 4y ago
Saying it's "idiomatic" isn't very actionable advice for people, the average programmer hears that and doesn't really know when to use Rc over other approaches. I also wouldn't say to always go with the most er
16.
by moldavi 4y ago
That's where the discipline comes in: one has to know when it's okay to use the simpler approach (indices into a Vec), and when it's better to use Arcs such as to prevent privacy problems.
17.
by moldavi 4y ago
In Rust, people tend to go for the easiest solution that works within the borrow checker, and not workarounds like Rc or Arc. Otherwise, the performance hit means there's little reason to use Rust over much easier languages.
18.
by moldavi 4y ago
That's why I said one should have the discipline and practices in place to avoid this bug. I think we can do better than saying that indexes into Vecs are "non-idiomatic" in applications... such advice could remove much of Ru
19.
by moldavi 4y ago
That's why I mentioned one needs to have discipline, to not use that particular solution. We agree it's not the best solution. And it's easy for us to say that now, after I've spelled out why. You'd be surprised how
20.
by moldavi 4y ago
In fact, in the pursuit of eliminating memory-safety and security bugs, Rust can sometimes makes some privacy bugs more likely. For example, in GC'd/RC'd languages, if we have several UserAccount instances and a bunch of long
21.
by moldavi 5y ago
React and Polymer seemed like an okay balance of of OO and functional... are our current GUI architectures really that nasty?
22.
by moldavi 5y ago
The author could have recommended Scala, which has all of Rust's type system benefits, plus garbage collection (and of course, minus the low level control over performance). YMMV though, as everyone uses Scala differently. A lot of Sca
23.
by moldavi 5y ago
I'm also curious about the architectural consequences of Rust. It seems to force us into a very procedural or functional style, and sometimes makes us use parallel collections for things in a way reminiscent of relational databases...
24.
by moldavi 5y ago
Something about Odin I like is that you can have multiple allocators, and use a bump allocator for just a specific call (and its subcalls), and afterward free it all at once, and go back to normal heap allocation. It would be cool if Rust o
25.
by moldavi 5y ago
Doesn't GhostCell preclude deletion, and effectively grow forever?
26.
by moldavi 5y ago
Same, that was... harrowing.
27.
by moldavi 5y ago
Doesnt Rust have implicit panics on indexing out of bounds? I wonder if any codebases lint those away.
28.
by moldavi 5y ago
I used to love making custom games for Kyle's Quest! I wish games like that existed today.
29.
by moldavi 5y ago
Rust has paid promoters?
30.
by moldavi 5y ago
The same thing was loudly proclaimed about both C++ and Java, yet C is still here.

More ›