I wonder if quote of the week can be used to bust some myth.
But what's the point of a const function then?
It makes code like this compile:
const FOO: i32 = my_const_fn(13);
That code is rejected unless my_const_fn is a const fn .
That is the only effect const has on fn . And AFAIK we never say anything else anywhere in the docs, so I do not comprehend where all these extra assumptions come from that you have been making. I'd really like to know as I'd like to avoid people making such false assumptions.
I always thought that const means all of these happens in compile time and none of it goes to runtime except those called in non-const places.
Code in const "places" (usually called const contexts) must run at compiletime. So this statement is true but I don't think it means what you think it means. In particular, format is impossible to use in const contexts:
const FOO: String = format!("abc"); // does not compile
Since format! can only be used in non-const-contexts, that means it never happens at compiletime. Or rather, it is never guaranteed to happen at compiletime -- optimizations can do whatever they want, but there's no guarantee they ever happen.
You want to be looking into languages that tell you not "programming is so easy with me" but "programming is actually fiendishly hard but I'm going to try my best to help you get through it in one piece."
Rust has a curse (it has many, but this one is critical): inefficient code is generally visible. Experienced developers hate to notice that their code is inefficient. They will recoil at seeing Arc<RefCell<T>> , but won't bat an eye at using Python.
Historically, C has been the best fit for these applications just because it so lean: by providing essentially nothing other than the portable assembler that is the language itself, it avoids the implicit assumptions (and girth) of a complicated runtime. But the nothing that C provides reflects history more than minimalism; it is not an elegant nothing, but rather an ill-considered nothing