I have a daydream.
Uncategorized
16
Posts
3
Posters
0
Views
-
(cont)
If the reason for the split is "Lua is for 'business logic', C is for high performance stuff", you'd think you'd want the matrix multiplication on the C side. But things will never work out that politely. At some point in a single function you'll wind up going, oh, I gotta mutiply this matrix, it would be really inconvenient to move all this over the line. And invariably, a larger and larger set of utility functions wind up being duplicated 3 times (C, Lua, GLSL).- There is a second problem with "partly in Rust, partly in Lua". Rust is greedy! Rust is a totalizing system. C is pretty easy to interface with other languages; C++, less so. Rust has all kinds of things that don't map well into other languages but are *important*.
Why is everything being rewritten in Rust these days? I have a theory. It's because Rust has all these really great libraries people want to use. And the only way to access them is Rust, since *Rust doesn't interoperate well!*
-
- There is a second problem with "partly in Rust, partly in Lua". Rust is greedy! Rust is a totalizing system. C is pretty easy to interface with other languages; C++, less so. Rust has all kinds of things that don't map well into other languages but are *important*.
Why is everything being rewritten in Rust these days? I have a theory. It's because Rust has all these really great libraries people want to use. And the only way to access them is Rust, since *Rust doesn't interoperate well!*
(cont)
Like, Rust *can* interoperate— as I said, mlua's great. But the interop is such that you have to do a bunch of *work* to expose functionality in Rust primitives to another language.Rust (glossing over many things) was supposed to be a language for writing VMs, for writing *one* VM, Servo. It's designed for interop. It's *designed* for the "the hard parts in this compiled language, easy parts in JS". But the hard parts aren't hard enough. It's easier to just write it *all* in Rust!
-
(cont)
Like, Rust *can* interoperate— as I said, mlua's great. But the interop is such that you have to do a bunch of *work* to expose functionality in Rust primitives to another language.Rust (glossing over many things) was supposed to be a language for writing VMs, for writing *one* VM, Servo. It's designed for interop. It's *designed* for the "the hard parts in this compiled language, easy parts in JS". But the hard parts aren't hard enough. It's easier to just write it *all* in Rust!
(cont)
At least, this is the trap I'm in. I'd like a scripting language, but my scripting languages can't easily access Rust stuff, and a lot of what I want to use is in Rust, so I just use Rust. Suboptimal.Hence, a solution: *The scripting language should use the Rust ABI*. I'm not sure this has ever been done fully. There are several scripting languages which are Rust-flavored or sit atop Rust, I've skimmed docs for a couple. As far as I *know* "just interpret Rust" would be a novel one.
-
(cont)
At least, this is the trap I'm in. I'd like a scripting language, but my scripting languages can't easily access Rust stuff, and a lot of what I want to use is in Rust, so I just use Rust. Suboptimal.Hence, a solution: *The scripting language should use the Rust ABI*. I'm not sure this has ever been done fully. There are several scripting languages which are Rust-flavored or sit atop Rust, I've skimmed docs for a couple. As far as I *know* "just interpret Rust" would be a novel one.
- I've been dealing with "writing in 2 languages means duplication/annoying refactors" a long time.
Thus, my daydream for a long time has been a programming language that's interpreted/compiled dual mode, such that "porting" across the interpreted/compiled line is just a matter of adding types until there are no untyped statements left. (From what I hear Racket tried this, and there were huge problems. Not sure if I should take this as a warning against trying, or a guide for things to avoid).
-
- I've been dealing with "writing in 2 languages means duplication/annoying refactors" a long time.
Thus, my daydream for a long time has been a programming language that's interpreted/compiled dual mode, such that "porting" across the interpreted/compiled line is just a matter of adding types until there are no untyped statements left. (From what I hear Racket tried this, and there were huge problems. Not sure if I should take this as a warning against trying, or a guide for things to avoid).
(cont)
I at one time thought I'd do this by taking an interpreted language and adding types (this was Emily 2). It turns out writing a typechecker is hard! Writing a compiler is hard! I never got the full thing working. Okay, I give up. Somebody already wrote the Rust compiler. I'll go the other direction. Start with a compiled language I like using, give it an interpreted mode. Solve the "compilers hard" and "Rust interop annoying" problems at once! -
(cont)
I at one time thought I'd do this by taking an interpreted language and adding types (this was Emily 2). It turns out writing a typechecker is hard! Writing a compiler is hard! I never got the full thing working. Okay, I give up. Somebody already wrote the Rust compiler. I'll go the other direction. Start with a compiled language I like using, give it an interpreted mode. Solve the "compilers hard" and "Rust interop annoying" problems at once!This thread got ungainly & apparently I needed 1000-character posts to write it coherently. But I have been stewing in these ideas for several years and some *variant* of them for like, 15 years. This might actually happen. Last year I wrote a language interpreter in Rust (a flimsy LISP) and it wasn't so hard. Eventually some version of this will happen. The nice thing is even if it's terrible, it has the defense "well, use it during dev, then rewrite the whole thing in Rust before you ship it".
-
This thread got ungainly & apparently I needed 1000-character posts to write it coherently. But I have been stewing in these ideas for several years and some *variant* of them for like, 15 years. This might actually happen. Last year I wrote a language interpreter in Rust (a flimsy LISP) and it wasn't so hard. Eventually some version of this will happen. The nice thing is even if it's terrible, it has the defense "well, use it during dev, then rewrite the whole thing in Rust before you ship it".
Tangential thought:
A really funny thing is almost everything good about Rust comes down to when it was written. It has excellent LLVM integration because it was written right after LLVM happened. It has a good build system because the build system was written after pip and npm. It has great libraries because all the libraries were written between 2020 and 2024 and so they're all modern. Not sure where I'm going with this but it makes me wonder how Rust will age.
"How Rust will age". Heh.
-
Tangential thought:
A really funny thing is almost everything good about Rust comes down to when it was written. It has excellent LLVM integration because it was written right after LLVM happened. It has a good build system because the build system was written after pip and npm. It has great libraries because all the libraries were written between 2020 and 2024 and so they're all modern. Not sure where I'm going with this but it makes me wonder how Rust will age.
"How Rust will age". Heh.
Tangent:
Imagine this approach for "interpreting" a Rust-like language. You link against LLVM; you *actually compile* the Rust into machine code, in memory; when you want to invoke your script, you simply jump to that code. This is the approach used by Julia and (optionally) GHCi, and it has many advantages.
I wouldn't use it, at least not at first, because it makes your "interpreter" non-embeddable. LLVM is tens of megabytes. It also excludes you from W^X ("no JIT") platforms (iPhone, wasm).
-
Tangent:
Imagine this approach for "interpreting" a Rust-like language. You link against LLVM; you *actually compile* the Rust into machine code, in memory; when you want to invoke your script, you simply jump to that code. This is the approach used by Julia and (optionally) GHCi, and it has many advantages.
I wouldn't use it, at least not at first, because it makes your "interpreter" non-embeddable. LLVM is tens of megabytes. It also excludes you from W^X ("no JIT") platforms (iPhone, wasm).
It is my opinion there is virtually no good reason for an distributed executable to ever be larger than ten megabytes, and for a program without art/sound assets I'd lower that ceiling to something like one to four megabytes. I am aware this is a deeply antiquated opinion but it is the opinion I have. I think this is also the attitude you need if you want to make a language that targets wasm. I have made a serious attempt at JITing C# to ASM.js. There were… there were executable size problems.
-
It is my opinion there is virtually no good reason for an distributed executable to ever be larger than ten megabytes, and for a program without art/sound assets I'd lower that ceiling to something like one to four megabytes. I am aware this is a deeply antiquated opinion but it is the opinion I have. I think this is also the attitude you need if you want to make a language that targets wasm. I have made a serious attempt at JITing C# to ASM.js. There were… there were executable size problems.
@mcc I often think about how a 16MiB 486 was perfectly capable of displaying and editing any document a human could reasonably write. Advances since then have allowed for higher fidelity images, and audio/video playback, and yet software that does neither still consumes gigabytes of RAM. I hate often wondered about adapting a coredump analysis tool to do a top-down breakdown of how the address space is actually used...
-
@mcc I often think about how a 16MiB 486 was perfectly capable of displaying and editing any document a human could reasonably write. Advances since then have allowed for higher fidelity images, and audio/video playback, and yet software that does neither still consumes gigabytes of RAM. I hate often wondered about adapting a coredump analysis tool to do a top-down breakdown of how the address space is actually used...
@kitten_tech I feel like audio/video editing worked really well on circa 2000 computers and I'm not completely certain we do it better now
-
@kitten_tech I feel like audio/video editing worked really well on circa 2000 computers and I'm not completely certain we do it better now
@mcc @kitten_tech Video editing worked ok around then, but more advanced editing was assisted by specialized hardware. This included the switch to HD and DTV sometime between 2001 and 2007 (maybe more but that’s when I worked in the industry). There were some serious limits with the PCI bus. I remember being one of the few people benchmarking PCI latency.
Asside from HD, mpeg4/avc, and encoders, one of the big leaps at the time was the speed of consumer hard drives. -
undefined oblomov@sociale.network shared this topic on
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Quizzino della domenica: Strana equazione
784 - algebra
La sonda marziana Curiosity ha trovato delle scritte dell'antica civiltà marziana. Una di esse, una volta decifrata, è la seguente: 5x² − 50x + 125 = 0: x = 5 e x = 8. In effetti 5 è una soluzione dell'equazione, ma 8 non lo è: 5×64 − 50× + 125 = 45. Quante dita avevano i marziani?(trovate un aiutino sul mio sito, alla pagina https://xmau.com/quizzini/p784.html; la risposta verrà postata lì il prossimo me https://wp.me/p6hcSh-91s
-
What a hole.
Kiev 60
Zodiak-8 30mm F3.5
Lomography Metropolis
-
Even when there’s no accountability, the record matters. Credit to the Wikipedia editors maintaining this page.
-
Tamper Detection with Time-Domain Reflectometry
For certain high-security devices, such as card readers, ATMs, and hardware security modules, normal physical security isn’t enough – they need to wipe out their sensitive data if someone starts drilling through the case. Such devices, therefore, often integrate circuit meshes into their cases and regularly monitor them for changes that could indicate damage. To improve the sensitivity and accuracy of such countermeasures, [Jan Sebastian Götte] and [Björn Scheuermann] recently designed a time-domain reflectometer to monitor meshes (pre-print paper).
Many meshes are made from flexible circuit boards with winding traces built into the case, so cutting or drilling into the case breaks a trace. The problem is that most common ways to detect broken traces, such as by resistance or capacitance measurements, aren’t easy to implement with both high sensitivity and low error rates. Instead, this system uses time-domain reflectometry: it sends a sharp pulse into the mesh, then times the returning echoes to create a mesh fingerprint. When the circuit is damaged, it creates an additional echo, which is detected by classifier software. If enough subsequent measurements find a significant fingerprint change, it triggers a data wipe.
The most novel aspect of this design is its affordability. An STM32G4-series microcontroller manages the timing, pulse generation, and measurement, thanks to its two fast ADCs and a high-resolution timer with sub-200 picosecond resolution. For a pulse-shaping amplifier, [Jan] and [Björn] used the high-speed amplifiers in an HDMI redriver chip, which would normally compensate for cable and connector losses. Despite its inexpensive design, the circuit was sensitive enough to detect when oscilloscope probes contacted the trace, pick up temperature changes, and even discern the tiny variations between different copies of the same mesh.
It’s not absolutely impossible for an attacker to bypass this system, nor was it intended to be, but overcoming it would take a great deal of skill and some custom equipment, such as a non-conductive drill bit. If you’re interested in seeing such a system in the real world, check out this teardown of a payment terminal. One of the same authors also previously wrote a KiCad plugin to generate anti-tamper meshes.
Thanks to [mark999] for the tip!
-
Feditarian Fediversalist
-
@DavidBHimself I guess we will have to agree to disagree on this one.
And yes, I did lose my right to vote when I moved a couple of times, even as a resident+citizen of said location. That’s how our imperfect electoral system works. 😥
-
-
@evan I agree with @EricLawton -- "expatriate" is an imperial term. I see no confusion of terminology in his comment, quite the opposite.
In the context of the poll, "expatriate" was used about emigrants, not immigrants, but the point stands. The clearest term, if a bit long and pedantic, might have been "citizens who are not residents".
