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

Maintain It with Zig

kristoff.it

Post reply on HN
Print view View original

271–280 of 286 posts

Re: Maintain It with Zig

#271

Post by int_19h »

pjmlp wrote: post #37
mishafb wrote: post #5

Earlier quoted context omitted.

Zig has painless cross compilation, with gcc or clang it's a nightmare

I would like to see that painless cross compilation for UWP applications. Truth is that cross compilation always breaks down in complex deployment use cases.

In principle, why wouldn't it work for C++/WinRT, given that it doesn't use the WinMD metadata directly, but rather produces valid C++ headers from it?

I think the problem for Zig is that they use MinGW as their Windows target, and the latter's standard library isn't really UWP compatible (yet?).

Re: Maintain It with Zig

#272

Post by rofrol »

adamdusty wrote: post #115
torginus wrote: post #109

Generally speaking, what killed C++/C for me is the absolute insanity that comes with it's build systems/third party dependency management. I feel like the notoriety that C++ gets for it's absurd complexity comes not from variadic template metaprogramming/rvalue references/unique_ptr or whatever, but the absolutely humongous effort needed to understand automake/CMake/autotools just to build other people's code (god f…

The build system for zig is essentially the same as CMAKE just in Zig and entirely undocumented.

- https://ziglang.org/learn/overview/#zig-build-system

- https://ziglearn.org/chapter-3/#zig-build

- https://zig.news/xq/zig-build-explained-part-1-59lf

- https://dev.to/mattnite/weaning-zig-off-of-git-submodules-1-...

- https://dev.to/fabioarnold/setup-zig-for-gamedev-2bmf

Re: Maintain It with Zig

#273

Post by ljm »

earth_walker wrote: post #269
rk06 wrote: 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…

I think you're saying Evan is the BDFL (Benevolent Dictator for Life) for Elm, except it's interesting you chose the word 'despot' because many of the decisions made with Elm are far from benevolent (like preventing certain library usage and interop if the code isn't hosted on github, within the elm org).

The criticism is valid. Haskell is painfully strict and, still, it offers various ways out of its guarantees. Rust is painfully strict and gives you `unsafe`. Neither of them break your build if you don't host your code in a specific github org.

Re: Maintain It with Zig

#274

Post by amedvednikov »

super_flanker wrote: post #266
amedvednikov wrote: post #254

Earlier quoted context omitted.

There's no `nil` in the language, but indeed there's a hack that allows to assign 0 to references. It's on the 0.3 roadmap, high priority.

Similarly almost every feature in V has some hacks or doesn't work outright. But authors of V don't have enough dignity to mention the in-progress/missing features on home page. And when somebody points them to their dishonesty, they block them on discord.

No, this is completely false.

I see you created this account to spread false information about V:

> Ditto same experience, I asked if somebody could explain me the memory model of V; and all of sudden hell broke loose. I was asked why do I need to know how memory model worked, are you a troll, if you don't contribute to the lang you're not welcome here. Never asked a second question again.

This never happened. Otherwise you could send a link to the discord conversation.

No one gets banned or called a troll for asking questions.

Besides, the memory model is explained in details on the home page.

Re: Maintain It with Zig

#275

Post by pjmlp »

int_19h wrote: post #271
pjmlp wrote: post #37

Earlier quoted context omitted.

I would like to see that painless cross compilation for UWP applications. Truth is that cross compilation always breaks down in complex deployment use cases.

In principle, why wouldn't it work for C++/WinRT, given that it doesn't use the WinMD metadata directly, but rather produces valid C++ headers from it? I think the problem for Zig is that they use MinGW as their Windows target, and the latter's standard library isn't really UWP compatible (yet?).

Because the whole build process to produce a MSIX or APPX requires a little more, like the whole Windows SDK, plus whatever might be fetch via NuGET via MSBuild, and the process to sign the packages?

Re: Maintain It with Zig

#276

Post by pjmlp »

dnautics wrote: post #258
pjmlp wrote: post #237

Earlier quoted context omitted.

What sanity when the developer is still responsible for tracking memory manually by themselves? > It is the Zig programmer's responsibility to ensure that a pointer is not accessed when the memory pointed to is no longer available. https://ziglang.org/documentation/0.8.1/#Memory Mocking malloc you say? https://docs.microsoft.com/en-us/visualstudio/debugger/crt-d... It exists at very least since Visual C++ 5.0, and Bo…

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.

Re: Maintain It with Zig

#277

Post by moltonel3x »

fulafel wrote: post #238
steveklabnik wrote: post #12

Agreed for sure that working with C and C++ is the only way forward for systems languages. Rust's expression of this is the zero-cost C FFI, using native platform tooling, and stuff like that. Rust was never about re-writing the world, after all, its reason for existing was to eventually improve Firefox. The very first presentation about Rust ( http://venge.net/graydon/talks/intro-talk-2.pdf ) says "We are not “rewri…

The boat has already sailed, but it's GCd languages and not Rust that replaced most usage of C and C++ in systems programming. Rust is nibbling at the remaining niche islands of C/C++.

Rust isn't only nibbling at the C/C++ niches: thanks to its correctness and productivity aspects it also attracts people coming for example from Go/Python/Javascript.

In some way, you could say that Zig is pulling system programmers towards high-level programming, whereas Rust is pulling high-level programmers towards system programming. That's not a watertight comparison but I think it's an insightful one.

Re: Maintain It with Zig

#278

Post by earth_walker »

ljm wrote: post #273
earth_walker wrote: post #269

Earlier quoted context omitted.

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…

I think you're saying Evan is the BDFL (Benevolent Dictator for Life) for Elm, except it's interesting you chose the word 'despot' because many of the decisions made with Elm are far from benevolent (like preventing certain library usage and interop if the code isn't hosted on github, within the elm org). The criticism is valid. Haskell is painfully strict and, still, it offers various ways out of its guarantees. Rus…

I purposely avoided 'BDFL': too much precedent as to what that means!

Limiting certain kinds of js access to vetted libraries is benevolent, if that's part of the language's goals. Likewise the lack of type classes or mutability/unsafe escape hatches.

Elm's developers do not enforce constraints to be 'hostile' or 'far from benevolant'. It's a tradeoff - language power for certain guarantees, guarantees that not even Haskell can provide.

Unfortunately, this sometimes means trying to constrain access to the completely unconstrained js library ecosystem, so the solution, at least for now, is a bit of a blunt weapon.

Note that Elm doesn't 'break your build' if you don't use github - that's a constraint on linking to official libraries only. I don't use github and my code works just fine.

Re: Maintain It with Zig

#279

Post by int_19h »

pjmlp wrote: post #275
int_19h wrote: post #271

Earlier quoted context omitted.

In principle, why wouldn't it work for C++/WinRT, given that it doesn't use the WinMD metadata directly, but rather produces valid C++ headers from it? I think the problem for Zig is that they use MinGW as their Windows target, and the latter's standard library isn't really UWP compatible (yet?).

Because the whole build process to produce a MSIX or APPX requires a little more, like the whole Windows SDK, plus whatever might be fetch via NuGET via MSBuild, and the process to sign the packages?

I would compare building MSIX or APPX to building an apt or rpm package on Linux - that's the next step after building the actual executables, which is what Zig covers.

Re: Maintain It with Zig

#280

Post by strokirk »

Arnavion wrote: post #124
mumblemumble wrote: post #50

Earlier quoted context omitted.

disclaimer: I haven't actually used either, just done a lot of interested reading and a little toying around. One thing that impressed me about Zig is how simple the language is. I get the impression that it would take very little time to properly learn the language and become effective at it. Rust, on the other hand, has a whole lot of complexity even without the ownership semantics. So much to learn and understand.…

Is char* c_foo(char* bar) { ... } simpler than fn rust_foo (bar: &'a str) -> &'a str { ... } ? On the one hand, c_foo is shorter and doesn't use strange symbols. On the other hand, rust_foo doesn't leave you guessing on whether the returned value needs to be free()d or not, and whether the heap allocation backing `bar` can be free()d after the call or not.

The first example is definitely simpler, yes.
Post reply on HN