[HN Gopher] Maintain It with Zig
___________________________________________________________________
Maintain It with Zig
Author : Tomte
Score : 307 points
Date : 2021-09-08 15:40 UTC (7 hours ago)
(HTM) web link (kristoff.it)
(TXT) w3m dump (kristoff.it)
| rattray wrote:
| Interesting; this piece advocates for porting only (or at least
| initially) the build system of C/C++ projects to use the Zig
| compiler and the build.zig build system for cross-compiling
| dependencies. A package manager in the works could be interesting
| too.
|
| I don't do C/C++ development. How many headaches would using Zigs
| compiler & build system solve?
| mishafb wrote:
| Zig has painless cross compilation, with gcc or clang it's a
| nightmare
| pjmlp wrote:
| 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.
| dleslie wrote:
| o.O
|
| Zig uses LLVM for cross compilation, and so does clang. It's
| really not any better.
|
| https://clang.llvm.org/docs/CrossCompilation.html
| messe wrote:
| The part that Zig does well, is that it bundles C headers
| and standard library sources with it. This is the hard part
| of cross compilation. The default install can build
| standalone executables from C programs for any supported
| platform.
| dleslie wrote:
| If someone wanted to package clang to do that, they
| could. They do, in fact, that's how clang cross
| compilation packages work.
|
| But sure, to Zig's credit, they ship all the supported
| toolchains and so don't have many different cross
| compilation variants in the OS's package manager. But
| that's a bit like buying one of everything, even though
| you'll only use one or two.
| messe wrote:
| > If someone wanted to package clang to do that, they
| could. They do, in fact, that's how clang cross
| compilation packages work.
|
| Clang doesn't bundle a C standard library implementation.
|
| > But sure, to Zig's credit, they ship all the supported
| toolchains and so don't have many different cross
| compilation variants in the OS's package manager. But
| that's a bit like buying one of everything, even though
| you'll only use one or two.
|
| Zig only bundles the sources, so it builds the C library
| on-demand. IIRC it's smaller than most cross compiler
| toolchains.
| dleslie wrote:
| > Clang doesn't bundle a C standard library
| implementation.
|
| ... So? It can use most any you wish.
|
| > Zig only bundles the sources, so it builds the C
| library on-demand.
|
| Which it then caches, post-compilation, taking up binary
| space on disk comparable to if you just downloaded the
| pre-compiled target binaries.
| kristoff_it wrote:
| > Which it then caches, post-compilation, taking up
| binary space on disk comparable to if you just downloaded
| the pre-compiled target binaries.
|
| I don't understand the point of this comeback. If you
| have the artifact cached it means that you compiled for
| that target, while the rest of the stdlibs remain in
| source form (also Zig deduplicates header files which is
| why everything fits in a 40mb tarball), and you didn't
| have to download anything manually. What else would you
| want exactly?
| [deleted]
| skywal_l wrote:
| Zig is a very interesting language. You are able to do thing that
| would require wizard level skills in C with simple plain language
| construct. Like serializing/deserializing an enum variants over
| the wire for example in the most efficient way (look at
| std.json.{parser, stringify} [0]).
|
| > soon we'll also have a package manager
|
| This. If they succeed to do this (and I have my doubts) it will
| be a paradigm shift for low-level "system" programming.
|
| Let's hope this is not vaporware.
|
| Finally, it's relatively easy to contribute to Zig. Andrew Kelley
| is very opinionated on where the language should go with an
| emphasis on simplicity which sometimes can make things awkward
| but he is also persuasive and welcoming. I have been using Zig
| for a month and I am still positively surprised so he must be
| onto something.
|
| [0]:
| https://github.com/ziglang/zig/blob/master/lib/std/json.zig#...
| moogly wrote:
| 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 sentinel-terminated arrays for
| certain string manipulations. Maybe I'm not familiar with
| common idioms in Zig that might help avoid this C-style
| tracking of string/buffer lengths malarkey that I tend to end
| up with where a slice is not appropriate.
|
| Maybe a dynamic-length string library is the way forward.
|
| 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. I understand having one of
| those could make C interop a bit gnarlier (I think Odin's
| approach of having two separate string types -- one of which is
| just meant to be used for interop -- should be workable).
|
| Oh, and the ecosystem of libraries is still young. I needed to
| format timestamps as human readable date/time to a file, and
| had to step down to C to do something that basic[1], but it'll
| get there in time, I'm sure.
|
| [1]: "basic" from the perspective of the end-user of the
| language. Having written a (not even fully featured) date/time
| library in C++, I consider date and time to be one of the
| hardest domains I've ever had to work in.
| 10000truths wrote:
| > 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 strings, like utfcpp
| (https://github.com/nemtrif/utfcpp).
| kristoff_it wrote:
| Agreed, and Zig also has a lib for that as well:
|
| https://github.com/jecolon/ziglyph/
| moogly wrote:
| Ooh, haven't come across this. Thanks!
| moogly wrote:
| 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 still ignore it.
| mikepurvis wrote:
| That was basically the state of affairs with strings in
| Python 2, and although the transition was awful, I'm
| really, really appreciative of Python 3 now having
| clearly-separated str and bytes types.
| moogly wrote:
| 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.
| AndyKelley wrote:
| Out of curiosity, what are you working on that requires a
| proper string type (rather than encoded UTF-8 bytes)?
| moogly wrote:
| 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.
| losvedir wrote:
| Note that while strings are generally opaque bytes in Zig,
| there are standard library functions[0] to work with them as
| Unicode codepoints and such. But Unicode is quite large and
| complicated, and things like grapheme clusters aren't in the
| standard library (yet?). I also believe that that module is
| planned to be rewritten. So it's more the case that Zig plans
| to someday support Unicode at the standard library level, but
| not as a specific type.
|
| Then again, I'm not sure exactly what a _type_ would be for
| Unicode. Basically just a flag that the array of bytes has
| been checked and is valid? It 's nice to let the type system
| help you enforce your application boundaries, but I think you
| could wrap it pretty easily in a struct of your own if you
| needed that.
|
| [0] https://github.com/ziglang/zig/blob/master/lib/std/unicod
| e.z...
| moogly wrote:
| Looks like this is an attempt:
| https://github.com/jecolon/zigstr
| mamcx wrote:
| > Then again, I'm not sure exactly what a type would be for
| Unicode.
|
| I have this internally in my lang AST Rust
| Utf8
|
| I think that is the type: struct City {
| name:Utf8 }
|
| For a scripting lang like mine I surface it as `Str` but in
| a system language I think is better to say `Utf8`
| tialaramex wrote:
| > Basically just a flag that the array of bytes has been
| checked and is valid?
|
| In something like Zig I think it's OK that it's merely a
| stated assumption that these bytes are UTF-8, not actually
| checked - so long as people take that seriously.
|
| It's nice in code that maybe isn't very concerned with such
| things to be able to know that any "string" is actually
| text we can display, output to a console, something like
| that. Not for example a TCP/IP packet we haven't decoded
| yet, or the first 32 bytes of a JPEG image.
|
| Programmers who aren't writing firmware for a vacuum
| cleaner or washing machine, probably want string literals
| like "this" in their code, and you'd naturally want those
| to have a type, for which a string type is the obvious fit.
| I believe in 2021 this type should obviously be UTF-8.
| "It's just some bytes" is far from useless, but it isn't
| much of a string type.
|
| I was sceptical at first about Rust's choice to build in
| str (immutable UTF-8 string slices), because that seems
| like a relatively high level concept. But unlike
| std::string::String, str isn't that tricky after all. See,
| the only place such things would come from (not having
| std::string::String to make new ones) is the program
| source, and our compiler is necessarily already reading the
| program source, so it follows that the compiler must know
| how the source is encoded etc and thus it does actually
| know exactly what those literal strings are. If your
| literal wasn't Unicode, that wasn't a Rust program and it
| won't compile.
| void_mint wrote:
| I've been paying attention to Zig posts on HN, mostly just
| because it seems well-liked and I think Andrew Kelley is
| interesting/smart. Would it be fair to say that Zig is to C,
| what Rust is to C++? Or are they both just kind of...low-ish-
| level systems languages solving similar problems, differently?
| oconnor663 wrote:
| > Would it be fair to say that Zig is to C, what Rust is to
| C++?
|
| There's definitely something to that analogy, but I think it
| also misses a lot of really important details. For example,
| Zig has generics, which right off the bat makes it hard to
| say that it's "like C". Also Rust enforces memory safety,
| which isn't like C or C++.
| woodrowbarlow wrote:
| 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'.
| maleldil wrote:
| 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?
| dnautics wrote:
| 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.
| robinei wrote:
| You can constrain type arguments with a compile-time `if`
| check, and generate a compile error on violation.
| kristoff_it wrote:
| It's duck typed but it's not based on a funky and limited
| syntax, but rather types at comptime become normal
| arguments to functions that you can then inspect using
| normal Zig code.
|
| I wrote a blog post about comptime if you want to learn
| more: https://kristoff.it/blog/what-is-zig-comptime/
| roblabla wrote:
| I mean, C11 also has generics, but I would really suggest
| not using it X). See
| https://en.cppreference.com/w/c/language/generic
|
| Of couse, it's a much less powerful feature, there's
| nothing like interfaces or stuff, just a way to "overload"
| based on the type.
| yisonPylkita wrote:
| Thank you. I had no idea that you could do such a thing
| in C11 preprocessor
| nrclark wrote:
| I think that's correct with some overlap, yes. Zig's explicit
| goal - as stated by the creator - is to replace C. Nothing
| more, nothing less.
|
| I feel like Rust wants to replace C but it also wants to
| replace C++. And given the complexity difference between the
| two languages, that means that Rust will end up closer to C++
| than to C.
|
| So there's some overlap based on how Rust positions itself,
| but not based on how Zig positions itself.
| AndyKelley wrote:
| You can find Zig's explicit goal as stated by the creator
| on the homepage:
|
| > Zig is a general-purpose programming language and
| toolchain for maintaining robust, optimal, and reusable
| software.
| masklinn wrote:
| > I feel like Rust wants to replace C but it also wants to
| replace C++.
|
| Rust wants to make systems programming memory safe (and
| type safe while at it). It's not really about any specific
| language, it's about dragging the field forwards on the
| safety front.
|
| Well it's not really Rust, it's the Rust community, which
| kinda wrestled it away from Graydon Hoare: the original
| inception of Rust was more of an applications language
| (what with the evented model and the split stack and the
| planned-though-never-really-implemented GC'd pointers) --
| which explains part of the historical confusion with /
| comparison to Go.
|
| But then a critical mass of people took a look at this
| early rust and figured "we've got plenty of memory-safe and
| type-safe (ish) languages for applications, but this thing
| has precise control over memory and lifetimes and shit, we
| could actually build reliable infrastructure with that",
| and it coincided with a lot of memory safety issues news
| (which has been continuing ever since), and the rest is
| history, pretty much.
| jhoechtl wrote:
| > Zig's explicit goal - as stated by the creator - is to
| replace C. Nothing more, nothing less.
|
| The ZIG compiler requires a C compiler to compile to a
| native executable though.
| Twisol wrote:
| To be fair, the C compiler also requires a C compiler.
| Bootstrapping is a common milestone in language
| development (Rust can bootstrap itself too), so while the
| current state of affairs for Zig might require a C
| compiler, that's not necessarily written in stone.
| messe wrote:
| > The ZIG compiler requires a C compiler to compile to a
| native executable though.
|
| No it doesn't? Not unless you want to also compile C,
| which the Zig compiler is capable of doing because it
| bundles clang.
| wyldfire wrote:
| > The ZIG compiler requires a C compiler to compile to a
| native executable though.
|
| Do you mean compiling the zig compiler or zig programs?
|
| I think neither is quite the case. zig itself can build
| both Zig programs and C/C++ ones. Zig doesn't need to use
| a C compiler to build native Zig executables. It _does_
| need a linker, as does Rust, as do C /C++ programs and
| AFAIK zld is not yet ready.
|
| However it's accurate to say that it's only able to
| compile the C/C++ code by leveraging libclang, the C/C++
| compiler underneath.
| AndyKelley wrote:
| Here's the info on zld status:
| https://ziglang.org/download/0.8.0/release-
| notes.html#Self-H...
|
| By the way, check out this project by Zig core team
| member, Vexu: https://github.com/Vexu/arocc
| abledon wrote:
| We already have c/c++ as low level bases, now zig/rust are
| coming for the throne, I really hope contenders dont keep
| spawning like rabbits. If everyone got behind a smaller #
| of initiatives the worlds codebase would be simpler going
| forward?
|
| 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..
| kaibee wrote:
| > 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.
| PaulDavisThe1st wrote:
| 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 Mandarin) ?
| AnIdiotOnTheNet wrote:
| Eventually maybe only the same amount of time it takes
| the average programmer to understand your meaning.
| rattray wrote:
| I think they solve some similar and some different problems,
| with some similarities and differences!
|
| The biggest difference in the problems they solve, in my
| view, is that Zig does not aim for safety. It'll be _easier_
| to write safe programs yourself with Zig than it might be
| with C, but it doesn 't give you any guarantees.
|
| Zig also seems like it may be a better fit for embedded
| programming; there's a big community around embedded Rust,
| and it sounds like there's a lot of progress, but still an
| uphill battle.
|
| But yes, Zig:Rust :: C:C++ has merit in that Zig is a much
| smaller, less feature-rich language.
| void_mint wrote:
| Thanks for the response. I'm excited for as many viable
| alternatives to C/C++ as we can get.
| tristan957 wrote:
| Zig/Rust aim to fit in the same systems/general purpose space
| which can be viewed as alternatives to both C and C++.
| steveklabnik wrote:
| Many people say this, and there's some truth to it, but like
| all analogies, it can be useful in some contexts but not
| others.
|
| The issue with this analogy is that it assumes that C, one of
| the languages used in the most diverse set of circumstances
| ever, means the same thing to everyone. Same with C++,
| frankly.
| matu3ba wrote:
| Take a look at my comparison of semantics that unfortunately
| not yet includes a sketch of memory and synchronization: http
| s://gist.github.com/matu3ba/dda72ad5ee473e3ea26426c121e0...
| JoshTriplett wrote:
| > Would it be fair to say that Zig is to C, what Rust is to
| C++?
|
| I don't think that's the parallel I would draw.
|
| Rather, I think both Zig and Rust aim to serve the use cases
| C and C++ do, but Zig and Rust pick different points on the
| tradeoffs involving safety. Zig feels like a "better C", in
| the sense of bringing modern language features to C, but it
| chooses _safer_ rather than _safe_. Rust supplies modern
| language features as well, and chooses to prioritize _safe_ ;
| sometimes that comes at the expense of other factors, such as
| productivity or compile time. I personally prefer the point
| on the spectrum that Rust chose, but I think Zig still offers
| improvements over C.
| mumblemumble wrote:
| 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. And, in some cases, work around. It seems, from
| looking at others' code, that there is a very strong
| temptation to lean on `unsafe` instead of figuring out how
| to solve a problem within the constraints it normally
| applies.
|
| That has me wondering if there's really all that much
| safety difference in practice? Simpler code is generally
| easier to understand, and it's generally easier to find and
| fix bugs in code that's easier to understand. I can imagine
| a world where it's a tradeoff between, "You definitely
| won't have any of this relatively narrow category of bug,
| unless of course you opt out of the static checks, which
| you will probably do sometimes, even though we tell you you
| shouldn't," and, "There are no particular guarantees, but
| you're generally less likely to have any of this broader
| category of bug."
| steveklabnik wrote:
| "simple" is, unfortunately, not a simple concept, nor
| does everyone agree on its effects on programs written in
| a language that is or is not simple.
|
| Some people do believe that, let's say "conceptually
| parsimonious" languages (using complicated words to
| describe simplicity is amusing to me, sorry) do exactly
| what you say. Others believe that complexity inherently
| exists, and you can put it in the language, where a
| compiler can tirelessly check certain properties for you
| or a runtime can do magical complicated work on your
| behalf, or you can put it in the programs, where users
| have to check such things themselves.
|
| Another way I heard this expressed one time is Ruby vs
| Python. I once heard someone talk about how they
| preferred Python as a language more, because it was
| simpler, but enjoyed actually programming in Ruby more,
| even thought it was more complex, and they value
| simplicity. The reason is that all of that nasty ugly
| stuff Ruby lets you do makes you be able to make
| extremely nice APIs. Things you couldn't do, or just
| folks don't do, in Python. And therefore they ended up
| liking using Ruby more in practice.
|
| I suspect that this is a topic that we, as a profession,
| will debate about endlessly.
| dman wrote:
| There is also the notion of languages you love writing
| code in vs languages you like reading code in. Languages
| with more powerful abstraction abilities bring joy to the
| writer but make things tedious for the reader.
| paavohtl wrote:
| I don't agree with that. For example, I think it brings
| me joy as a reader that I can tell at a glance from a
| function signature which arguments are modified and which
| ones are just read. Without the abstraction of mutable
| and immutable references I would have to read the entire
| source code of the function and every function it calls
| to know for sure what it does with the pointers. It also
| brings me joy as a reader that common functionality like
| equality comparisons or string formatting can be derived
| by the compiler, instead of having separate hand-made
| implementations for each data structure, which might have
| subtle differences.
| steveklabnik wrote:
| Totally.
|
| I personally would not agree with
|
| > Languages with more powerful abstraction abilities
| bring joy to the writer but make things tedious for the
| reader.
|
| I find map/filter to be easier to read than a C-style for
| loop. Things that are conceptually denser make discussion
| between experts easier, even if it makes things harder
| for non-experts. This is why jargon exists, for example.
| dman wrote:
| Ah yes - that makes sense. I should have been more
| precise - I meant abstractions that allow you to add
| opaqueness (like macros and operator overloading). Again
| culture plays a role here too - some communities
| normalize such abstractions more than others.
|
| In short I believe languages that one can pick up in a
| couple of days and then read code where reasoning of the
| code is highly local would stand a higher chance of being
| perceived as simple.
| pron wrote:
| > Others believe that complexity inherently exists, and
| you can put it in the language, where a compiler can
| tirelessly check certain properties for you or a runtime
| can do magical complicated work on your behalf, or you
| can put it in the programs, where users have to check
| such things themselves.
|
| I think we'd all agree there's a spectrum, with, say,
| Assembly on one end and Idris on the other, where neither
| Zig nor Rust are near either extreme, and are actually
| rather close to each other. It's not a matter of
| accepting or rejecting a principle, but on picking
| _slightly_ different sweet spots (hopefully) on a
| tradeoff spectrum.
|
| Rust doesn't check at compile-time most things that
| _could_ be checked at compile-time. In fact both language
| check almost the same things at compile-time, and almost
| the same things at runtime. The design differences come
| down to one or two things that are clearly tricky and
| that neither language "does for you" -- i.e. you still
| need to think about them -- but are, indeed, checked in
| different ways.
| steveklabnik wrote:
| Yep. I agree they're closer to each other than the
| extremes for sure.
| paavohtl wrote:
| In my experience unsafe tends to be used really sparingly
| by most users, if at all. And besides, unsafe doesn't
| really turn off static checks - it allows you to do a few
| extra things that can't be proven to be safe statically,
| in tightly scoped specially annotated regions. It's
| mostly about bending the rules temporarily, for 1-5 lines
| of code at a time.
| dimitrios1 wrote:
| Side note: Nothing is provable in rust because it does
| not have a formal, verifiable specification. We have a
| reference implementation that we believe does the things
| it says it does on one particular architecture. But
| trust, not proofs, is indeed required. >:) (don't
| downvote murder me, I love rust)
| steveklabnik wrote:
| A subset of Rust has been formalized and proven, but
| you're right that we're still working on it.
| Arnavion wrote:
| Is char* c_foo(char* bar) { ... }
|
| simpler than fn rust_foo<'a>(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.
| steveklabnik wrote:
| (You have a tiny typo; you forgot the <'a>. Also, I know
| you know this, but for those that don't, this signature
| _could_ be written as fn rust_foo(a:
| &str) -> &str { ... }
|
| but Arnavion is trying to be explicit here to make a
| steelman.)
| Arnavion wrote:
| Yeah, I fixed that typo. And yes, foo is arbitrary, so
| one can assume it has another * / & parameter such that
| the lifetimes can't be elided any more.
| user-the-name wrote:
| You are talking about the simplicity of a line of code.
| The topic being discussed, though, was the simplicity of
| the _language itself_.
| Arnavion wrote:
| The simplicity of the language is directly correlated to
| the simplicity of that line. The fact that the language
| makes relationships between inputs and outputs explicit
| is a feature of the language, because of its borrow
| checker, at the expense of being syntactically verbose
| compared to C.
| user-the-name wrote:
| Not at all. A single line will use a tiny subset of
| language features. It will show you nothing about the
| overall complexity of the language, just about those
| things it happens to use.
| heavyset_go wrote:
| > _It seems, from looking at others ' code, that there is
| a very strong temptation to lean on `unsafe` instead of
| figuring out how to solve a problem within the
| constraints it normally applies._
|
| Are you sure those examples of unsafe Rust code were
| written using unsafe in order to work around safety
| constraints due to difficulty?
|
| I ask because there are some very real and valid use
| cases for unsafe code in Rust that have nothing to do
| with the fact that writing the code safely might be more
| difficult.
| mumblemumble wrote:
| Not sure at all - I have effectively zero working
| knowledge of Rust - and certainly not looking to second-
| guess people's motivations for using the feature.
|
| The big bias I'm working from here is that, as an
| outsider, I have a hard time reconciling all the big talk
| about how Rust makes it impossible to experience certain
| classes of bugs, with the existence of a known set of
| things that its type checker can't check, and which
| includes a lot of things that are difficult to avoid. One
| could be forgiven for thinking that the Rust community
| has a habit of keeping its fingers crossed behind its
| back when talking.
|
| I don't want to make the perfect the enemy of the good,
| of course. I realize the feature is there for an
| important reason. But it sure looks to me like Zig is
| also good despite being imperfect. Perhaps they're both
| similarly good languages.
| not2b wrote:
| Proper use of 'unsafe' in Rust is to write safe code that
| the compiler cannot prove is safe. In fact, this is done
| to implement many parts of Rust's standard library. See
| the split_at_mut example in
|
| https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
|
| The spec here is to turn one mutable slice into two non-
| overlapping mutable slices. The operation does not
| violate memory safety; we wind up with only one mutable
| reference to any part of the object. But the compiler
| does not know how to verify that the programmer has done
| this correctly. Here, 'unsafe' means 'I certify that this
| is safe, use that as a lemma to do further checking'.
| pjmlp wrote:
| All systems programming languages need the ability to do
| unsafe stuff, the big difference between C , C++,
| Objective-C and all the remaining system programming
| languages since JOVIAL and NEWP, is the explicit unsafe
| code blocks that make that visible.
|
| It is a big difference to have it on your face that
| something might need to be properly double checked and
| having each line of code as possible security exploit.
| jhgb wrote:
| > the big difference between C , C++, Objective-C and all
| the remaining system programming languages since JOVIAL
| and NEWP, is the explicit unsafe code blocks that make
| that visible.
|
| Would you consider Oberon to belong in the former or
| latter category? On one hand, there's no explicit code
| blocks as such (syntactically). On the other hand, unsafe
| primitive operations are limited to the SYSTEM module, so
| functions calling operations in the SYSTEM module can be
| considered doing unsafe things.
| pjmlp wrote:
| If you read Oberon documentation, modules importing
| SYSTEM are tainted and considered unsafe.
|
| Just like Modula-2 already does it.
| jhgb wrote:
| Well...that's what I meant. But which one is it, then?
| Ar-Curunir wrote:
| No type checker can catch all buggy programs (that
| involve solving the halting problem). In practice, Rust
| strikes a good balance: in over 120,000 LoC of Rust code
| that I have helped write and maintain, we have maybe 10
| lines of unsafe, with performance matching or exceeding
| that of the C/C++ counterparts.
| heavyset_go wrote:
| It might help to better understand the motivations behind
| unsafe Rust by reading some of The Rustonomicon[1].
|
| [1] https://doc.rust-lang.org/nomicon/
| AndyKelley wrote:
| > 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 it, which
| means building Zig projects will involve compiling more lines
| of Zig code, which means the Zig compiler must get faster,
| better at incremental compilation, and better at resource
| management.
|
| > Therefore, the package manager depends on finishing the Self-
| Hosted Compiler, since it is planned to have these improved
| performance characteristics, while the Bootstrap Compiler is
| not planned to have them.
|
| I can't help but mention, I am incredibly excited about how
| well the self-hosted compiler is coming along. Progress is
| swift, and all the ambitious design decisions (fully
| incremental compilation[1], extremely fast debug builds[2], low
| memory usage, multi-threaded) are intact. I anticipate it to
| make quite a splash once it becomes generally usable.
|
| I don't expect the package manager to take nearly as long to
| develop.
|
| [0]: https://ziglang.org/download/0.8.0/release-
| notes.html#Packag...
|
| [1]: https://vimeo.com/491488902
|
| [2]: https://twitter.com/andy_kelley/status/1416485475125141504
| cs702 wrote:
| _> ...I can assure you there is already a very large fire
| under my ass to get this shipped ... [followed by a short,
| easy-to-follow explanation as to why it 's taking so long]_
|
| I'm going to check out Zig because of your response.
|
| I love coming across comments like this one on HN.
| ljm wrote:
| Zig has been on my radar precisely because of Andrew
| Kelley's vision.
|
| I wrote about cross-compiling to a raspberry-pi and writing
| a barebones driver for an OLED display[^1]
|
| That was a lot of fun despite the fact the code was
| incredibly basic. The interop with C was effortless.
|
| [^1] https://www.kamelasa.dev/posts/gettin-ziggy-with-it-
| pi-zero....
| gravypod wrote:
| Will the compiler have something like go's ability to vendor
| code locally? I've worked on some science projects and this
| has been a hard requirement on some systems for tape archive
| storage.
| pryelluw wrote:
| How can I help?
| thechao wrote:
| > Progress is swift ...
|
| _ahem_
|
| > Progress is _zig_ ...
|
| Thanks for all your work! I ported a bunch of basic data-
| structures from C++ to Zig very early on (right as y'all
| began exposing generics). Even though the code no longer
| compiles, still worth learning The Zig Way(tm).
| zamadatix wrote:
| 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)?
| scrubs wrote:
| Folks, gotta like the sentiment and artifacts to back it up with
| here.
| yawn wrote:
| This post has a copy of an xkcd comic (https://xkcd.com/2347/)
| without linking back to it (https://xkcd.com/license.html). It's
| probably a mistake.
| hitekker wrote:
| > To improve our critical infrastructure we must improve the
| developer experience (DX) of systems programming, but rewriting
| everything is not the only answer.
|
| I like Kristoff from what I've read of him. He seems like a
| leader who will take responsibility and not shy away from hard
| decisions.
|
| On that quality alone, my money is on Zig winning systems
| programming over Rust in 10 years.
| 0xCMP wrote:
| You can build C projects using Rust and Cargo as well[0], but
| it requires more work than Zig appears to need.
|
| Rust also has good C FFI story and honestly I think we will
| still see a lot of important code rewritten in Rust.
|
| That said, a more ergonomic C which seamlessly replaces the
| often bloated build configuration of C/C++ projects while
| allowing a far nicer language to slowly replace the existing
| code feels like TypeScript for JS (which I consider a good and
| smart thing). Definitely agree it's going to get far more use
| than I'd originally have guessed.
|
| [0]: https://adventures.michaelfbryan.com/posts/how-to-riir/
| steveklabnik wrote:
| This is qualitatively different, that requires a C compiler
| to be installed. rustc cannot compile C code itself. zig can.
| xedrac wrote:
| When choosing between Zig and Rust for systems programming, I
| would reach for Rust most of the time. It's just a more
| expressive language with some seriously awesome compile-time
| guarantees. There are three things that bother me about Rust:
| bloated binaries, slow compile times, and dependency bloat
| (accidentally building 5 versions of the same crate). But
| seeing as it's being integrated into the Linux Kernel, I think
| Rust has a long and bright future in that space. Having said
| that, I think Zig would be a really great language for kernel
| programming.
| sandwichbop wrote:
| Interesting read and I agree that growth in technical debt is
| something to worry about. I want to get more involved and been
| trying my best to learn the skills needed but there's so much to
| consider that it's a bit overwhelming. I'm not familiar with Zig,
| it's neat that it has a toolchain that can compile C/C++ but it
| reminds me a lot of Nim. Could someone explain to me some
| differences between the two and why you would pick Zig over the
| other besides personal preference?
| cassepipe wrote:
| I'd say Zig wants is really serious on wanting to be a better
| C, that is have the same (better?) access to bare-metal, memory
| and bits but with a better type system and error management and
| without C's footguns and cruft (build system, memory errors,
| preprocessor). I don't know Nim that well but it seems more
| ambitious and seems to cater to be more "general purpose" if
| that means anything. For example there's no hidden flow control
| in Zig.
| habibur wrote:
| Nim is garbage collected, thus is a higher level language but
| doesn't fit the high performance low overhead of "systems
| programming" requirement.
|
| While Zig is manual memory managed like C and nearer to the
| core, but harder to program.
| sa1 wrote:
| With ARC, Nim's memory management would be closer to Rust
| than to Go.
| michaelsbradley wrote:
| I think the maintainers of Nim would disagree with your
| assessment given that the first sentence on the front page of
| Nim's official website is:
|
| _" Nim is a statically typed compiled systems programming
| language."_
|
| As someone else pointed out, when using Nim with its ARC/ORC
| and move semantics (which will eventually be the default),
| it's closer to Rust than to Go.
|
| That being said, Nim's current default GC does well for many
| kinds of workloads. If it's really causing a performance
| problem, it's possible to disable it and manage memory
| manually (or use a different language for the task at hand,
| of course).
| goodpoint wrote:
| Not at all: Nim always targeted system programming. Even
| before the new ARC/ORC, the GC was optional and done
| independently in each thread.
| pjmlp wrote:
| https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne.
| ..
|
| https://tinygo.org/
|
| https://www.ptc.com/en/products/developer-tools/perc
| nimmer wrote:
| Nim targets all the architectures that GCC targets, including
| less common microcontrollers.
| modeless wrote:
| If Zig can solve the C++ build system quagmire then I will love
| it for that reason alone, even if I never write a line of Zig for
| any other purpose.
| dnautics wrote:
| Zig is clearly leaning in hard to the E3 strategy!
|
| (embrace, extend, extinguish) for those not familiar
| deadwisdom wrote:
| 4x
|
| Explore, Expand, Exploit, Exterminate
| ynx0 wrote:
| based
| kristoff_it wrote:
| Not sure why people are downvoting. We all have our hidden
| agendas, mine is the destruction of all macros.
| jeofken wrote:
| What are compilers but advanced text macros?
| tialaramex wrote:
| 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
| ?
| dralley wrote:
| 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,
| PostgresQL, etc.
|
| There's plenty of innocuous activity that could be called E3 if
| you stretch the definition that far. Most of the GNU ecosystem
| for example.
| dnautics wrote:
| I'm not opposed to calling GNU E3. Basically no one uses unix
| or multics or whatever anymore.
| [deleted]
| vlovich123 wrote:
| > added a Rust dependency which in turn changed the list of
| supported platforms
|
| My understanding is that `zig cc`/`zig c++` are thin wrappers
| around LLVM, so doesn't that just reintroduce the same problem?
| williamstein wrote:
| 'zig cc' is more than that. You get a very powerful caching
| system, and built in support for cross compilation to a huge
| range of targets (via zig shipping with libc sources). Zig is
| extremely impressive.
| dleslie wrote:
| The built in cross compilation is just LLVM; it's a narrower
| set of targets than GCC, and a _far_ narrower set of targets
| than where you'll find a C compiler.
|
| clang cross compilation is not really any harder, you just
| supply the -target flag.
| messe wrote:
| > clang cross compilation is not really any harder, you
| just supply the -target flag.
|
| Yes, but it doesn't bundle and automatically compile the
| appropriate C library for the platform. Zig does.
| dleslie wrote:
| It can, if the package manager bundles it that way.
| Instead, clang is usually packaged and distributed as
| cross-compilation variants; because most of the time
| users don't need all of the different possible targets,
| they just want one or two.
| klyrs wrote:
| The benefit here is that zig is batteries-included. The
| fact that you can drive to the store and buy batteries if
| you need them is missing the point.
| AndyKelley wrote:
| Here's some relevant reading [1]:
|
| > If zig cc is built on top of Clang, why doesn't Clang
| just do this? What exactly is Zig doing on top of Clang to
| make this work?
|
| > The answer is, a lot, actually. I'll go over how it works
| here.
|
| [1]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-
| replace...
| steveklabnik wrote:
| llvm's platform support or the lack thereof was not the issue,
| it was assuming you had a compiler other than a C compiler
| installed at all on certain platforms. This would have affected
| zig in the same way, or any non-C language.
| kristoff_it wrote:
| Quoting a reply about this point I left in another comment
| thread:
|
| The point about the Python package example is not to say that
| Zig can get on platforms where Rust can't, but rather that the
| C infrastructure that we all use is not that easy to replace
| and every time you touch something, regardless of how decrepit
| and broken it might have been, you will irritate and break
| someone else's use case, which can be a necessary evil
| sometimes but not always.
|
| This is a point I made in the section of the blog post
| dedicated to explaining the limits or rewriting code.
| [deleted]
| skybrian wrote:
| Yes, if you exclusively use Zig to build the code. But on an
| platform that Zig doesn't support, you could write your own
| makefile instead to compile the C code with the native
| compiler, so the situation seems a bit better than with Rust?
| pharke wrote:
| 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 improvement and support. 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,
| after which I can clean it up and simplify it using the new
| features mentioned. Oh! and integrated unit tests and
| documentation generation are superb. Helpful error messages too.
| I could go on but I'd prefer everyone just try it out and see for
| themselves.
|
| https://dlang.org/
| jeofken wrote:
| For strings in C nothing beats SDS by antirez. So simple
| 10000truths wrote:
| 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 blocks make unit
| testing trivial to integrate.
| gavinray wrote:
| 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 interop with both C, and C++. Also, it's
| recently gained it's own C compiler, and can natively compile
| C code so that they are D objects, not just external
| definitions.
|
| - https://dlang.org/spec/interfaceToC.html
|
| - https://dlang.org/spec/cpp_interface.html
|
| It can even directly interop with C++ classes:
|
| - https://dlang.org/spec/cpp_interface.html#using_cpp_classes
| _... > the syntax was very easy for me to
| pick up as someone familiar with C/C++
|
| D is closer to C/C++ than Zig IMO. One of it's design goals
| is actually: "10. Where D code looks the same
| as C code, have it either behave the same or issue an error."
|
| And: "The general look and feel of C/C++ is
| adopted. It uses the same algebraic syntax, most of the same
| expression and statement forms, and the general layout."
|
| See: https://dlang.org/overview.html#goals
|
| I found Zig to be much less syntactically similar to C/C++
| than D. Zig felt more like a mix of Rust/Go.
| > the features it adds on top of C (e.g. slices, compile time
| execution)
|
| D also has slices and (outside of Lisp) was the first
| programming language I believe to introduce CTFE and CTFE-
| based metaprogramming. C++'s implementation as I understand
| it is essentially lifted from D.
|
| - https://dlang.org/articles/d-array-
| article.html#introducing-...
|
| - https://tour.dlang.org/tour/en/gems/compile-time-function-
| ev... > its translate-c utility works
| amazingly well at transpiling C code to Zig
|
| As stated above, not required due to ImportC, but there are
| several tools to automatically generate "extern" bindings to
| C/ObjectiveC/C++.
|
| You use these if you're linking with an external out-of-tree
| library, or a C++ library.
|
| - C, Limited C++ = https://dlang.org/blog/2019/04/08/project-
| highlight-dpp
|
| - C, Extensive C++ =
| https://github.com/Superbelko/ohmygentool
|
| - C, Objective-C = https://github.com/jacob-carlborg/dstep
| > its test blocks make unit testing trivial to integrate.
|
| Again, D also has this:
|
| - https://tour.dlang.org/tour/en/gems/unittesting
|
| =============
|
| Not trying to start a pissing match, because I actually think
| that Zig has a lot to offer as well -- but for these
| particular list of things, there's no clear winner here.
| pjmlp wrote:
| Me too, I really wished some nice corporation would give it the
| adoption boost it needs.
| gavinray wrote:
| 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/reasons (which I think ought to go somewhere official
| tbh, since that brief discussion in the above thread is the
| best + most succinct overview of it currently AFAIK)
| The reasons for ImportC are: 1. It's no longer
| necessary to translate .h files to D to interface with C. While
| doing the translations isn't hard, it is tedious, and if there
| are a lot of .h files it becomes a barrier. 2. .h
| files get updated over time, and correspondingly updating the D
| files is error prone. It's much more effective to just compile
| the new .h files. 3. It is not necessary to even
| create a .h file - just compile the .c file with ImportC and D
| will access it just like any other module. D will even inline
| the C functions in it. 4. Use it as a standalone,
| small and fast, C compiler.
| geon wrote:
| > once you learn JS you can do [...] video games (Unity)
|
| Not true. Unity once supported their own language based on Boo, a
| python dialect for the .net runtime, that they falsely advertised
| as "Javascript". That has since been depreciated.
| pjmlp wrote:
| Until Zig fixes the issues with use after free, it is hardly an
| improvement.
| wyldfire wrote:
| Can you clarify your point?
| sigzero wrote:
| Probably related to the following:
|
| https://github.com/ziglang/zig/issues/3180
| wyldfire wrote:
| Gee, IIUC it looks like it's been addressed by offering a
| new allocator that's able to detect use-after-free.
| kristoff_it wrote:
| To be fair this alone is nowhere near what Rust can do
| for you in terms of safety.
| ngrilly wrote:
| 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 memory leaks, use after free
| and so on.
| matu3ba wrote:
| 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.
| wyldfire wrote:
| But Zig makes this tradeoff intentionally. By design.
| kllrnohj wrote:
| "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?
| adamdusty wrote:
| You wouldn't because you already know Rust. The mental
| overhead of Zig is essentially zero if you already know
| C. Also, generics and other syntax is cleaner in my
| opinion, but that doesn't matter that much.
| matu3ba wrote:
| 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
| pjmlp wrote:
| So can debugging tools for C and C++ since late 1990's,
| zero progress there.
| clipradiowallet wrote:
| The article didn't tell me what Zig really was, so for other
| people in my boat: https://ziglang.org/
|
| headline from that website: Zig is a general-purpose programming
| language and toolchain for maintaining robust, optimal, and
| reusable software.
| ndesaulniers wrote:
| Replacing lld rather than add macho support send like a mistake.
| BiteCode_dev wrote:
| 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 ?
| dralley wrote:
| 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.
| amedvednikov wrote:
| 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
| ternaryoperator wrote:
| I too am surprised V does not get more attention here. I think
| the main developer frayed his ties with HN by some of his early
| claims. Nonetheless, he's doing good work moving V forward and
| developing community. [0]
|
| [0] https://vlang.io/
| torginus wrote:
| 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
| forbid on a different platform than the original author).
| adamdusty wrote:
| The build system for zig is essentially the same as CMAKE just
| in Zig and entirely undocumented.
| pjmlp wrote:
| I just build a VS solution, call MSBuild, install dependencies
| via NuGET/vcpkg and be done with it.
|
| And even better since they support binary libraries, I can
| focus on my own code instead of building the foundations first.
| [deleted]
| slimsag wrote:
| I totally 100% agree. "Getting started" with a C/C++ project is
| a huge pain and IMO where most people get stuck and give up on
| their weekend project.
|
| I'm working on a game engine in Zig[0], and I've been able to
| package up GLFW, write a build.zig file that `git clone`s all
| of the third-party system dependencies so that anyone can just:
| const glfw = @import("glfw/build.zig"); ...
| lib.addPackagePath("glfw", "glfw/src/main.zig");
| glfw.link(b, lib, .{});
|
| And have GLFW building (and cross-compiling!) for their
| project, without installing anything other than Zig and Git. No
| XCode. No `apt-get install ...`. Nothing. Just `zig` and `git`
| binaries. Zig is the C compiler and builds the GLFW source, and
| I have repositories with the required prebuilt system libs for
| cross compilation.
|
| [0] https://github.com/hexops/mach
| PaulDavisThe1st wrote:
| > the absolute insanity that comes with it's build
| systems/third party dependency management.
|
| Well yes, that would kill me too, if I actually expected the
| language to come with a single blessed dependency that
| addresses functionality <Foo>, that I will never want or need
| to patch the blessed dependency, and that there would be only
| one way to actually build a program or library.
|
| But it doesn't kill me because I don't expect either of those
| things.
|
| The dependency stack for my (21 year old) project consists of
| 86 3rd party libraries that on an x86_64 platform take up about
| 2GB after compilation. This is intimidating and sometimes
| painful, but I don't find it insane in any way. We have patches
| for a half-dozen of the deps that will never make it upstream
| and we have to be sure that we compile the libraries in the
| precise way that we need them (for example, we require the
| thread-safe version of libfftw, not the regular version).
| ndesaulniers wrote:
| Andrew, let me know if you want to try to compile the Linux
| kernel with zig cc. ;)
| dleslie wrote:
| The author seems to be under the impression that Rust cannot live
| harmoniously within the C ABI ecosystem, which is false.
|
| To some extent. Rust, due to relying on LLVM, is limited by its
| available targets; and so cannot enjoy the full access that C/C++
| can. The same is true for Zig, however, since it does not compile
| to C.
| kristoff_it wrote:
| > The author seems to be under the impression that Rust cannot
| live harmoniously within the C ABI ecosystem, which is false.
|
| The author is not under any such impression. The key point is
| that Zig can cross-compile C/C++ code, while Rust can't. If you
| have a Rust project that depends on C code, you will have to
| put in some work if you want to compile it for a different
| target.
|
| That's a pretty big difference in practice. The point about the
| Python package example is not to say that Zig can get on
| platforms where Rust can't, but rather that the C
| infrastructure that we all use is not that easy to replace and
| every time you touch something, regardless of how decrepit and
| broken it might have been, you will irritate and break someone
| else's use case, which can be a necessary evil sometimes but
| not always.
|
| This is a point I made in the section of the blog post
| dedicated to explaining the limits or rewriting code.
|
| > since it does not compile to C.
|
| Give it some time, it will.
| dleslie wrote:
| Zig itself doesn't cross compile C/C++ code, LLVM does the
| work for Zig.
|
| > If you have a Rust project that depends on C code, you will
| have to put in some work if you want to compile it for a
| different target.
|
| Rust is built on LLVM, and so its toolchain can also cross-
| compile C/C++ code. There are crates for that[0], and
| projects inspired by that idea[1].
|
| > Give it some time, it will.
|
| Given enough time mountains become valleys. Zig doesn't
| compile to C now; and won't be mature and field-tested for a
| decade or more.
|
| 0: https://crates.io/crates/cc
|
| 1: https://www.build2.org/
| steveklabnik wrote:
| You're splitting hairs in a weird way. rustc cannot compile
| C code. zig can. That they delegate to LLVM is immaterial.
|
| "This crate calls out to the most relevant compiler for a
| platform, for example using cl on MSVC."
| kllrnohj wrote:
| > You're splitting hairs in a weird way. rustc cannot
| compile C code. zig can.
|
| But why do I care? I don't use rustc directly, the build
| system of choice does. And very few of the major build
| systems have an issue handling multiple languages.
|
| Cargo (rust's build system) supports build scripts and
| the community has already created C/C++ compiler hooks
| such as https://github.com/alexcrichton/cc-rs
|
| rustup and cargo also provide easy cross-compilation
| support, too.
| steveklabnik wrote:
| You care because you need to have a c compiler installed,
| as well as the libc stuff... It is a giant pain to do so
| in some circumstances. One less dependency is a good
| thing.
|
| I quoted from cc's readme above.
| kllrnohj wrote:
| 100% of platforms that Zig & Rust run on already have a C
| compiler installed, though. A c compiler being present is
| the baseline assumption. If Zig existed in places C
| doesn't _and_ I wanted to write C for that platform then
| having Zig CC would be an advantage. But such a situation
| doesn 't currently exist and seems unlikely to ever
| exist? Especially in the context of a library/module
| porting _to_ Zig or Rust piecemeal, though, then I
| already obviously have a working C compiler & build
| toolchain in place since that's my start point.
| steveklabnik wrote:
| _you_ may have one. Not everyone does, or should. It is a
| _massive_ pain. See how many folks complain about various
| native wrapper packages in Python and Ruby for example.
| Someone even made a Python wheel wrapper for zig to make
| it easier to compile C extensions.
| kllrnohj wrote:
| Yeah it was a really odd choice of a "why not Rust" bug since
| the problem with Rust in that bug applies entirely to Zig as
| well.
|
| So if you can't use Rust because it doesn't have the broad
| compiler support that C does, you almost certainly can't use
| Zig either for the exact same reason. And then the article
| touts Zig using their own in-house linker, which seems
| inevitable to have less platform support than LLVM will? Zig
| isn't wrong for doing that, but you can't claim that's a
| benefit at the same time the problem with Rust is it's lack of
| fringe system support... :/
| kristoff_it wrote:
| > which seems inevitable to have less platform support than
| LLVM will?
|
| ZLD can link for M1 while LLVM can't yet. And Zig can also
| use lld alongside it to increase the platform coverage.
|
| > but you can't claim that's a benefit at the same time the
| problem with Rust is it's lack of fringe system support... :/
|
| I find it hard to believe that a dispassionate reader could
| misinterpret to this degree the goal of a sentence written in
| a chapter dedicated entirely to showcase the limits of
| rewriting code in another language, be it RIIR or RIIZ.
|
| See my reply to the parent comment for the intended meaning
| of that example.
| matu3ba wrote:
| yet.
| zamadatix wrote:
| One could say the same thing about Rust, and at least that
| language has hit 1.0.
| kristoff_it wrote:
| It's not just a random remark, the self-hosted
| implementation of the compiler which is being worked on as
| we speak (type?) has multiple backends, one being the C
| backend which will be used to simplify the bootstrap
| process of Zig.
| losvedir wrote:
| The build tooling of Zig is very impressive. I'm a sponsor of the
| project not necessarily because of the language itself, but
| because it surely has the potential to make waves in some way or
| another (edit: though the language itself is also quite
| interesting).
|
| One thing I wish the blog post had brought up is testing! Zig has
| some great tooling around tests, and that is something sorely
| lacking in a lot of C projects. If nothing else, you can pretty
| easily use Zig to simply write some tests for a C project! Even
| that would be a big improvement to the ecosystem.
| smasher164 wrote:
| What I don't understand is why Clang doesn't do this? What's
| stopping them from shipping libc's for cross compilation? Given
| that they are a C and C++ compiler, surely this is in their
| domain.
| matu3ba wrote:
| You need to provide low-level build functions, which is quite
| some work. On top of that you need to understand the build
| system of the libcs to replicate it. On top of that for libcs
| you want to deduplicate all symbols to reduce as much space as
| possible. On top of that you might want to provide glibc symbol
| versioning.
|
| People without incentive usually do not do this tedious kind of
| work, since "it works for me".
| fractalb wrote:
| If zig.build can alleviate the pain of building C/C++ projects,
| then it will surely to replace C in the future. So, IMHO, it's
| more important to get zig.build right than zig itself
| aninteger wrote:
| Aren't C projects relatively easy to build? C++ is a little
| more complicated, so there is more of a push for header only
| libraries there. I see the problem is probably with external
| libraries, but that is largely not a huge problem on
| Linux/Unix. Windows was more of a pain but msys/mingw
| alleviated most of it.
| woodrowbarlow wrote:
| not really, unless you're only building for one platform. gnu
| make isn't portable and doesn't have any real dependency
| management, so meta build systems quickly become a necessity.
| cmake is the most portable and the only real option on
| windows, but it's common to see projects that maintain
| support for both cmake and autotools.
|
| and that's ignoring the nightmare of cross-compiling with
| gcc.
|
| andrew kelley has talked about this[1]. his main point was
| about the number of dependencies you end up with compared to
| zig, where the standard library includes a high-level build
| system api. so your zig build scripts are written in ziglang
| and run by the zig compiler. no extra dependencies.
|
| [1] https://youtu.be/Gv2I7qTux7g?t=2120
| steveklabnik wrote:
| 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 "rewriting the browser". That's impossible. Put down the
| gun."
|
| Zig's cross compilation stuff and general compiler features, that
| this post talks about, is excellent, awesome, and makes me quite
| jealous frankly.
| kristoff_it wrote:
| Not sure if this transpired in the writing, but my
| interpretation of RIIR, partially informed by the chat with JT
| [0], is that this is a sentiment that I guess is there in some
| people, but that it was never something officially sanctioned.
|
| [0] https://www.youtube.com/watch?v=X7ny7Qrsbd8&t=5391s
| steveklabnik wrote:
| It is a weird self-fulfilling thing. People talk about it
| like it's a thing, so it's a thing, even if there's very
| little actual evidence of anyone sincerely holding this
| belief. People repeat that there's this plague of folks
| requesting that projects be re-written, and while it is
| literally true that I have seen two or three instances of
| this (you link to one of them, and notably it is not anyone
| harassing maintainers about their choices), it's been two or
| three.
|
| I actually got annoyed with this enough that I started doing
| a quantitative analysis; if you look at the canonical
| repository tracking this, it's got 44 total issues, most of
| which are jokes https://github.com/ansuz/RIIR/issues If you
| search GitHub for issues with these words in it, you get
| some, but many are either obvious jokes, people making issues
| on their own projects to think about doing this, and things
| like that. I never followed through on collecting it into a
| blog post though.
|
| I didn't think your writing was inappropriate at all; memes
| are memes, and I'm convinced that this one is just never
| going to die, because it's taken a life of its own,
| regardless of the underlying truth or not. It is always worth
| pushing back on this sentiment, even if I don't think Rust
| specifically tends to actually embody that sentiment very
| much.
|
| (Also: I don't know why you're now being downvoted. Hacker
| News works in mysterious ways.)
| hitekker wrote:
| As a counterpoint, I remember when someone satirized RIIR
| on HN and the post was flagged into oblivion even though
| the comments section was mostly approving.
|
| https://news.ycombinator.com/item?id=25198571
|
| Someone reposted the same document with Rust replaced with
| "$hotlang" which, for a reason you can guess, wasn't
| flagged at all:
|
| https://news.ycombinator.com/item?id=25208313
|
| My impression is that there are more than a few Rust
| developers who dearly believe in rewriting in Rust and were
| sincerely, bitterly offended by a joke to the contrary.
| geodel wrote:
| Agree with what you said. Another data point I noted how
| often popular Rust associated people hit Twitter whining
| about a disagreement they had on hacker news. I have
| almost never seen with other popular/mainstream
| programing languages. But for Rust it is regular thing.
| steveklabnik wrote:
| Oh I've been doing that since before Rust existed. And I
| assure you, complaining about Hacker News goes beyond
| Rust folks. Heck, even pg has complained about Hacker
| News on Twitter.
| steveklabnik wrote:
| See, I see that as the opposite: it is easy to get
| offended by the joke precisely _because_ it is not true.
| IMHO, the second version is _better_ because, by removing
| the language at hand, it directs the joke at the idea of
| re-writing everything in the first place, rather than at
| some specific niche of people who may or may not even
| actually exist.
|
| I could/would also get into a debate about "satire" and
| what exactly it is and means, but I have complicated
| feelings about it, how words change over time, etc.
| hitekker wrote:
| I think the seminal text on offense, jokes, and satires
| in the worship of programming languages is probably https
| ://web.archive.org/web/20061110043911/https://fluff.inf..
| .
|
| I've found it be to pretty useful in determining why I'm
| much more sensitive to things I care about than the
| things I don't, and particularly when jokes carry an
| element of truth that I cannot bear to acknowledge
| crazy_horse wrote:
| I'd never seen this, but it's too good. Thanks.
| tialaramex wrote:
| As a programmer I think it's notable that when I learned
| Rust I wanted to rewrite stuff in Rust.
|
| I rewrote 'leakdice' as part of learning Rust, so arguably
| that doesn't count (though I had never rewritten a program
| to learn a previous language), and 'misfortunate' wouldn't
| make sense in unsafe languages so that doesn't count
| either, but I then also immediately began rewriting 4store
| in Rust.
|
| I had never been compelled to rewrite stuff in other
| languages I learned. I am a compulsive programmer, so I did
| write stuff in languages I learned, (the other day I re-
| discovered, via an enquiry to a very old email address,
| that I used to know Scheme, as evidenced by the fact I
| wrote some Scheme that they were asking about from last
| century) but I didn't _rewrite_ anything until I learned
| Rust.
|
| C. Go. Python. Java. PHP. Bash. Perl. C#. Early C++. I'm
| sure there are many more. But always _new_ things, either
| because the language afforded something I hadn 't
| considered before or more often I wanted something and I
| chose a languages I knew would be able to achieve it.
| That's why I wrote some PHP less than a year ago, I'm not
| proud of that, but PHP got the job done so that's what I
| did. I can report that modern PHP is merely a bad idea,
| like Javascript, which I probably forgot to list above.
|
| Anyway with Rust I not only wanted to write new low-level
| code in Rust, I looked again at C programs I use and
| thought, "I should rewrite that in Rust". It felt like a
| good idea, and I expect to follow through on it at least
| somewhat, let's see how long 4store takes.
| kristoff_it wrote:
| Looking forward to when we get our own unfounded never-
| dying meme :^)
| crazy_horse wrote:
| Why does it matter?
| steveklabnik wrote:
| I think it matters less and less, which is part of why I
| didn't follow through on publishing.
|
| As to why it used to matter, well, it is _tremendously_
| difficult to bring a new programming language into
| popular usage, and even more in the systems space. It
| requires tireless effort by a large number of people. It
| is a very fragile thing. The stories we tell ourselves
| and others matter, and they influence what happens.
|
| That's all I'm willing to say right now :)
| mamcx wrote:
| I see it more like an _aspirational goal_. But one where
| everyone understand that is at most about start new projects
| that wholesome replace them (or "replace" is for create
| alternatives, not for truly rewrite the old ones).
|
| And I'm one that will be super-happy if all C/C++ code in the
| world dissapear now and be replace by
| Pascal/Rust/Zig/D/anything else that is better.
|
| MOST of my troubles are because C/C++. And the worst ones.
| Even if I 'm in a environment (business apps, ERps) where in
| theory system lang concerns are a distant worry.
| underdeserver wrote:
| I admire your use of special quotes to not break my mental
| parsing of your quote.
| steveklabnik wrote:
| Hilariously it was a copy/paste situation that I went "oh,
| that's kinda neat, I'll leave that" so I'm glad you noticed.
| (I am often guilty of nesting thoughts (inside of other
| thoughts) which is kind of amusing (even though I've never
| found lisps particularly easy to read)).
| wyldfire wrote:
| I think typical writing style guides suggest the single-
| quote for nested quotes.
|
| "I think he said, 'No way?! Zig for the win!'"
| [deleted]
___________________________________________________________________
(page generated 2021-09-08 23:00 UTC)