Or a language like Go, C or Nim that can compile tens of thousands of lines of code in a few seconds.

You forgot about D, where you can basically bind ctrl+s to rdmd in your favourite IDE and enjoy scripting language akin experience.

D is sadly very underrated.

My day job is in C and compile time is 30 minutes. It really depends what you're working on.

Does it take that long for an incremental build?

I've used Nim just a bit on Windows/MingW (I'm from python world). The very short program I made (about 200 lines, mostly math stuff, no framework imports) compiles in 2-3 seconds. It's already too long for me to iterate (it's not a rant against Nim, it's just that it's too long for my way of working; the language is nice and gives good results). Also note that Nim compiles fast, it's the compile-to-native compilation step that takes 90% of the time.

Or OCaml, Java, C#, F#, Eiffel, Delphi,...

I've worked in a C# code base where compiling the solution took 40 minutes.

Wow, one of our solutions is nearly 100 projects (legacy) and the compile time for the whole solution is sub-5 minutes. I'd love to see what kind of solution would take 40 minutes to compile! (or maybe I don't :)).

That being said, C# is clever enough to only need to recompile the assemblies affected by your code change, so often you can get away with 10 second compile times even for large solutions.

IIRC our solution was around 450 projects. Visual Studio just woudn't open the whole solution.

So you had to work in individual projects at a time, slowly going through and changing stuff project by project.

VS wouldn't even build it either, really. YOu had to build via batch file that did various ms build magic. I would make changes, set of a build and go to lunch, then come back and fix the errors.

Once you checked the code into source control it would trigger a build which would sometimes take upwards of an hour :( I hated that code base.

It got even worse when they added Coded UI tests. Wait an hour for a build and then a random Coded UI test would fail and the advice from the people who wrote the Coded UI was "just run another build!", yeah, flakey tests on a code bases that tests an hour to run...

Now imagine with the current Rust compile times, compiling those 450 projects from scratch, I bet the 40m would turn into hours.

Just googling “f# compile times” would beg to differ.

Apparently you didn't bother to read the 3 answers that come up.

Only one of them says anything and it an empty statement like

> F#'s compile times also seem to err on the long side but not very much so, my impression goes.

However it is quite easy to validate write the same algorithm in F# and Rust and then compare.

Ah but Rust is AOT compiled, easy, use NGEN, .NET Native, or Mono AOT for the F# compile time measurements.

Apparently you assume that everyone’s google results are identical.

I've had a reviewer in a (scientific) journal tell me some paper is relevant, and thus I need to cite it, because it "appears on their top google results".

People should be educated on the huge bias introduced by personalized services like google.

If that’s the case, then there’s no point in making any claims about what “just googling ‘f# compile times’ ” will reveal.

You mean a REPL, or an interpreted language?

I'd love a REPL that could somehow load the state of my entire app so I could test stuff out, but I've never found a language that could do that and also had reasonable type safety guarantees.

With Jetbrains IDEs (IntelliJ, Webstorm, CLion) you can run a "sketch" that can "see" any module in your project. I use that a lot in Java/Groovy/Kotlin/Rust and it feels much superior to a REPL because I can write not just one-liners, but larger amounts of code, with all the features of the IDE like auto-completion, inline docs, syntax checking etc.

A test suite facility can also be used like this. And Rust adds any "examples" you write in the code (with proper doc formatting) to the test suite, as mentioned elsewhere.

A test suite has a different use case... REPLs/Sketches are useful for exploration... both of your own design and of libraries you're using. Tests can be used for this as well, but it's not as convenient when you're very "early" in your exploration or have no code yet to test at all.

Some of the best solutions to that world right now seem to be things like lisps with dynamic typing added. You get a great set of repl support, but you can also build components and systems into easy wrapper scripts to load them as needed.

I assume you mean static typing enabled. Because lisps are already dynamically typed to begin with.

Thanks, I actually meant gradually typed systems, like rust typed or closure with heavy spec usage.

As a spec user in production, I must say it's very nice usability-wise and can help alleviate most of the issues coming from a lack of a type system.

But god it's slow... Some static analysis support would also be hugely appreciated. Not being able to check everything doesn't meen you shouldn't attempt to check something! Many specs are type predicates anyway.

Clojure has a java type system which can be partially enforced statically with clj-kondo

Clojure spec is great at system boundaries but it's hard to describe it is a type system, it's a predicate system it can define very arbitrary constraints mostly at runtime

I think you mean Clojure. Closure is something different.

What a terrible day for autocorrect, thank you.

Visual Studio can give you a REPL experience for a number of languages (notably C#, of course) using its Immediate and Interactive windows.

Have you try Haskell? The most used compiler, GHC, shipped with it's own REPL and it's quite good. Something I missed when coding in Rust.