Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
verdagon
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
37 ms
·
361.
▲
by
verdagon
5y ago
I've never dabbled with multi-threading in Rust, so I'm curious how far it can go in practice. In our closure, we probably can't have any RefCell or Rc or anything that could reach either of those things, because those can&#x
362.
▲
by
verdagon
5y ago
Vale uses the term "regions" a bit differently, as a way to represent a collection of objects that all are all treated the same (usually w.r.t. memory management). We have something called the "region borrow checker" whi
363.
▲
by
verdagon
5y ago
Thank you for this thorough and balanced explanation! This is probably why all the GUI frameworks in Rust (that I've seen) require message passing like this. You have a really good handle on the borrow checker's benefits and limit
364.
▲
by
verdagon
5y ago
I thought COM was a way to talk between applications/libraries, not between GUI elements? Message passing at that level is fine IMO, but between GUI views/controllers sounds like a bad tradeoff though.
365.
▲
by
verdagon
5y ago
I think what you might be missing is that, in (safe + idiomatic) Rust, we actually can't have references between things (unless we want to make our entire GUI immutable, which would be a tad silly). Since we can't use references,
366.
▲
by
verdagon
5y ago
My bad, I didn't really explain that part. In practice, when we receive a GUI event, we then modify something in our surrounding environment, usually some model, controller, or other view. To interact with any of those in Rust, we need
367.
▲
by
verdagon
5y ago
My point was that when we hydrate, we don't use the same IDs as what was in the serialized data. Otherwise, we'd have conflicts when we hydrate the same definition multiple times.
368.
▲
by
verdagon
5y ago
By opaque, do you mean encapsulated? Encapsulation is pretty important to software architecture, in that it enforces decoupling between components. Rust has private visibility for this very reason. The filtering you're talking about so
369.
▲
by
verdagon
5y ago
I'm afraid that when dealing with nondeterminism, you *do* need to be perfect. If even one call is nondeterministic, you've corrupted your entire replay. This is a common challenge with e.g. RTS games, and it means we have to very
370.
▲
by
verdagon
5y ago
I'm not sure this is how WYSWYG really works. There's only one MyFancyTextEditor widget definition, a blueprint so to speak. It's IDs refer to other things inside that blueprint. But at runtime, we might instantiate two diffe
371.
▲
by
verdagon
5y ago
You might be serializing your enums, but unless you serialize a lot more (button IDs, view IDs, etc), the IDs in your enums will be meaningless. I don't think you're suggesting we serialize the entire GUI? This also seems like the
372.
▲
by
verdagon
5y ago
If we had a closure, we wouldn't ever need to "handle all possible events", we would just do a virtual call. It's guaranteed to be handled.
373.
▲
by
verdagon
5y ago
> 1. All your actions are in one place. Figuring out what can happen as a result of a series of user interactions can be done without navigating through a component hierarchy. I'd imagine it would be easier to just call a method on
374.
▲
by
verdagon
5y ago
I personally appreciate when languages have a consistent style. I think on the whole it helps readability more than it hurts. We're enforcing whitespace around infix operators in Vale, and it's working pretty well. It's also
375.
▲
by
verdagon
5y ago
Any ideas on how one can simplify the borrow checker?
376.
▲
by
verdagon
5y ago
There's a pretty clear tree of ownership, actually. Looking at any given component, it's fairly easy to know when a component is a "subcomponent" (owned) or whether it's a reference to some other component elsewhere
377.
▲
by
verdagon
5y ago
I would love your opinion on whether migrating to Rust is a good idea for us, since you're experienced in this realm. My team has a Java project that's written in a modern OO style. We defined "modern" OO as encapsulatio
378.
▲
by
verdagon
5y ago
The runtime overhead of RefCell<> is usually accompanied by some other runtime overhead. To be reachable from multiple places, it usually needs to be stored in some relatively central location. If it's a rather short-lived object
379.
▲
by
verdagon
5y ago
Agreed! While it's not considered "idiomatic" Rust (from all my conversations on the Rust discords), I think that interior mutability is a totally fine thing to reach for in certain cases, at the upper levels of one's ar
380.
▲
by
verdagon
5y ago
> Rust does have a lot of complicated stuff, but almost all of it secretly turns up if you wanted to be good at C++ too. This is mostly true. As FP and Rust have shown us, if you can treat an input data set as immutable, while building u
381.
▲
by
verdagon
5y ago
That's a fair point. I'd add: some GC'd languages solve this with sending around deeply immutable objects (functional languages mostly), in a way that can be more flexible than the way Rust handles immutable objects.
382.
▲
by
verdagon
6y ago
I'm a big fan of this kind of improved RAII. We implemented it in https://vale.dev/blog/raii-next-steps , you might find it interesting!
383.
▲
Generational references: 2.3x faster than reference counting (unoptimized)
(vale.dev)
11 points
by
verdagon
6y ago
|
0 comments
384.
▲
Vale's Generational References
(vale.dev)
14 points
by
verdagon
6y ago
|
0 comments
385.
▲
Zero-Cost References with Regions
(vale.dev)
6 points
by
verdagon
6y ago
|
0 comments
386.
▲
Zero-Cost References with Regions in Vale
(vale.dev)
3 points
by
verdagon
6y ago
|
0 comments
387.
▲
Zero-Cost References with Regions in Vale
(vale.dev)
4 points
by
verdagon
6y ago
|
0 comments
388.
▲
by
verdagon
6y ago
Great question! We could also use a deleter, set up when we create the object, but thats often too early to know what parameters to pass into the destructor. In some cases, you do know the destruction parameters up-front, and there I would
389.
▲
by
verdagon
6y ago
The other main (safe) alternative to Rc<RefCell<T>> for mutable aliasing is Vec + generational indices, which also involves an expect/unwrap assertion whenever you expect something to be alive and it isn't. If you need
390.
▲
by
verdagon
6y ago
That's interesting! I'm fairly certain Vale avoids the problem with its lambda approach, but I can see a partially initialized array being very useful for Rust. In fact, I think Cone [1] does exactly that; you can designate a cert
More ›