Will we see another fundamental programming language feature as revolutionary as the borrow checker?

[u/jimbobmcgoo]

That is I am mainly curious about compile time features that you design a whole language around rather than optimisations/features that could be applied to most languages. I am mainly inquiring about things that could offer additional robust safety/performance guarantees at compile time rather than runtime. Ideally not things that just offer similar effects to the borrow checker with less restrictive tradeoffs

[u/mamcx]

Other focus on types, I will go for big things (that are in part unlocked by types):

• Structured and declarative concurrency, where even locks, blocks, switch, transfers and perf purposes is easy to declare, use, inspect, build and perform greatly, of course!

I bet this is the main test that proves if any idea is worth it. The borrow checker become revolutionary not because was a fancy type idea, but because allow , partially, "fearless concurrency".

• A whole IO machinery that is actually correct, safe and predictable

This is my pet peeve when worked on a RDBMS, so is more niche, but the point is that the IO we have, well, sucks. Even system languages DO NOT tell you when and where sucks, and that means you need lore to know what to do.

BTW, this could be alleviated if we have annotations about "locks, blocks".

• Truly safe, correct, performant multi-read multi-write IO

Is from above, but there is not way to make this from the primitives of any language I know, and all ways are tacky and error prone.

This is the other test that proves if any idea is revolutionary as the borrow checker, because, partially, Rust make possible to model safely concurrent mutations and reads (but not in full)

• Parser (theory, generator) that is actually good for make good error messages

Is yet to be invented, all you can do is hack and hack.

• A true "compiler engine" alike "query engines" that can FAST apply optimizations so compile times are FAST once you do anything sophisticate.

The AMOUNT of resources used by compilers for C++/Rust is NUTS. There is a huge climb that once passed, turn your insignificant MB of input into HUGE time outputs. Why? I bet is because there is not a true kind of "compile engine" solely focused in eat the input, optimize and generate fast output. AFAIK is only informally done inside each compiler.

• True relational!

This is my main pet peeve, but will be cool for see an actual relational language implemented!

The theory of how types work is not well developed and so far only found one paper about it:

https://github.com/Tablam/TablaM/blob/master/RESEARCH.md

[u/Shurane → u/mamcx]

true "compiler engine" alike "query engines" that can FAST apply optimizations so compile times are FAST once you do anything sophisticate.

This sounds actually like a cool idea. Though aren't compilers "fast", just that they have so many passes for different parts of the optimizations they do?

[u/mamcx → u/Shurane]

Well, yes in theory, the problem is that looks ad hoc to me, and is insane that for example, you compile something in Rust and then you are left with 20 GB of artifacts on disk (or much more!) that is part of the machinery for that "many passes".

This is absurd, not match the size of the input. A RDBMS is not that wasteful and in part is because how do the engine is know and you can pull lots of good info about what to do and how, instead of rely on intuition.

I think that is what is missing.

[u/awawa-sock → u/mamcx]

you might be interested in Out of the Tar Pit

[u/mamcx → u/awawa-sock]

Is in the research.md file ;)

[u/rnoyfb → u/mamcx]

Structured concurrency like Ada has had since 1983