How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
Looking at this makes me nostalgic in a way the author probably hasn't intended.
Rust is notorious for its slow compile times, while Turbo Pascal was known to be blazingly fast. And the debugger, one of the most important part of the experience is "Not implemented". Dressing it as a 1989 IDE makes me painfully aware of what we have lost. Despite running on hardware that were orders of magnitudes slower than today, software used to be more responsive.
By "more responsive" I mean that while modern systems are excellent at batch processing, latency is often not great, and because so much happens in parallel, also confusing.
Not really, because contrary to Rust, Haskell, C++ and OCaml have faster alternatives, even though some people decide to ignore them to their own pain.
Haskell has GHCi, where you can pre-compile modules and play around in the repl with code that is more in flow.
OCaml has a bytecode interpreter, and a repl, thus you can compile only what you need, and do the full compilation for proper releases.
C++, well, yes it is slow, if you don't make use of binary libraries, external templates, incremental compilation and incremental linking, parallel builds, hot code reloading (VC++ and Live++), or REPLs (ROOT/cling, Clang-Repl).
The danluu article's great but I'd add that polling frequency is only part of it -- the software stack latency (OS scheduling, rendering pipeline) often dwarfs the hardware contribution, as far as I can tell from the literature.
Measured on a a IBM PS/2 Model 60, meaning an Intel 80286 running at 10 MHz with 640 KB for MS-DOS, up to 8 MB depending on extenders and HMA configurations.
The blue CRT glow of Turbo C++ / QBasic 4.5 IDE at 12 AM when I've snuck up in the middle of the night to poke around on the family computer on a school night when I was ~10 years old... I love this.
I haven't felt a lot of desire to code in Rust but I do now! Absolutely applaud this project - it's completely tugged on the retro nostalgia strings for my Turbo Pascal days. Also one of the reasons I enjoy the previously HN featured Microsoft Edit project immensely - https://github.com/microsoft/edit. Thank you OP
Thank you for that - I’m definitely going to look into it.
I realize that I lost the fun in coding. I’m in a different career stage now as well, but just seeing this reminded me of how I started a long time ago implementing snake, learning about graphics mode, double buffering / page flipping etc.
Everything felt exciting and so close to really understanding what’s going on. And just seeing the blue text interface reminded me of how much fun that was…
I am glad to hear how the project resonates with you and other people here. I was reading an article about coding in the 90s and thought, the best time I had was on our first computer. Starting out with Basic, Pascal, Assembly and C++. Text mode, VGA mode, INT 10h ... what fun
Cool! I assume TRUST stands for "Turbo Rust"? If yes, maybe it would be worth mentioning that in the readme. I doubt that Embarcadero Technologies (the current owners of the Delphi and C++ Builder IDEs, and probably also the owners of other former Borland trademarks) would mind - but then again, it doesn't hurt to stay on the safe side...
Staying on the safe side would be not confirming whether it stands for Turbo Rust or not. "You might very well think that; I couldn't possibly comment."
I recommend VHS generally for these (we use them for all the ratatui screenshots generally). I'm also playing around with doing a rust version of this (https://www.joshka.net/betamax/)
Turbo Vision library, which apparently inspired TRust, had a great object model, in which you could derive built-in classes implementing controls, windows, validators etc., extend them by adding custom functionalities and seamlessly plug them into the system. Imagine extending the built-in TEditor class to handle syntax highlighting, or extending TDialog to handle complex multi-tab option dialogs.
To beat 1989 and Turbo Pascal, TRust must do that (perhaps the Rust's way).
Honestly the experience looks pretty nice. Which is crazy to say for such an old style of program but I kind of like it. Perhaps just nostalgia for a time I never got your experience.
Thank you! I may build this out further. I just wanted to get started and feel like back then; share and see what happens. If I am the only one who is excited about this.
A year or so ago I spent half a day writing some Rust on an actual DEC glass teletype (VT520) connected to a Debian box. I used vim and shell job control (^Z, jobs, fg, etc.) to switch between tooling and a persistent text editor. It made me feel things.
That vim and job control workflow is basically what runs half our prod fleet. Works until someone fat-fingers a ^C and wonders why the deploy job vanished.
The nostalgia framing feels off to me. QBASIC was exciting because it was a gateway — not because the IDE looked retro. Does aesthetics-first tooling actually help you learn Rust better?
I actually expected an unsafe-only Rust because of the name and the "archaic" date (of course, "safe" languages did exist at the time, if not low-level and safe ones).
Ran it on a small embedded project. The syntax highlighting in the editor felt snappier than I expected, and the inline error display saves constant terminal-switching. Biggest gotcha: rebuild on save isn't default.
Rust is notorious for its slow compile times, while Turbo Pascal was known to be blazingly fast. And the debugger, one of the most important part of the experience is "Not implemented". Dressing it as a 1989 IDE makes me painfully aware of what we have lost. Despite running on hardware that were orders of magnitudes slower than today, software used to be more responsive.
By "more responsive" I mean that while modern systems are excellent at batch processing, latency is often not great, and because so much happens in parallel, also confusing.