Hacker News Reader

Comment by Cloudef | Hacker News Reader

The compile time in zig and nim is breath of fresh air, while rust seems similar spaghetti mess as c++

I know its super hip to hate on C++, but how is adding one keyword to make a function compiletime evaluated "spaghetti mess"? Because it's C++ and its hard?

constexpr should just try to evaluate stuff at compile time. In D, most sensible code works at compile time automatically, I don't think about it.

Having to mark everything as evaluatable at compile time is a stupid, stupid, decision that only C++ could think was a good idea.

It may seem stupid to you, because you only consider saving a few keystrokes. The keyword exist to guarantee stability/contract of compile-time-compatible APIs.

A change of an implementation detail in some leaf function (that happens to add a run-time dependency) should not accidentally break execution of another function elsewhere (possibly in a different downstream project) that happened to work as compile-time before that.

Note that compilers are still free to execute pure functions opportunistically at compile time, but it's just not guaranteed.

By the same logic it also means everything has to be marked as constexpr, i.e. you have to type everywhere, people who don't make their code less pleasant to use. The end game is that everything reasonable will be constexpr anyway, so there's no point.

One downside to implicit constexpr is its harder to know when an API intends it as a user and harder to enforce it works as an author. Seems like it could be easy to break compatibility.

At least users would notice at compile time when it breaks. With both implicit and explicit constexpr, authors who care could use the explicit form, and any implicit constexpr would be “use at your own risk”, but would still be guaranteed to work as long as you don’t upgrade the dependency.

That doesn't really happen in D because basically everything is "constexpr" unless it does something like inline ASM or unions with pointers in them

D should worry less how great language it is, focus on fixing long standing DIPs and compiler bugs, and actually have an ecosystem that makes it worthwhile using in the industries where C++ is the first choice.

Somehow it feels like languages are clashing here.

>D should worry less how great language it is,

You are just replying to some guy expressing an opinion on internet about how to do something better, and using D as example.

Mostly because unless I am going crazy, the comment was different when I posted my remark.

The HN guidelines state:

> Eschew flamebait. Avoid unrelated controversies and generic tangents.

You responded to

> Having to mark everything as evaluatable at compile time is a stupid, stupid, decision that only C++ could think was a good idea.

with

> D should worry less how great language it is, focus on fixing long standing DIPs and compiler bugs, and actually have an ecosystem that makes it worthwhile using in the industries where C++ is the first choice.

Definitely qualifies as both "flamebait" and "unrelated controversies".

The comment was edited, it was about the virtues of static if in D versus C++.

My comment?

If I recall correctly it had something about not doing if constexpr if being lesser than static if, and how greater it makes D over C++, overlooking the fact that since Andrei published its book that has mattered very little.

Now if I happened to reply to the wrong comment, sorry about that, and I should pay more attention before replying.

You have replied to the wrong comment.

> Having to mark everything as evaluatable at compile time is a stupid, stupid, decision that only C++ could think was a good idea.

What is stupid about it? It makes a lot of sense given how programming languages work.

What sense is that? I've worked on roughly 3 compilers with CTFE

I did some experimenting recently and was disappointed by how limited it is. It's a great solution for generics but things like file access don't work in const expressions and the errors are horribly opaque with no hint that it's not allowed.

I was hoping to be able to do things like generate type safe classes from a database schema but the current limitations mean you have to fall back to shell scripts, which zig-build also appears to not support.

Even in this thread everyone is code golfing fizzbuzz instead of something more practical.

It's funny how something like Zig's comptime of C++'s constexpr get 90% of the way to solving most compile time issues, but can't knock out that last 10%. Compile time database types sound like one of those cases. F# had a feature for compile time types via "type providers". It seemed _really_ cool at first, but in practice is was a bit fragile.

Though on the other hand I'm using compile Nim code to parse CMake files and provide static types for configuration values. It's super easy in Nim between macros and const's. Here's a ~170 lines of code where I'm compile time checking that my Nim code can compile time check against the current build configuration of Zephyr RTOS https://github.com/EmbeddedNim/nephyr/blob/main/src/zephyr_c...

Isn't that somewhat possible with @embedFile? Then you get the content of the file as a null terminated byte array / normal zig string. I would think you could do further comptime things to it after that no? I haven't tried it myself so maybe I am missing something.

I get that this differs from normal file io, but I could argue that is in line with Zig motto of clarity.

Also you would of course suddenly have to have the file content as part of your binary. Maybe you were hoping to be able to throw that away after you generated what you wanted...?

In the case the file was only intended to be there for a temporary step, I wanted that working before involving the database, which I believe also won't work because you can't do system calls at comptime.

Ultimately if you go down that path, whatever would be supplying the file could just as easily (or perhaps easier) be supplying zig code and you're still reliant on some sort of per-processor.

Reply on news.ycombinator.com