D has has compile time function evaluation for 15 or 16 years now. It doesn't have a special keyword, either. It's simple - everywhere the grammar has a const-expression, then compile time function evaluation is in play.
Could it be because some of it, say, places a delegate, bound to a closure, into an immutable struct within a child thread's run function, and passes that to another thread via a send to be called?
This means, if a C library is available, D can use it.
(There are some exceptions. While ImportC will handle C preprocessor metaprogramming just fine, those metaprogramming macros won't be available to the D code, other than simple #define manifest constant declarations.)
Can't agree more. Such a powerful language but with an absolute meager ecosystem! No dogfooding.
GC and crashes are pretty common on long running high performance apps. They should just build things from the ground up using betterC.
So when I see comments like this that say "D also has X feature", I'm curious about why D didn't take off but Zig (likely) will.
In Zig's near category, there are other languages like Odin, Jai, Vlang, Rust, etc... For example, by the time Zig reaches 1.0, Jai (which is in Beta) might be publicly released, others languages might have added some "killer" features, and/or others in development might have also reached production quality.
Zig has quite a long way to go, and if anything may never achieve the popularity or widespread usage of D. Examples of the difficulty of programming languages rising through the ranks, is Nim and Crystal. Both Nim (2008) after 14 years and Crystal (2014), have not even made it into the top 50.
And no Vlang is not a programming language, it's a scam and should be treated as one.
Stop deluding yourself. If we take out TIOBE, and use the IEEE's Top Programming Languages of 2022 (https://spectrum.ieee.org/top-programming-languages-2022), D is still recognized (even higher than the 30s) while Zig, Nim, or Crystal do not even make their chart. That's the reality. The point is, it's hard to climb the charts, and not to underestimate the positions of established languages or that they will suddenly be abandoned.
> Vlang...
To begin with, you are a known troll (with possibly multiple troll accounts at HN) that has spent over an year engaging in slander, lies, and flames about the language almost any time it's mentioned.
Looks like you are the creator or involved with some other language that can't get as much support and popularity, and have taken to being underhanded. It would be advisable for you to stop being obsessed with Vlang. How many years of your life will you waste on such childish antics? You would be better off focusing on making your programming language better, if it's not already too late and its a failure.
As for pushing this bold face lie that the language is a "scam", that's both ludicrous and easily proven false. Vlang has many hundreds of code examples and projects. Easily found at:
1) Vlang examples on GitHub (https://github.com/vlang/V/tree/master/examples).
2) Vlang at Rosetta Code (https://rosettacode.org/wiki/Category:Vlang).
3) Awesome Vlang at GitHub (https://github.com/vlang/awesome-v).
The "scam" is you tricking yourself into thinking that your troll tactics are working. Instead, your continual and unnecessary slander is making what you are even more obvious.
int i = f(3); // evaluate at run time
enum i = f(3); // evaluate at compile time
enum res = toggle_gpio(FRONT_LED_2);
Then, suppose we have all these requirements
- We want a separate compilation model where the code which is calling f(3) at either compile or run time knows nothing about how f is defined, only how it's declared.
- We want not to include the compiled image of f in the target program, if if is only called at compile time, only if at least one call to it somewhere in the program is staged to run-time.
- We want to make sure that if f is called at compile time, nobody can change its definition to accidentally call for run-time semantics like toggle_gpio(FRONT_LED_2).
and that's how we probably arrive at a declarative mechanism like constexpr that goes on the function, rather than trying to orchestrate thing remotely/indirectly by placing a call to the function into a compile-time context.
Not including functions never called for runtime execution in the runtime is a normal compiler optimization. No user input is necessary.
If the function's semantics change so it is no longer runnable at compile time, the compiler will let you know when you try it. If you want to force the detection, just call it at compile time with dummy declaration.
> that's how we probably arrive at a declarative mechanism like constexpr that goes on the function, rather than trying to orchestrate thing remotely/indirectly by placing a call to the function into a compile-time context.
This issue is raised now and then, and in 16 years of CTFE in D it has never ever been reported as causing an actual problem.
Great we have many good languages to choose from