Login
You're viewing the front-end.social public feed.
  • Jul 2, 2026, 7:26 AM

    I wonder though if great perceived performance requires full AOT compilation to native code, which IIUC basically requires static typing to be meaningful.

    Rust is probably not a good candidate for a would-be future VB; for all of the language's high-level abstractions, it has a famously steep learning curve that requires attention to low-level details (borrowing, lifetimes). So I guess we need something garbage-collected, or reference-counted like Swift.

    💬 4🔄 0⭐ 0

Replies

  • Jul 2, 2026, 7:29 AM

    To improve upon VB, we need an easy way to build an app as a self-contained artifact including any number of libraries, without requiring the app developer to manually manage the bundling of such libraries, and especially without requiring such libraries to be globally installed and registered (I have a horror story about that, from trying to redistribute a VB6-based thing and all of its ActiveX dependencies 24 years ago). Both Rust and Go absolutely nail this part.

    💬 1🔄 1⭐ 0
  • Jul 2, 2026, 10:03 AM

    @matt And I'd say that whatever it is, it can no longer just assume that everybody owns a computer, much less a Windows computer. That realistically means web, which also means servers, authentication systems and hosting costs.

    💬 0🔄 0⭐ 0
  • Jul 2, 2026, 7:35 AM

    @matt

    Objective-C provides late binding and dynamic typing with AOT compilation. 15 years ago, I wrote a compiler that implemented a Smalltalk dialect on the same object model. It had three execution modes!

    • An AST interpreter.
    • A JIT, which worked method at a time (so was fairly fast if you just edited a method and recompiled).
    • A ‘just too late’ compiler that, when a process exited, did an AOT compilation of all of the code and dumped it in a .so, so the next time the program started it got all of the last run’s code with a single dlopen call.

    Startup times were on the order of 200ms on a 1.2GHz Celeron M.

    This still gave a Smalltalk-like programming environment: you could open a class browser, replace methods, add instance variables to classes, and so on. While you were editing, things ran a bit slower (though I broke the JIT for a couple of months and used the AST interpreter without noticing) but they worked and were then fast the next run of the program.

    The goal was to integrate it with CoreObject, the persistent object store for Étoilé. With that, it would have been trivial to restart the program without losing state, so we could have done the same thing that Sudden Termination does on macOS: when none of the windows for a program are active, quietly restart it so that you pick up new object layout and so on.

    I mostly gave up the approach because, without something like CHERI, it’s hard to give end-user-programming environments access to C libraries without giving them myriad ways of crashing themselves. So I had to go and build CHERI before I could come back to solving the fun problem.

    💬 0🔄 2⭐ 0
  • Jul 2, 2026, 7:39 AM

    @matt My understanding is that Chez Scheme is among the fastest dynamic languages out there despite being purely AOT compiled. (More precisely, the compiler is usually bundled with the runtime, but it doesn't do any dynamic optimizations like a JVM/.NET/JS runtime does, and it can be omitted entirely if you want.) Having novice devs write Lisp would be, uh, controversial, but it could maybe be useful as a compilation target for a more conventional language?

    💬 0🔄 0⭐ 0
  • Jul 2, 2026, 7:41 AM

    @hatzka Well, Logo was famously successful with novices. I didn't realize its Lisp roots until quite recently.

    💬 0🔄 0⭐ 0
  • Jul 2, 2026, 1:12 PM

    @matt AutoHotkey compiles to executables that are small and start up fast and it's one of the worst programming languages I've ever worked with. If it was ever shown a hint of static typing, it wasn't looking at the time.

    💬 0🔄 0⭐ 0