Between 20 and 35 years ago when I was writing a lot of C/C++ code there was no context for the memory safety that we desire today. Memory-safe meant "doesn't overwrite video memory due to a stray pointer" or "doesn't seg fault on Unix."
-
-
Replying to @VaughnVernon @pcwalton
I understand. Yes, the meaning of "memory-safe" changed over time. I'm 28 years old, therefore I don't know about that time you speak of, but for what you say I guess that market changed and mass online platforms created a new meaning for "just a bug".
2 replies 0 retweets 0 likes -
I don't think anyone blames anyone with the code written 30 years ago (it enabled finding new solutions) , but definitely we feel the current definition of memory-safe, and not the old one. And that is a good thing, it means that we all can afford to think about that now.
2 replies 0 retweets 0 likes -
If you had to implement a desktop app today, what language and toolkit would you use? It's possible that today's desktop app is server-based running on the client. Would anyone know or care?
1 reply 0 retweets 0 likes -
Replying to @VaughnVernon @pcwalton
Depends of the app. If it required high performance, maybe Rust, maybe some html over a OpenGL, like some videogames do or even something like Azul (https://github.com/maps4print/azul ) if it was more mature.
2 replies 0 retweets 0 likes -
Cool, I didn't know that Rust had any GUI frameworks. What I meant by server-based is actually running server software on the client with an HTML5 browser. In other words, if you don't have "memory safe" desktop languages and tools you just redefine desktop software.
1 reply 0 retweets 0 likes -
Replying to @VaughnVernon @pcwalton
I see. Yes, I really like the idea. Electron was a first general approach but with a very high memory consumption. Tools like Azul/Servo/Pathfinder/WebRender are pushing the boundaries of what can be done with web standards. They are the way to go in my opinion.
1 reply 1 retweet 4 likes -
David Bonet Retweeted Alan Jeffrey
David Bonet added,
1 reply 0 retweets 0 likes -
Nice. Implementation language?
1 reply 0 retweets 0 likes -
Replying to @VaughnVernon @pcwalton
Pathfinder: Rust Magic leap, I don't know, but it probably is compatible with engines, therefore C++ ensured. A bit off topic but I remember that Unity is slowly replacing C++ parts with a subset of C#. I don't remember where I read that, I think from
@aras_p , but not sure.3 replies 0 retweets 1 like
The Magic Leap API is C++. This demo is Rust code that calls the ML API via FFI. I also have an Android/Daydream port in the repo. That one is a Java shell app that calls Rust functions through JNI. (There is a jni crate for Rust that enables this.)
-
-
It's nice that we're flexible enough to work in both "other language calls Rust" and "Rust calls other language" scenarios.
0 replies 0 retweets 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.