Yes. Functional world is not impervious to leaky abstractions.

I am personally of the opinion that, to be a good developer, you have to have mental model of what happens beneath. If you are programming in a high level language it is easy to try forget about the fact that your program runs on real hardware.

I know, because I work mostly on Java projects and trying to talk to Java developers about real hardware is useless.

I have an interview question where I ask "what prevents one process from dereferencing a pointer written out by another process on the same machine" and I get all sorts of funny answers and only 5-10% candidates even have beginning of understanding what is going on. Most don't know what virtual memory is or are surprised that two processes can resolve different values under same pointer.

> Most don't know what virtual memory is or are surprised that two processes can resolve different values under same pointer.

Yikes. How many of them have a degree in computer science?

A lot of them have although I must admit that CS graduates fare noticeably better.

What happens is they know what virtual memory is but can't connect the concepts. It is knowledge without understanding.

Probably not many of them, because it doesn't usually take a graduate to write Java. Especially if your experience with Java is also limited to tools like Spring. I think the question is kind of pointless unless your specifically hiring people to work on an application that needs that sort of thru-put. Most apps don't need it.

The funny thing is that in the old days, it is required to know how the machine worked - you coded assembly against physical memory.

But that was incredibly hard, and error prone (and comes with tonnes of limitations). The fact that today, it's very easily possible to write working programs without knowing any of the underlying details, is a marvel.

If i were to hire a truck driver, i wouldn't expect to have to ask him to understand how the truck itself worked (e.g., fuel injection when he presses the accelerator). He only needs to know how to operate the truck from the interface (steering wheel!). Why isn't this the same for a java programmer?

> But that was incredibly hard, and error prone (and comes with tonnes of limitations).

No, it wasn't. If it was incredible anything it was tedious. But nobody really expected anything super complex from you. Just look at the kinds of programs that were produced in 80s or 90s.

It would be incredibly hard today. Machines got very complex, operating systems got very complex.

But it wasn't so complex in 90s. I think I stopped writing assembly when I started using WINAPI because that was the point when assembly stopped being practical.

Sometimes I wonder how I would fare if I was 18yo again today and had to start in development and learn everything from scratch. I feel being able to learn everything as the technologies were evolving is a huge advantage I enjoy.

There’s a much vaster gulf between a truck driver and a truck engineer, vs a Java programmer and a programmer one layer below. Per your analogy, the truck driver is the program user here, not the program maintainer.

Rust for example does indeed apply lots of black compiler magic to really cut the cost of those abstractions (I've seen the output of complex iterator chains compiled down to exactly the same machine code you'd write without the abstractions). However man is it slow to compile. Pick your poison.

From what I understood the problem with Rust compilation time are more with LLVM and monomorphization of generics. I know that OCaml has a generics system that's kinda like Rust but doesn't monomorphize functions and is really really fast at compiling. OCaml also has its own backend.

> Pick your poison.

I pick Rust every time.

I have this concept of easy problems and hard problems. Every decision to choose technology is a compromise and comes with its own problems. It is your job to know whether these are easy or hard problems.

Compilation time is easy problem. Just put more hardware to it or modularize your application or schedule your coffee breaks correctly.

Building reliable abstractions to prevent hard to debug problems is hard problem. Building a large, complex, reliable application in ANSI C is hard problem.

I try imagine, what would you rather spend your time on: coffee breaks or debugging complex bugs?

> just put more hardware to it or modularize your application

This is not that easy as it seems.

Rust compilation is not embarrassingly parallel as a lot of what's going on seems to be deferred at the link stage.

Modules inside a crate can't be compiled in parallel because of some reason I don't truly understand, please educate me.

Crates can be truly compiled in parallel, crating projects with hundreds of crates is quite a pain for other reasons.

The result is that a change single line of code in the project I'm working in can take more than 2 minutes on my last gen MacBook pro.

I have a M1 Mac mini where the compilation is twice as fast but I don't have enough RAM there and I'll have a hard time to convince my manager to make an exemption to my companies laptop refresher policies "because of rust".

If I have to take a coffee break every time I need to wait for an incremental compilation my heart would explode.

My current solution is:

1. Multitask. Do somethings else while I'm waiting.

2. Split the code that I'm iterating on in a new project. With minimal dependencies and copy the code back in the main project when I'm done (or just import it as a crate if it makes sense)

Both options suck and I wish they weren't necessary. Please let me know what else could I do. What hardware should I buy etc

(I already use zld on Mac and use minimal debug symbols, iirc debug=1)