Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig cc: A drop-in replacement for GCC/Clang (2020)

andrewkelley.me

Post reply on HN
Print view View original

121–126 of 126 posts

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#121

Post by jcalvinowens »

jedisct1 wrote: post #47
jcalvinowens wrote: post #37

Earlier quoted context omitted.

Have you tried ASAN? If you like valgrind, you will be in love with ASAN, it's really surpassed it at this point IMHO.

Be careful with ASAN on cryptographic code, though. It can introduce side channels.

That's definitely a good point, and worth thinking about. But most people don't go to the trouble to rebuild dependencies like openssl. Unless you're actually implementing crypto, it seems unlikely you'd expose anything, although you do have to consider the possibility that a crypto library could call an instrumented function which could leak state.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#122

Post by jcalvinowens »

klyrs wrote: post #45
jcalvinowens wrote: post #37

Earlier quoted context omitted.

Have you tried ASAN? If you like valgrind, you will be in love with ASAN, it's really surpassed it at this point IMHO.

I have tried ASAN, and I'm fully prepared to love it, but last time I tried to use it with Cython, it was pretty fidgety to configure my build system to get it running -- unlike valgrind, you need to understand how programs are compiled and linked. If you want ASAN to see into the Python that's calling/consuming your Cython, you need to build a custom Python. It's certainly a sharper tool, but valgrind has the learni…

Ugh yeah, it just doesn't work well with Python. A friend of mine went down the same rabbit hole trying to debug a C extensions... it's a shame.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#123

Post by klyrs »

jcalvinowens wrote: post #122
klyrs wrote: post #45

Earlier quoted context omitted.

I have tried ASAN, and I'm fully prepared to love it, but last time I tried to use it with Cython, it was pretty fidgety to configure my build system to get it running -- unlike valgrind, you need to understand how programs are compiled and linked. If you want ASAN to see into the Python that's calling/consuming your Cython, you need to build a custom Python. It's certainly a sharper tool, but valgrind has the learni…

Ugh yeah, it just doesn't work well with Python. A friend of mine went down the same rabbit hole trying to debug a C extensions... it's a shame.

Yeah, I'll be honest... I know how to build Python and all that, but I stopped dead once I realized that it was a requirement. Much faster to just valgrind/[print-]debug an issue than set up all that tooling. Making all that happen is on a distant back-burner, as it will take about 10+ uses to pay off and segfaults are typically rare and shallow for me.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#124

Post by [deleted] »

burntsushi wrote: post #117
pcwalton wrote: post #110

Earlier quoted context omitted.

Do you think that Rust would be a better language if everything had to be compiled from source?

Obviously I don't. And that's totally consistent with learning from Zig about how to improve the cross compilation story for Rust. (Trivially: compile some things from source, but not other things.) I'm honestly pretty disappointed at your participation in this thread. It seems like you're going out of your way to assume the worst possible interpretation of what folks are saying.

[deleted]

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#125

Post by littlestymaar »

steveklabnik wrote: post #100
pcwalton wrote: post #67

Earlier quoted context omitted.

I don't. We could approximate it by shipping all targets by default, but few really want that and the few who do can just install those targets with rustup.

Sure, like many things, I bet you could pick three or four and get 90% of the default coverage. That still helps 90% of the users. I also think you're really missing out on the "compile C code easily too" thing. That isn't very pleasant at all in Rust today. (Finally, one reason it’s so big is that we ship binaries. This ships source. std-aware cargo could really help here.)

> I also think you're really missing out on the "compile C code easily too" thing. That isn't very pleasant at all in Rust today.

So much this. Cross compiling pure Rust code is really easy today but as soon as you have a C dependency in your dep tree, you're gonna have a bad time.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#126

Post by jhgb »

pcwalton wrote: post #110
burntsushi wrote: post #97

Earlier quoted context omitted.

The difference is really not just one command. I suggest you go out and actually try Zig cross compilation or at least read more about it. Andrew Kelley has written a lot about it. The work impressed me so much that it was one of the things that provoked me to become a financial supporter of Zig. (Even though I haven't written a line of Zig yet.) Cross compilation in Rust is better than C or C++. But it's still a big…

Do you think that Rust would be a better language if everything had to be compiled from source?

The Ultimate++ environment for C++ does the same thing with C++, and it seems to work just fine even for them.
Post reply on HN