Live data from Hacker News

C Macro Reflection in Zig

jstrieb.github.io

31–40 of 139 posts

Re: C Macro Reflection in Zig

#31

I really want to like zig, but I've just had some annoying problems with it, most of which I think are just a result of it not being in 1.0 yet. For example, the recommended way to start a project, with `zig init`, has a load of code that I really don't need when I just want a bare project to get started. I only recently found out that you can just `zig build-exe filename.zig` and skip the whole init part. Also I've…

Honestly same. I think it has the potential to be a great language and I'll definitely have a look at 1.0. Right now it's more for the people who are fine living on the bleeding edge.

Nothing wrong with that, imo. It's hard to evolve a language without having the ability to make breaking changes. They're doing the right things, generally making the right calls, and taking their time building instead of rushing.

Re: C Macro Reflection in Zig

#32
post #13

Earlier quoted context omitted.

zls should generally work out of the box but I don't use vscode, so your mileage may vary. Make sure your zls and zig versions match. zig build-exe, zig run can be fine for small things, but when you want to start importing modules or do something more fancy, build.zig is nice to have.

According to the extension, ZLS is optional, but according to some zig docs I found, its part of the extension. I may have misread, I'll try this stuff again sometime

As with all VSCode language extensions, they will try to download and manage ZLS for you. That's ok if it's done well, but they probably have some ways to go still.

I just prefer using Zig on emacs with the built-in eglot LSP client. You just tell it where you installed ZLS (and it won't do magic to get it for you) and off you go. It's the same level of support as with VS Code. If you're not new to emacs, maybe consider that (otherwise emacs may be too much of a rabbit hole :)).

Re: C Macro Reflection in Zig

#33
post #30

Earlier quoted context omitted.

While I understand the reasoning, I think this is one of the most disappointing decisions by the Zig team. One of the main reasons I took Zig seriously was their C interop story—as someone who loves C and dislikes almost every implementation of C interop and FFI I’ve used in other languages (Rust is a notable exception to this), I was pretty much sold on Zig when I was able to, in a total of I respect Andrew a lot (I…

> as someone who loves C and dislikes almost every implementation of C interop and FFI I’ve used in other languages (Rust is a notable exception to this), Have you tried D? It can import C files as if they were D modules: https://dlang.org/spec/importc.html Basically, if there's a `hello.c` file next to your D file, you simply import it with: import hello And use the functions it provides. You can also import only a…

> Have you tried D?

I tried D years ago (at least 5 years ago, I think), but I don’t remember experimenting with the C interop.

Your explanation sounds intriguing though. And a couple pretty smart folks I respect have talked about D too. So thanks for bringing it up. I’m going to make some time to experiment with it again some time soon.

> Is that as good as Rust?

Franky, although I don’t have firsthand experience with D, your explanation and example make the D C interop experience sound actually better than Rust’s. It seems more similar to Zig.

Re: C Macro Reflection in Zig

#34
post #4

Clang's preprocessor is actually not implemented as a separate compilation pre-pass, it's essentially a part of the lexer and I would be willing to bet that gcc uses a similar scheme. So there is nothing technically impossible about having the access to macro names as a compiler-specific extension, it's just that there is no much demand for it.

Clang prints out things about macro instantiations on the semantic error reporting paths. That probably means it has all the macro information available already. It's not probably reflected to the language because C++ fears reflection in general and hates macros in particular.

> C++ fears reflection and hates macros

But only wicked gods would banish us from paradise

Why do they fear our power?

Because evil is what they are.

Re: C Macro Reflection in Zig

#35

I really want to like zig, but I've just had some annoying problems with it, most of which I think are just a result of it not being in 1.0 yet. For example, the recommended way to start a project, with `zig init`, has a load of code that I really don't need when I just want a bare project to get started. I only recently found out that you can just `zig build-exe filename.zig` and skip the whole init part. Also I've…

I have the same issue. It's hard to say if the tooling is working but incomplete, or if the tooling doesn't work for some reason. I can get syntax highlighting to work, but basic variable autocomplete doesn't, so I'm guessing the language server ran into some kind of issue.

I really want to get started with Zig but I don't want to go back to the age of nano/edit.com for learning a new language. Zig is complex enough already.

Re: C Macro Reflection in Zig

#36
post #32

Earlier quoted context omitted.

According to the extension, ZLS is optional, but according to some zig docs I found, its part of the extension. I may have misread, I'll try this stuff again sometime

As with all VSCode language extensions, they will try to download and manage ZLS for you. That's ok if it's done well, but they probably have some ways to go still. I just prefer using Zig on emacs with the built-in eglot LSP client. You just tell it where you installed ZLS (and it won't do magic to get it for you) and off you go. It's the same level of support as with VS Code. If you're not new to emacs, maybe consi…

My terminal editor of choice is nano :P

Re: C Macro Reflection in Zig

#37

I really want to like zig, but I've just had some annoying problems with it, most of which I think are just a result of it not being in 1.0 yet. For example, the recommended way to start a project, with `zig init`, has a load of code that I really don't need when I just want a bare project to get started. I only recently found out that you can just `zig build-exe filename.zig` and skip the whole init part. Also I've…

Tbf, when coming from the C/C++ ecosystem, these types of problems are 'just another Tuesday' (especially for cross-platform projects and the official VSCode C/C++ extension).

This is part of the reason why I don't use VSCode for C(++). Jetbrains Clion seems to be the best IDE for those languages, with Visual Studio (the full fat one, costing a grand, as the free version lacks a bunch of features) as a close second, depending on what platform you're developing for.

VSCode is great when it works, but in cases like these it quickly becomes obvious that it's a hodge-podge of tools glued together via extensions and command lines rather than a purpose-built IDE.

Re: C Macro Reflection in Zig

#38
post #30

Earlier quoted context omitted.

> as someone who loves C and dislikes almost every implementation of C interop and FFI I’ve used in other languages (Rust is a notable exception to this), Have you tried D? It can import C files as if they were D modules: https://dlang.org/spec/importc.html Basically, if there's a `hello.c` file next to your D file, you simply import it with: import hello And use the functions it provides. You can also import only a…

> Have you tried D? I tried D years ago (at least 5 years ago, I think), but I don’t remember experimenting with the C interop. Your explanation sounds intriguing though. And a couple pretty smart folks I respect have talked about D too. So thanks for bringing it up. I’m going to make some time to experiment with it again some time soon. > Is that as good as Rust? Franky, although I don’t have firsthand experience wi…

I think the feature that allows importing c, called "importC", is newer than 5 years. I think they may have "copied" it from Zig :D they definitely are trying to not "fall behind" Zig and keep making the language better. With DMD, you can cross compile just as with Zig, but only to object files as the linker is not multi-platform... so I am experimenting with using Zig's linker to "finish" the job. Unfortunately, Zig is not being able to link Phobos, the D stdlib, for reasons I don't understand yet.

Re: C Macro Reflection in Zig

#39
post #21

Earlier quoted context omitted.

While I understand the reasoning, I think this is one of the most disappointing decisions by the Zig team. One of the main reasons I took Zig seriously was their C interop story—as someone who loves C and dislikes almost every implementation of C interop and FFI I’ve used in other languages (Rust is a notable exception to this), I was pretty much sold on Zig when I was able to, in a total of I respect Andrew a lot (I…

How I see is that the only thing that changes is that you can't do @importC anymore. You'll instead do something in build.zig that produces a module which you can then addImport("my-c-lib", generated_module); which you then @import("my-c-lib"); in your zig code as you would with @cImport. This does not seem bad in paper. One thing that does worsen with this is that in @cImport you could also comptime define preproces…

Having worked with Rust I would say that is bad. @cImport is way better than the C introp in Rust.
Post reply on HN