[throwaway894345]

I think most people haven't used many languages that prioritize compilation speed (at least for native languages) and maybe don't appreciate how much it can help to have fast feedback loops. At least that's the feeling I get when I watch the debates about whether Go should add a bunch more static analysis or not--people argue like compilation speed doesn't matter at all, while _actually using Go_ has convinced me that a fast feedback loop is enormously valuable (although maybe I just have an attention disorder and everyone else can hold their focus for several minutes without clicking into HN, which is how I got here).

[DanielHB]

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.

[kstenerud]

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.

[kaba0]

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

[throwaway894345]

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]

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.

[throwaway894345]

I'm not claiming it's ergonomic (I don't think it is especially ergonomic, as I indicated in my previous comment), I'm claiming it's more ergonomic than Java. That said, it's always struck me as silly that people associate ergonomics with character counts. I don't think code golf is especially ergonomic either.

[DanielHB]

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]

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]

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!

[Weebs]

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]

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]

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-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]

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.

[sans-seraph]

In the case of Rust the fast feedback loop is facilitated by the `cargo check` command which halts compilation after typechecking. Unlike in Swift the typechecking phase in Rust is not a significant contributor to compilation times and so skipping code generation, optimization, and linking is sufficient for subsecond feedback loops.

[throwaway894345]

I mean, you still need to run code at the end of the day. Yeah, the type checker will update your IDE quickly enough, but you still need to compile and link at least a debug build in order to meaningfully qualify as a feedback loop IMHO.

[sans-seraph]

This was my initial mindset as someone whose background lies in untyped languages, but after time with Rust I no longer feel that way. My feeling now is that seeing a Rust codebase typecheck gives me more confidence than seeing a Python or Javascript codebase pass a test suite. Naturally I am still an advocate for extensive test suites but for my Rust code I only run tests before merging, not as a continuous part of development.

To give an example, in the past week I have ported over a thousand lines of C code to a successor written in Rust. During development compilation errors were relatively frequent, such as size mismatches, type mismatches, lifetime errors, etc. I then created a C-compatible interface and plugged it into our existing product in order to verify it using our extensive integration test suite, which takes over 30 minutes to run. It worked the first time. In order to ensure that I had not done something wrong, I was forced to insert intentional crashes in order to convince myself that my code was actually being used. Running that test suite on every individual change would not have yielded a benefit.

[throwaway894345]

> This was my initial mindset as someone whose background lies in untyped languages

Yes, I understand and agree regarding Rust vs dynamic languages, but to be clear my remark was already assuming type checking. I still think you need a full iteration loop even if a type checker gets you a long ways relative to a dynamic language.

[pjmlp]

While others have, more expressive languages than Go, that compiled blazingly fast in 1990's hardware, with more features than Go will ever get.

[throwaway894345]

I've never understood why people think "more features" is a flex. "Faster compile times" isn't even the primary benefit of fewer features, it's just gravy. More features, even with fast compile times, is a failure (which is probably why most of those "more expressive languages" are no longer with us unless one includes the JIT languages and--disingenuously--only measure the AOT compilation).

EDIT: wow, a downvote within literally 2 seconds of posting!

[pjmlp]

Those languages are definitely with us,

https://dlang.org/

https://www.embarcadero.com/products/delphi

https://www.mikroe.com/mikropascal-arm

https://www.eiffel.com/

https://www.ptc.com/en/products/developer-tools/objectada

[throwaway894345]

Do those languages command even a single percentage of marketshare combined?