4 ms·

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

lionkor 5y ago
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?
- mhh__ 5y ago
  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.
  - pjmlp 5y ago
    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.
    - rat9988 5y ago
      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.
      - pjmlp 5y ago
        Mostly because unless I am going crazy, the comment was different when I posted my remark.
    - bachmeier 5y ago
      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".
      - pjmlp 5y ago
        The comment was edited, it was about the virtues of static if in D versus C++.
        mhh__ 5y ago
        My comment?
        pjmlp 5y ago
        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.
        mhh__ 5y ago
        You have replied to the wrong comment.
  - epage 5y ago
    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.
    - mhh__ 5y ago
      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
    - layer8 5y ago
      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.
  - deleted 5y ago
    [deleted]
  - pornel 5y ago
    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.
    - mhh__ 5y ago
      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.
  - anecd0te 5y ago
    > 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.
    - mhh__ 5y ago
      What sense is that? I've worked on roughly 3 compilers with CTFE
flukus 5y ago
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.
- elcritch 5y ago
  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/zconfs.nim https://github.com/EmbeddedNim/nephyr/blob/main/src/zephyr_c...
- olodus 5y ago
  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...?
  - flukus 5y ago
    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.

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?

mhh__ 5y ago
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.
- pjmlp 5y ago
  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.
  - rat9988 5y ago
    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.
    - pjmlp 5y ago
      Mostly because unless I am going crazy, the comment was different when I posted my remark.
  - bachmeier 5y ago
    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".
    - pjmlp 5y ago
      The comment was edited, it was about the virtues of static if in D versus C++.
      - mhh__ 5y ago
        My comment?
        pjmlp 5y ago
        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.
        mhh__ 5y ago
        You have replied to the wrong comment.
- epage 5y ago
  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.
  - mhh__ 5y ago
    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
  - layer8 5y ago
    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.
- deleted 5y ago
  [deleted]
- pornel 5y ago
  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.
  - mhh__ 5y ago
    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.
- anecd0te 5y ago
  > 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.
  - mhh__ 5y ago
    What sense is that? I've worked on roughly 3 compilers with CTFE

flukus 5y ago

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.

elcritch 5y ago
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/zconfs.nim https://github.com/EmbeddedNim/nephyr/blob/main/src/zephyr_c...
olodus 5y ago
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...?
- flukus 5y ago
  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.