Zig is becoming more production-worthy • Hacker News Board

Re: Zig is becoming more production-worthy

#71

Post by girvo » Fri, Jul 08, 2022, 12:48 AM UTC

birdfood wrote: post #70

girvo wrote: post #69

Earlier quoted context omitted.

> I'm particularly keen on Nim's UFCS One of my favourite parts about UFCS is how it can turn C libraries that I've had to bind into nice clean looking interfaces! esp_err_t sw_enableRx(SwSerial *self, bool State) Becomes proc sw_enableRx*(self: ptr SwSerial, State: bool): esp_err_t {.importc: "$1", header: " ".} Which when called is super lovely! var port = sw_open(params, etc) port.enableRx(true)

The end result doesn't look anything like C! Really nice. Nim almost feels like I'm writing a dynamic scripting language, except that I've worked with a typed python code base and it sucked because typing always felt taped on. With generics in Nim I feel like I'm duck typing, but my ducks are compile time checked! I'm keen on experimenting with protocol oriented programming and as far as I understand, UFCS provides t…

Absolutely! It's fantastic :)

One piece of advice I can give, is functional programming (which I am a huge proponent of), as defined by a tonne of chained/composed operations on sequences

   .map.filter.etc.etc()

Is not a good fit for Nim. `proc` is a really good reminder: its a procedural language, more than anything else!

You can still use a lot of FP ideas though, but one thing I always remind myself is at the end of the day Nim _is_ C, C is the output, so working within that idea helps a lot in terms of keeping things optimised with little effort on my behalf!

Re: Zig is becoming more production-worthy

#72

Post by delphLonepaw » Sun, Jul 17, 2022, 7:47 AM UTC

chienandalou wrote: post #38

suby wrote: post #32

Zig looks very promising, but there are a few nitpicks I have which keep me from deep diving into it. The most annoying thing I've found so far is treating unused variables as compiler errors. I understand this is something more and more languages are doing, but I can't get over it. It makes writing and prototyping code annoying and tedious, especially during the initial learning phase. Zig trusts the programmer to d…

If the 'unused variable'-handling is the only thing that holds you back: it's quite simple to build the zig compiler and patch it. See this post by ryuukk in the corresponding issue on github: https://github.com/ziglang/zig/issues/335#issuecomment-10138... and also https://github.com/ziglang/zig/issues/335#issuecomment-10184... I use this method to build a zig compiler to work with, and when I build a release build o…

I think the unused error is great, and a lot of people once they got used to it, it becomes quite the useful message, some bugs and some mistakes not easy to catch are quite there now.

Giving it a bit of time is a good way to get used to it and ends generally (at least in my opinion) in better code.

Outside that :shrug:

Re: Zig is becoming more production-worthy

#73

Post by Gibbon1 » Sun, Jul 17, 2022, 8:02 AM UTC

anonymoushn wrote: post #48

ihateolives wrote: post #42

Earlier quoted context omitted.

Having to build your own version of the compiler to fix this annoyance is like using a sledgehammer to crack a nut. It should be a simple flag, whichever way the default, but it shouldn't require building a compiler. That's nuts, both in a bad and a good way.

I have my own version of the stdlib because I don't think formatting a number with leading zeroes should involve parsing UTF-8. It's pretty easy! I once said I would like arrays of 33 or more items to be Default and my resident Rustacean told me step 1 is to rebuild libcore after changing the appropriate macro :)

That funny. I have one where octal is banned.