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

181–190 of 286 posts

Re: Maintain It with Zig

#181

Post by AnIdiotOnTheNet »

PaulDavisThe1st wrote: post #153
kaibee wrote: post #113

Earlier quoted context omitted.

> I'm imaging some poor software engineer in 2065, having to maintain an enterprise legacy stack... levels of FORTRAN/COBOL->C->C++->ZIG->RUST->PERL->PYTHON.... all the way up....JS..etc.. I have good news and bad news: That programmer will not know any of those languages, as they will just program in English and GPT-3000 will convert it into code.

The reason that we have programming languages at all is that English and all other natural languages are too ambiguous to be used for this purpose. GPT-3000 will have no problem understanding some interpretation of your English (or Spanish or Mandarin) "program", but will it be the right one? How long will it take to get GPT-3000 to understand what you mean when you can only talk to it in English (or Spanish or Manda…

Eventually maybe only the same amount of time it takes the average programmer to understand your meaning.

Re: Maintain It with Zig

#182

Post by moogly »

AndyKelley wrote: post #111
moogly wrote: post #64

Earlier quoted context omitted.

I've been toying with Zig over the summer, and I'm really impressed by the build system, general ergonomics and the explicitness of the language. The only thing I've found being a pain point is C's biggest pain point: the lack of a proper string type. Even though I've worked for years in the past with C and C++, I still get tripped up, and in Zig I keep on being confused whether I should use raw byte arrays, or senti…

Out of curiosity, what are you working on that requires a proper string type (rather than encoded UTF-8 bytes)?

I wouldn't use the word "require", and perhaps you didn't mean it that strongly. Don't get me wrong: I could get by without and achieve what I needed to, but to be honest it didn't feel great.

I was doing some pretty gnarly high-level filesystem work (transforming an unstructured tree of files/folders into a more structured tree following certain naming and categorization conventions -- a lot of parsing/building/concatenating paths). I have been working with higher-level languages for the past decade or so, but have had a wanderlust to get away from garbage collected langauges and go back to my roots a bit, so I've been comparing some of the newer options in the "improved C"/"C++ replacement" space.

It may very well be that I'm not the target demographic for Zig, and that's totally fair, but to me it felt pretty jarring to go back to working with C-style character (byte) arrays and all the (well-known) issues with which they are fraught. I didn't feel like Zig was an improvement over C in the string handling area (as opposed to all other areas), whereas languages like Go and Rust are.

Other than that, I felt Zig was a joy to use.

Re: Maintain It with Zig

#183

Post by tialaramex »

kristoff_it wrote: post #18
dnautics wrote: post #10

Zig is clearly leaning in hard to the E3 strategy! (embrace, extend, extinguish) for those not familiar

Not sure why people are downvoting. We all have our hidden agendas, mine is the destruction of all macros.

Surely if you ensure people can't write macros in your language they'll just wrap the entire language in a pre-processing layer to enable macros which seems obviously worse ?

Re: Maintain It with Zig

#184

Post by moogly »

moogly wrote: post #99
10000truths wrote: post #80

Earlier quoted context omitted.

> I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age. You don't need a string type for that, you just need routines that handle UTF-8…

Sure, you're not wrong. For my purposes that'd work, but I'm of the opinion that delegating that to an optional library will make a lot of developers lazy and not even bother thinking about Unicode/i18n/l10n issues at all. I've seen so much code, in a multitude of languages that is oblivious to it, but even if it's reified in a type or even having some form of language support, I guess you can argue that people can s…

In addition, I should add there are synergy effects in having the community (and the major libraries) settling on a common way, and you'll only really get that if there is a built-in.

However, if the philosophy here is to be unopinionated and optimize for flexibility over everything else, I feel I can't really fault them for making that choice.

Re: Maintain It with Zig

#185

Post by matu3ba »

ngrilly wrote: post #167
kristoff_it wrote: post #78

Earlier quoted context omitted.

To be fair this alone is nowhere near what Rust can do for you in terms of safety.

Any plans to go one step further towards memory safety (and even better data race freedom)? Maybe using ARC when the overhead is acceptable (like Swift), it static analysis is not possible due to the type system not supporting the concepts of ownership, borrowing, lifetimes and so on? Zig is super exciting, but without a GC or Rust type system, I’m worried about going “back” to a language where I have to think about…

As of now the tradeoff of Rust's type system is that code may leak memory and you may need to investigate all occurrences to fix it, because there is no tooling yet (testing everything is infeasible).

You can have either extensive static analysis or fast compile times. Tracking ownership down to semantic analysis (where type layouts are in resolved form) requires adjusting and slowing down the complete compiler.

Re: Maintain It with Zig

#186

Post by dnautics »

maleldil wrote: post #162
woodrowbarlow wrote: post #86

Earlier quoted context omitted.

i love that zig doesn't have a special syntax for generics, it just allows anything to be resolved at compile-time -- including types. which gives you generics 'for free'.

I've only cursory of Zig, so bear with me. Does this mean that Zig templates are like C++, that is, duck typing? Or is there a notion of constraining the type arguments?

It's duck typed but let's say your "template" takes an integer and divides by two depending on some boolean (perhaps you need to return a lookup table of sometimes half the bitwidth of an integer type). That function called by your template at compile time to maybe-divide-by-two is in the same language as runtime zig, and you could even conceivably call that very same function as a compiled entity in the runtime context.

Re: Maintain It with Zig

#187

Post by amedvednikov »

dralley wrote: post #152
BiteCode_dev wrote: post #123

I hear about zig all the time, and I'm surprised I don't more about vlang. Yet they still to target a similar audience. Is this a matter of popularity or features ?

Vlang started as a closed source project with a lot of lofty claims that fell apart quickly once the project was actually opened up. Combined with all the delays and broken delivery promises leading up to that, it gave people a poor impression of the project. With that said, I've heard the situation has improved since then.

Can you list any claims that fell apart?

For example, one of the biggest claims has always been fast compilation. Here's V compiling itself in 0.3 seconds: https://www.youtube.com/watch?v=pvP6wmcl_Sc

V was also self hosted (written in V) from the start, which says a lot about the maturity of the language.

> Combined with all the delays

There were no delays. The project was announced to be released in June, and it was.

By the way, we now have a cool OS written in V, that can already run Bash, g++, and V itself!

https://github.com/vlang/vinix

Re: Maintain It with Zig

#188

Post by dnautics »

dralley wrote: post #148
dnautics wrote: post #10

Zig is clearly leaning in hard to the E3 strategy! (embrace, extend, extinguish) for those not familiar

I disagree for two reasons. The first is that if the traditional upstream stops caring about improvement, it's only reasonable for other parties to move on. And that's largely true with the C ecosystem, as it was with OpenOffice for example. Second, "extend" has traditionally meant "extend with proprietary code". Think early 2000s Microsoft with browser APIs and J++, or Amazon with their in-house forks of MongoDB, Po…

I'm not opposed to calling GNU E3. Basically no one uses unix or multics or whatever anymore.

Re: Maintain It with Zig

#189

Post by matu3ba »

kllrnohj wrote: post #101
wyldfire wrote: post #85

Earlier quoted context omitted.

But Zig makes this tradeoff intentionally. By design.

"It's intentionally less safe! That's why you should use it!" Zig may strike a better balance than Rust does here, but it seems more like Rust stole its lunch. I don't know why I'd migrate from C/C++ to Zig instead of going all the way to Rust?

1. Rust doesnt let you safety-check bit-compressed stuff and instead relies on well-formed types during runtime (basically everything that union allows).

2. Graph memory patterns in Rust are completely unsafe.

3. Code might leak and you dont have tooling to check your dependencies. Trusting the test coverage does not help you there with Rust, because Rust tooling is infeasible for testing leaks.

4. CTFE is not easy to track in Rust, so you dont know if certain code may have run-time cost or not.

5. Not all UB during comptime or runtime is (planned to be) checked/checkable https://rust-lang.github.io/rfcs/3016-const-ub.html

Re: Maintain It with Zig

#190

Post by lhorie »

zamadatix wrote: post #166
AndyKelley wrote: post #120

Earlier quoted context omitted.

> Let's hope this is not vaporware. I sincerely approve of the skepticism. I can assure you there is already a very large fire under my ass to get this shipped. To provide some more context, here is a snippet from the latest release notes[0]: > Having a package manager built into the Zig compiler is a long-anticipated feature. Zig 0.8.0 does not have this feature. > If the package manager works well, people will use…

After self hosted compiler and package manager what are the big ticket items blocking 1.0 (other than fixes for a lot of the stuff that is broken)?

IIRC nailing down stdlib and its documentation was a big one
Post reply on HN