Live data from Hacker News

Maintain It with Zig

kristoff.it

281–286 of 286 posts

Re: Maintain It with Zig

#281
post #241

Earlier quoted context omitted.

Ahh you mean Elm, by any chance? I feel Elm's growth has been stunted because the creator is actively hostile with whoever disagrees with him. I remember the infamous "leaving elm" post which was handled so poorly by Elm's author. If they had handled it well, elm would have definitely seen a large uptick in adoption

There really isn't any call to trash Elm and its creator like this. There's very little evidence of ongoing hostility from Evan - I pay attention to his work and writings and find he's rarely if ever hostile. In fact he's very mild-mannered, and is painstakingly detailed about explaining the reasons for why he does things the way he does, over and over again. Perhaps that wore thin once or twice in the face of repeat…

Elm has done some great work, even the ones, who left elm for other tech, acknowledge elm's elegant design.

However, elm is not pragmatic. the issues mentioned in Luke plant's "leaving elm" [0] are valid. and Evan's response to that was far from satisfactory[1] and this has affected Elm's popularity.

The disagreement between BDFL and community has happened in many other cases as well. and there is a way to solve them amicably. Most recently, Vue faced it when community caused uproar over composition API RFC. and Vue solved it nicely and amicably[2]. If Elm has followed similar approach, Elm too would be praised for it, and gained even more popularity.

[0] https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

[1] https://www.reddit.com/r/elm/comments/g070sz/evans_response_...

[2] https://dev.to/danielelkington/vue-s-darkest-day-3fgh

Re: Maintain It with Zig

#282

Earlier quoted context omitted.

I would say that Zig has the same advantages for a lot of these points. Its interoperability with C at the source and object level is first-class, the syntax was very easy for me to pick up as someone familiar with C/C++, the features it adds on top of C (e.g. slices, compile time execution) are few but huge QoL improvements, its translate-c utility works amazingly well at transpiling C code to Zig, and its test bloc…

Out of curiosity, have you written apps in both languages? I have written small applications in both. To be transparent: my total dev hours in D are probably somewhere around ~100, and in Zig about ~30. So I am more familiar with D than Zig, though competent enough with both to have written a few small real-world programs. > Its interoperability with C at the source and object level is first-class D has direct intero…

D has a lot to offer. But C absolutely crushes everything else in the embedded space, on micro-controllers, and if a language wants to be a C replacement, it'll have to leave C gasping right there. D quite simply never tried.

Zig on the other hand seems like a silver bullet aimed straight at C's heart, the embedded space. Once it arrives it'll only have to worry about Rust.

Rust is the black hole at the center of the software universe, slowly sucking the blood out of everything else. Zig vs Rust is shaping up to be an epic battle, like the Jedi vs the Empire, for sure :)

Re: Maintain It with Zig

#283
post #90

I prefer D, it can be fully compatible with C, the syntax is easy to learn if you've used any of the C family you already know 80%, the package system is simple, modules mean no more headers or include statements just import things where and when you need them, supports every style of programming, QOL improvements like ranges and foreach, proper strings, optional garbage collector, has a long history of continuous im…

Me too. > To me it's the clear choice if I'm going to rewrite an old C project since I can mostly just copy paste the old code and it runs With the new ImportC feature you can literally copy-paste the code and reference your C types from D directly with a mixed compilation. https://news.ycombinator.com/item?id=27872596 https://dlang.org/spec/importc.html Quoting Walter from the thread linked above on it's purpose/rea…

`@cImport` in zig does the same as `ImportC` for D. You import a C file and can then just use it in your program. Notably it existed in Zig before it did in D.

Re: Maintain It with Zig

#284
post #276

Earlier quoted context omitted.

Rust does not free you from having to track memory, for large classes of important data structures. And, if you want to implement smart pointers for your app in zig, it is easy. Yes, your examples are two proprietary, nonstandard techniques. Or alternatively using a third-class toolset (jemalloc toolkit e.g ). Sanity is having a single, anointed way to do it in the stdlib.

The point is what Zig offers, versus what C and C++ have been offering for at least 25 years, regardless of the tooling being commercial or not.

Yeah so? It's offering it in a not-insane fashion, that's my point.

Re: Maintain It with Zig

#285

Earlier quoted context omitted.

Out of curiosity, have you written apps in both languages? I have written small applications in both. To be transparent: my total dev hours in D are probably somewhere around ~100, and in Zig about ~30. So I am more familiar with D than Zig, though competent enough with both to have written a few small real-world programs. > Its interoperability with C at the source and object level is first-class D has direct intero…

D has a lot to offer. But C absolutely crushes everything else in the embedded space, on micro-controllers, and if a language wants to be a C replacement, it'll have to leave C gasping right there. D quite simply never tried. Zig on the other hand seems like a silver bullet aimed straight at C's heart, the embedded space. Once it arrives it'll only have to worry about Rust. Rust is the black hole at the center of the…

Well, I don't know how accurate this is, but I sure do enjoy how it was written.

Re: Maintain It with Zig

#286
post #261

Earlier quoted context omitted.

Hi Andy, I'm really intrigued by Zig's features - you're definitely solving the right and hard problems for C developers like myself. If I may, my only piece of feedback (as someone who looked at Zig with fresh eyes) is that the syntax has lots of special chars (@, !void, .{}, &, etc). Is there a rationale published for these and other design choices (even if it's "I like it that way"). I would have expected a langua…

>If I may, my only piece of feedback (as someone who looked at Zig with fresh eyes) is that the syntax has lots of special chars (@, !void, .{}, &, etc). Is there a rationale published for these and other design choices (even if it's "I like it that way"). I would have expected a language with ambitious goals like Zig to take a stab at coming up with a grammar that's even simpler and cleaner than C. That is sadly my…

Isn't the example difficult to parse only because it's unfamiliar to you? As someone who has never used zig, I feel like 5 minutes of study would make this line easy to read.
Post reply on HN