[HN Gopher] Zig Goals
___________________________________________________________________
Zig Goals
Author : whatever3
Score : 72 points
Date : 2024-06-07 19:15 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fallingsquirrel wrote:
| You probably want (2015) in the title.
| nick238 wrote:
| Kind of meh just linking to goals 9 years ago. How'd they pan
| out? 100%? 50%?
| squeek502 wrote:
| All of the listed goals have arguably been met, except:
|
| - Auto-generating a `.h` file has temporarily regressed
|
| - Friendly toward package maintainers is an ongoing goal
|
| - "Memory zeroed by default" is not accurate, instead you
| must initialize all variables (to either some value or
| `undefined`)
| sekao wrote:
| The ability to export a zig project to a single C header file
| would be really nice. Is that still a planned feature?
| jiripospisil wrote:
| Compiling to a single C file such that you can then compile the
| result via say clang is already supported (-ofmt=c). Automatic
| generation of C header files from your Zig library is WIP. The
| current recommend approach is to just write the C corresponding
| header files yourself, the issue mentions a couple of examples.
|
| https://github.com/ziglang/zig/issues/9698#issuecomment-9747...
| boricj wrote:
| Linking to the README.md file directly instead of the source code
| tree would make the intent of this submission more obvious.
| thangngoc89 wrote:
| I agree. Below is the direct link in case one of the moderators
| see this and want to update.
|
| https://github.com/ziglang/zig/blob/4236b85c722b36cb31595634...
| tiffanyh wrote:
| In more recent news, today Zig launched 0.13.0
|
| https://news.ycombinator.com/item?id=40605828
| durandal1 wrote:
| How they basically could not improve on tagged union enum types
| as you express them in C is to me one of the misses. Modeling
| data through effortless sum types is a requirement for me when
| picking up a modern language.
| AndyKelley wrote:
| you're confused. zig had tagged unions since before 0.1.0.
| taliesinb wrote:
| An earnest question: can you elaborate on what Zig got wrong in
| that respect?
| quocanh wrote:
| I don't think this was super important given the core goals of
| the project. I agree that effortless tagged unions are a very
| valuable feature in a language, but it's also one that is
| paradigm shifting and requires a different set of goals.
|
| Without naming names, there is a language out there with some
| overlap with Zig's domain that does have really good tagged
| unions. But that project has a different set of goal than Zig's
| and that's okay. They're both good projects.
| heavyset_go wrote:
| Off topic, but how stable is Zig's syntax these days?
| PartiallyTyped wrote:
| From previous conversations, very stable. There shouldn't be
| any changes going into v1.0
| refulgentis wrote:
| Flagged, per observations confirming other comments noting old,
| unclear link, people noting they're not sure if they're on-topic,
| and multiple people downvoted below 0 when they use the link as a
| source for their comment.
|
| Even with charity and steel-manning, this is a one-off, broad,
| short, personal todo list from 9 years ago.
|
| That leads me to believe it is unclear what the topic is, and it
| is clear it is a minefield if you comments.
| 0x0203 wrote:
| > Opinionated when it makes life easier. > Tab character in
| source code is a compile error.
|
| I don't think I will ever understand this. I get that different
| people have different preferences and reasons for those
| preferences, but why deliberately alienate such a large set of
| potential users? Especially after a statement asserting it's to
| make life easier? Who's life? The developers who will be using
| the language? I'm not convinced forcing all users to either type
| more white space or figure out how to configure their editor to
| auto convert (some of which may not be able to) is really making
| life easier. Or is it for the language developers themselves? In
| which case I'd argue that's probably the wrong thing to be
| optimizing for, and that it isn't that difficult to support both
| anyway.
|
| And to be clear, I'm not interested in litigating the tabs vs
| spaces debate here, or even white space as part of code/syntax.
| It's this attitude that I'm seeing a lot more in recent years of
| 'I know better than you how you should do/use _X_ so I'm not
| going to give you the option'. Obviously not every project out
| there can be tailorable to every user's every preference, but I
| wish that when deciding what to accommodate and what not to, it
| would be done not on one's own myopic perception of the problem
| space, but on actual limitations and priorities and user needs.
| And when making a choice that may not be widely popular, be up
| front about why and how that decision was made. I'm much happier
| accepting 'not enough dev resources to support the added
| complexity in the parser' than I am 'tabs are stupid and you're
| dumb for wanting to use them'.
| xxpor wrote:
| Consistency >> people's individual preferences when working in
| a large organization, which is how most stuff gets built.
| thangngoc89 wrote:
| I think this is to avoid debate in the team that would use the
| language. The language simply doesn't allow that, end of
| discussion.
|
| Just like `go fmt`. It's a compiler error for unformatted
| codes.
| WD-42 wrote:
| If you are completely alienated from a language because of your
| white space preferences it's probably a sign you need to re
| evaluate some priorities.
| smrq wrote:
| Spaces instead of tabs are an accessibility problem for some
| people. Being able to read and write source code is priority
| #1.
| timacles wrote:
| Especially for the elimination of tabs
| lioeters wrote:
| That is an opinionated decision to make tabs a compile error.
| It sounds like it offended you somehow, since nowhere does it
| even imply "tabs are stupid".
|
| There could be a reasonable explanation, for example, that
| having two different characters for white space is redundant
| and unnecessary. We may not agree, but making it an error to
| use tabs is an effective way to avoid any bike shedding about
| this contentious topic.
|
| It's similar to the Go formatter enforcing tabs for indentation
| and white space for alignment. It doesn't matter what I may
| think is the correct answer to the tabs/spaces question because
| I would never bother doing that manually. Either let some tool
| do it automatically, or don't allow tabs at all - which I'm
| guessing is how Zig's formatter works, by replacing tabs with
| white space.
| unclad5968 wrote:
| > Whitespace at the end of line is a compile error
|
| How does this "make life easier"?
| arcanemachiner wrote:
| One less annoyance for others to deal with.
|
| Set your text editor to trim trailing whitespace on save, then
| I won't have to filter out your crap from my commits just
| because I happened to save a change in the same file that was
| previously saved by your sloppy text editor.
|
| I wholeheartedly endorse this. While we're at it, please set
| your text editor to ensure that every file ends with a newline
| character.
| __loam wrote:
| Practically, engineers should never think about something like
| this because their environment should automatically fix it. I
| guess it's weird that it won't compile but there's languages
| that won't compile if you don't end the line with a semicolon.
| Just use an editor that will fix this automatically and never
| spare another thought for it.
| WD-42 wrote:
| So I can avoid needing to double check changes when I hit save
| on a file that you previously edited with white space and all
| of a sudden my one line change has 4 changed lines.
| ForLoveOfCats wrote:
| What I find remarkable is how closely aligned these goals are
| with the Zig we see today. Andrew is an incredible engineer and,
| while I don't prefer all of Zig's design decisions, he clearly
| had a very complete vision for the language from the beginning.
| LAC-Tech wrote:
| I like Zig the language. Probably more than rust - Zigs singular
| focus on making systems programming ergonomic really appeals to
| me.
|
| Rust tooling however makes it an easy choice. Unit testing with
| pretty printing, proptest crate for property based testing,
| Cargo.toml is just an easier life choice than build.zig, etc etc.
|
| Not sure if Zig will improve in this regard. I suspect what I
| consider an improvement Zig folks would not. Still easier to
| wrangle than C.
___________________________________________________________________
(page generated 2024-06-07 23:02 UTC)