[flohofwoe]

There's a massive Terra Incognita to explore between Rust on one side and Python on the other side (just to pick two extremes).

It's not "2 out of 3", it's a triangle where a language can pick a sweet spot anywhere within the triangle (and ideally, it's not a "sweet spot" either, but more like a "sweet area" where the programmer can pick an actual spot within that area defined by the language).

[pdimitar]

That sort of extreme flexibility simply does not exist. I mean it does but then you are firmly in the dynamic languages territory and you are forgoing any hope for close-to-the-metal performance.

[flohofwoe]

IMHO it does and its not restricted to dynamic languages (like JS or Python), look at this Zig function signature for instance (just an example from my current dabbling):

   fn setData(comptime pins: anytype, bus: anytype, data: u8) @TypeOf(bus)

In practice this looks and feels like dynamic typing, yet when looking at the compiler output it still resolves to optimal code (since it's "compile-time dynamic typing" not "run-time dynamic typing", but the difference in practice is surprisingly small).

[pdimitar]

Well you can make OCaml and Rust look like dynamic typing as well by omitting type signatures and squeezing the type inference engine as much as you can but I was under the impression that you have more asked about something that is very relaxed in terms of upfront requirements and be able to tighten it up later?

That's why I claimed that no such language exists.

[flohofwoe]

I was thinking more in terms of "language surface" but it didn't come across, C and Zig have a fairly small language surface (Zig a bit bigger than C), simple language primitives that can be combined quite freely and without much restrictions, but at the same time not carrying a lot of semantics the compiler could use to ensure safety (ignoring the "sloppiness" design warts of C though, like implicit type conversions, allowing accidential uninitialized data, or inverted defaults (mutable vs immutable) - these things are obvious problems but cannot be easily fixed in C or C++ because of backward compatibility requirements - they have been fixed in Zig though).

Rust is quite the opposite, more primitives that carry semantics (most of those in the stdlib though), a stronger but also more rigid type system, but those are pretty much needed for the compiler to guarantee safety.

The million dollar question is of course, can there be a more relaxed Rust with the same safety and performance guarantees, maybe by "squeezing the type inference engine" even more (and letting Rust look or somehow extract information across crate boundaries)? And do Rust programmers even see this as desirable, or are they mostly comfortable in their current sweet spot of the triangle?

[pdimitar]

I agree that your million dollar question is very good and relevant. Rust can definitely be improved -- async is sticking out as a sore thumb still and it requires a lot of ad-hoc knowledge that's not at all intuitive -- but I'd still venture to say it does pretty well in many areas.

Rust absolutely is not the end state of programming languages but I feel in many ways it's quite ahead than most of everything else. But yes, we still need something a tad better than it.

[SpaceNugget]

I'm not super familiar with Zig, but that appears to be the same as the rust function signature fn setData<P, B>(pins: P, bus: B, data: u8) -> B;

in rust, the P and B are resolved at compile time, not at runtime. If you wanted dynamic dispatch the types would be Box<dyn B>

[flohofwoe]

Yes, it's essentially the same, the comptime attribute on the pins arg is quite important though (in the function body that's not shown).