3 ms·

A fast hot code swap of a module is a more important feature in my opinion, but it is somehow even harder to find these days than a fast compilation speed langu

A fast hot code swap of a module is a more important feature in my opinion, but it is somehow even harder to find these days than a fast compilation speed language. But ideally I want both.

Weebs 2y ago
This is a direction I've been pushing in partly because I'm using a significantly slower type inference algorithm in my language. I'm hoping with that and focusing on separate compilation I'll be able to keep the fancy inference without sacrificing the UX too much
- DanielHB 2y ago
  When I used to program Java I absolutely loved hot code swap and was always amazed how little people even knew it was possible. If you have a massive codebase no matter how fast your compiler is, re-compiling is going to be slow. But hot code swap is even better in that you can keep any state around without having to set it up all over again. In Java I could change a method implementation with the program running and as long as I didn't touch my class state it would just work. Re-compilation was slow, but hot code swap was _fast_ and I maybe did a recompile 3-5 times per day total.
  - mike_hearn 2y ago
    Bear in mind that the underlying protocol used to request hot swap on Java is a lot more expressive than the standard HotSpot implementation is. If you use the Jetbrains Runtime (a fork of OpenJDK) or the GraalVM "Espresso" VM (a.k.a. Java on Truffle) then you can do way more hotswapping than you'd be able to normally. Espresso goes further and doesn't only allow hot swapping but lets you write plugins that react to hot swaps of code: https://www.graalvm.org/latest/reference-manual/java-on-truffle/hotswap/ https://www.graalvm.org/latest/reference-manual/java-on-truf... If you use the Micronaut web framework then it will selectively re-initialize your app in response to hot swaps that need it. Pretty advanced stuff.
    - DanielHB 2y ago
      That is pretty neat, I haven't done serious Java development in ~10 years but I do vaguely remember hot swapping would eventually cause out of memory errors. I was using standard OpenJDK 6 and 7 at the time.
kaba0 2y ago
Funnily enough java has both insanely fast compile times, and hot swapping, while being more expressive than Go.
- DanielHB 2y ago
  I wouldn't call the compile times super fast, but they were not that bad. I brought up the hot code swap thing because I did use it a lot when I was doing Java development.
  - kaba0 2y ago
    The compile itself is very fast, but the build tools tend to think a bit when not hot/do some additional stuff besides building. But the actual time spent in `javac` is very short (partially because it only outputs very high level byte code)
    - DanielHB 2y ago
      Seems reasonable, maybe it was just my project but it took around 3 minutes to recompile + run. I guess actually starting the application took a decent time as well. To be fair it was 10+ years ago with a pretty crappy laptop even for the time. Hot code swap was super fast though!
- throwaway894345 2y ago
  Java's compile times are "insanely fast" because it's not actually compiling to native code, it's compiling to JVM byte code which is actually compiled at runtime. And it is one of the rare languages that manages to be more expressive than Go while also being quite a lot less ergonomic. (:
  - kaba0 2y ago
    Go is significantly more verbose and just recently can one implement a goddamn map without hardcoding it in the compiler. Besides all the beautiful if err unreadable “error handling” that makes it all too easy to silently ignore errors, and design mistakes like defer being function scoped, it’s hardly something I would call ergonomic.
kstenerud 2y ago
I'd really like to see a careful compiler like Rust have a "fast and loose" mode for the development loop, whereby I swear on my mother's grave that I won't break any rules, and the compiler in turn stops making expensive checks. This would of course be for development only, not for releasing.

A fast hot code swap of a module is a more important feature in my opinion, but it is somehow even harder to find these days than a fast compilation speed language. But ideally I want both.

Weebs 2y ago

This is a direction I've been pushing in partly because I'm using a significantly slower type inference algorithm in my language. I'm hoping with that and focusing on separate compilation I'll be able to keep the fancy inference without sacrificing the UX too much

DanielHB 2y ago
When I used to program Java I absolutely loved hot code swap and was always amazed how little people even knew it was possible. If you have a massive codebase no matter how fast your compiler is, re-compiling is going to be slow. But hot code swap is even better in that you can keep any state around without having to set it up all over again. In Java I could change a method implementation with the program running and as long as I didn't touch my class state it would just work. Re-compilation was slow, but hot code swap was _fast_ and I maybe did a recompile 3-5 times per day total.
- mike_hearn 2y ago
  Bear in mind that the underlying protocol used to request hot swap on Java is a lot more expressive than the standard HotSpot implementation is. If you use the Jetbrains Runtime (a fork of OpenJDK) or the GraalVM "Espresso" VM (a.k.a. Java on Truffle) then you can do way more hotswapping than you'd be able to normally. Espresso goes further and doesn't only allow hot swapping but lets you write plugins that react to hot swaps of code: https://www.graalvm.org/latest/reference-manual/java-on-truffle/hotswap/ https://www.graalvm.org/latest/reference-manual/java-on-truf... If you use the Micronaut web framework then it will selectively re-initialize your app in response to hot swaps that need it. Pretty advanced stuff.
  - DanielHB 2y ago
    That is pretty neat, I haven't done serious Java development in ~10 years but I do vaguely remember hot swapping would eventually cause out of memory errors. I was using standard OpenJDK 6 and 7 at the time.

kaba0 2y ago

Funnily enough java has both insanely fast compile times, and hot swapping, while being more expressive than Go.

DanielHB 2y ago
I wouldn't call the compile times super fast, but they were not that bad. I brought up the hot code swap thing because I did use it a lot when I was doing Java development.
- kaba0 2y ago
  The compile itself is very fast, but the build tools tend to think a bit when not hot/do some additional stuff besides building. But the actual time spent in `javac` is very short (partially because it only outputs very high level byte code)
  - DanielHB 2y ago
    Seems reasonable, maybe it was just my project but it took around 3 minutes to recompile + run. I guess actually starting the application took a decent time as well. To be fair it was 10+ years ago with a pretty crappy laptop even for the time. Hot code swap was super fast though!
throwaway894345 2y ago
Java's compile times are "insanely fast" because it's not actually compiling to native code, it's compiling to JVM byte code which is actually compiled at runtime. And it is one of the rare languages that manages to be more expressive than Go while also being quite a lot less ergonomic. (:
- kaba0 2y ago
  Go is significantly more verbose and just recently can one implement a goddamn map without hardcoding it in the compiler. Besides all the beautiful if err unreadable “error handling” that makes it all too easy to silently ignore errors, and design mistakes like defer being function scoped, it’s hardly something I would call ergonomic.

kstenerud 2y ago

I'd really like to see a careful compiler like Rust have a "fast and loose" mode for the development loop, whereby I swear on my mother's grave that I won't break any rules, and the compiler in turn stops making expensive checks. This would of course be for development only, not for releasing.