17 ms·

Zig: a system language which prioritizes optimality, safety, and readability

237 points by vmorgulis 10y ago

kennell 10y ago
This is interesting from a technical point of view, but looking at the Hello World example [0] really makes me wonder... who wants to write code like this? I have been a touch typer for half my life now, but things like > %% unreachable{}; > main(args: [][]u8) -> %void really make my fingers and eyes itch. [0] https://github.com/jmi2k/zig-playground/blob/master/src/hello_world.zig https://github.com/jmi2k/zig-playground/blob/master/src/hell...
- abricot 10y ago
  Try that on a nordic keyboard: % - SHIFT + 5 { - ALT + 7 } - ALT + 0 ; - SHIFT + , ( - SHIFT + 8 : - SHIFT + . [ - ALT + 8 ] - ALT + 9 ) - SHIFT + 9 > - SHIFT + < % - SHIFT + 5 Just for the bit you quoted.
- dilap 10y ago
  yeah i agree the specific choice of % seems unintuitive, ugly, not great to type, but i love the functionality...
- codygman 10y ago
  https://github.com/andrewrk/zig/issues/176 https://github.com/andrewrk/zig/issues/176
ocschwar 10y ago
Once you've made the decision to leave C for a systems programming project, why would one not just go over to Rust?
- quacker 10y ago
  Maybe easier integration with existing C libraries? They give an example of a tetris clone in Zig. This is how they include GLFW with Zig: https://github.com/andrewrk/tetris/blob/master/src/c.zig https://github.com/andrewrk/tetris/blob/master/src/c.zig and all other locations in the project just import this c.zig file. In contrast in Rust, I think you have to actually declare all the functions you want to use from a C library. For example: https://github.com/PistonDevelopers/glfw-rs/blob/master/src/ffi/mod.rs#L331 https://github.com/PistonDevelopers/glfw-rs/blob/master/src/....
  - tomjakubowski 10y ago
    There are C library binding generators for Rust which do the boring work for you. It's not perfect, but rust-bindgen was pretty good last time I tried it (~15 months ago): https://github.com/Yamakaky/rust-bindgen https://github.com/Yamakaky/rust-bindgen
    - skissane 10y ago
      When a language has built-in support for easy binding to C, that's a positive. When other languages such as Rust offer that feature through external tools, that's not as good, since I need to evaluate which of those external tools to use (when there is more than one), and it is something else to download/install/learn and another step to add to the build process. So it looks to me like Zig handles this better than Rust does (of course, Rust has clear advantages over Zig in other areas: much more mature / widely used, and more advanced memory management.)
    - ycombinatorMan 10y ago
      not nearly as attractive as inline C or direct C imports
      - deleted 10y ago
        [deleted]
      - Ygg2 10y ago
        Pfft, pretty sure you could inline C in Rust. No one was brave enough to develop said compiler plugin.
        Gankro 10y ago
        C++ close enough? https://github.com/mystor/rust-cpp https://github.com/mystor/rust-cpp
        Ygg2 10y ago
        Eh, C++ isn't really C :P I kid, it's really impressive work.
- c3534l 10y ago
  Yeah, I really hope Rust becomes the default C replacement. It's such a well-designed language, it's just very early in its development right now.
  - aninteger 10y ago
    Rust seems very complex and C is more about simplicity (in the sense that K&R is a short read). Other languages with the same spirit of simplicity would be Tcl and perhaps Go. I just wish Go had more supported machine architectures.
    - ocschwar 10y ago
      My feeling is that one should use Python or Go to prototype a program, and then move to Rust to make it systems-ready.
- andrewchambers 10y ago
  Yes. One flavour of icecream is all we need. (I hope people can see the sarcasm)
  - nickpsecurity 10y ago
    "My qbe C frontend is actually written in myrddin which is a lot like rust/ocaml. To be honest, C is not well suited to places where there is adversarial input such as servers, but when it comes to logical correctness of code I do not see amazing benefits from languages like ocaml." Did you mean two? Or did you come to new conclusions after that experience? Or did I misunderstand that entirely? ;)
    - andrewchambers 10y ago
      There ARE benefits to correctness from better languages, just not as amazing as people think. I'm just saying a vulnerability in C is just going to be an out of bounds exception in another language. both cases the code is not correct, one is just safer than the other when it comes to exploits. Keep making more languages, we can't know for sure if we don't try.
      - nickpsecurity 10y ago
        I can see where you're going but I don't think it's correct. There are clearly cases where an error will mess you up whether it goes as far as in C or not. Other times, the language or tooling prevents the error before runtime to ensure correctness. Are you aware of the benefits of Design-by-Contract (Ada/Eiffel), static proving (SPARK), or dependent types (ATS), though? The correctness criteria you can encode in them can straight-up prevent errors at interface or algorithmic expression levels. Three of these have been used for low-level code with two often in real-time and one for an 8-bitter. Depending on automation or interactive use involved, the errors caught at compile-time can increase pretty far past what a basic, low-level, type system can do. So, we already know we can knock out extra classes of errors with such languages. It was proven in theory and in the field. Using or improving them is just good engineering. We can also make more languages in trial-and-error discovery process to see if we find more benefits. Exceeding C's benefits, though, is already empirically proven to be worthwhile whether it's a Myrddin, a SPARK, or an ATS.
- DSMan195276 10y ago
  I've thought alot about this before. Rust doesn't really have very great interoperability with C - most languages really don't, because the API for C programs revolves around functions, structs, macros, etc. Most languages can only really get part of that, and then the rest gets essentially a separate implementation in the language you're porting too - leading to a certain amount of manual duplication and intervention necessary (We don't call it porting when you use a C library in C). Design goals Rust has made compound the issue a bit more: For example, Rust uses the C++ ABI, not C. Rust can't generally use header files directly. The Rust<->C conversion loses a lot of information and can result in fairly messy code by Rust standards, etc. This makes combining Rust into already existing C code a hassle, as it is generally worse then even just trying to use C and C++ together which is already fairly annoying and error-prone. This is compounded by Rust's safety goals which generally require a different design to a problem then the "C-style" approach would be - IE. You're probably not going to get good Rust code by simply replacing a .c file with a Rust file, because the entire time you're going to have to make use of the unsafe C functions that your program includes. Perhaps the bottom line is that (for good reason) Rust is much more then just an improved C. And because of that, combining C and Rust is always going to feel like combining two separate systems together with a compatibility layer in-between - because that's really what it is - and that's just not very attractive. I know little about Zig (I'm reading about it for the first time now) and don't at all predict it to replace C. That said, I would love a language which has a focus on maintaining very good compatibility with C while fixing the various pieces of its design that are fixable within the bounds of the language. For example, I noticed it mentioned in the README that in Zig that pointers are nonnull by default, and can be made nullable by adding the 'maybe' attribute. This is a feature I would love in C, but really isn't there (gcc has a nonnull attribute, but it is really essentially useless and nothing like you'd want). Essentially, I would like a language where it feels like writing code for the same system, but in a different (better) syntax - where I can drop it into a project and it works together with the system like any other .c file (Though with a different compiler, obviously), but the code inside is much better then what you can do in standard C. I think that such a language could retain the reasons why people (like me) still like C, while fixing a lot of the uglier sides to the language that everybody is aware of but aren't going to get fixed any time soon. And perhaps most importantly, I think such a language is definitely possible (Though it may not be able to employ all the features you may want) - but I don't have the time nor probably the skills to really do it well besides list off the things it should fix and shouldn't fix. As for starting a project though, if you ignore difficulty to learn then I would agree with you: There's probably little reason not to just go for Rust if you're already willing to learn a new language. For most projects the issues I outlined above don't really matter assuming the entire project is written in Rust - besides the want for a language closer to C in design. That said, I readily concede that I have no idea if Rust's borrow-checking semantics could ever work without the extra features they added that take the design away from being 'C-like' - and considering that's one of the definitive features of Rust, is easily worth losing the 'C-like' detail if it is necessary. But when considering a project like the Linux Kernel, the GNU coreutils, git, GTK, and other various large projects where conversion to Rust is probably impossible without a complete rewrite, being able to use a 'better' C while still retaining the aspects that people like would probably be a nice step in the right direction. The chances of it happening are nil, but it would still be a step in the right direction.
- daurnimator 10y ago
  One of my biggest reasons is the lack of ability to handle OOM when using the standard library. see e.g. https://internals.rust-lang.org/t/could-we-support-unwinding-from-oom-at-least-for-collections/3673/17 https://internals.rust-lang.org/t/could-we-support-unwinding...
  - whyever 10y ago
    How can you handle OOM if your process gets killed by the kernel for using to much memory?
    - daurnimator 10y ago
      By never going that far. Turn off overcommit; I advise to never run with it in production.
- teacup50 10y ago
  Among other things, systems programming projects generally require stability of language syntax, API, and ABI. In terms of ABI stability, Rust has none. In terms of API stability, they seem willing to drop features within a major release cycle or two. In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x). Rewriting for the sake of language updates is a huge resource drain when you're talking about code bases with lifetimes that are likely to be longer than their authors'. For reference, just about every major shipping OS contains significant LoC dating back to the 70s or 80s.
  - Gankro 10y ago
    > In terms of API stability, they seem willing to drop features within a major release cycle or two. I don't think any feature/api that was at one point marked as stable post 1.0 (when they started making any guarantees) has ever been removed. > In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x). While it's true that 2.x has the rights to break everything, this is incredibly dishonest to state in a vacuum, because it's a well established point that 2.x should never exist. The devs want all code to work forever, and only a catastrophe would push them to pull the lever. They have of course reserved the right to require fixes in special cases -- e.g. fixing a bug in the type checker might break some code, and that's acceptable. Although even then they'll try to phase in the fix over a few releases. Every release is tested against the entire crates.io ecosystem to try to catch these regressions. You are absolutely correct on ABI stability, though.
    - teacup50 10y ago
      Given the litany of deprecation markers applied to existing APIs, one must presume the intention of removing them, no?
      - Manishearth 10y ago
        Not necessarily. I suspect even in the case of 2.0, most if not all of those apis will survive. Deprecation markers exist to encourage people to use newer, better APIs. I suspect that even if 2.0 happened, the only apis that would be removed would be ones that we're reasonably sure nobody uses (via crater), and even then there would be debate. And like Gankro said, 2.0 is a thing that's not supposed to happen in the first place.
- Koshkin 10y ago
  Rust? Maybe. But then, why not Go or Swift or Lisp? Personally, if I were to be expelled from C/C++ paradise, I would try Oberon - the only language I know that can compete with C in its simplicity and, despite normally being perceived as garbage-collected, the ability to serve as a truly systems programming language.
  - mordocai 10y ago
    As far as vs Go or Swift or Lisp, Rust is much "closer to the hardware"(as discussed in other threads nothing is really close to the hardware anymore) than the other languages, go and most lisps use GC which causes problems in many systems language situations, and last I heard swift still has lackluster cross platform support. I don't really know anything about Oberon so can't speak to that. P.S. Personally, all my hobby projects are in lisp. I write applications though, not system stuff.
    - pjmlp 10y ago
      Oberon was used for writing a complete graphical workstation OS used during the mid-90 at the ETHZ in Switzerland. It was a language and OS, following the same spirit of Xerox PARC OSes.
    - nickpsecurity 10y ago
      The A2 Bluebottle OS is latest incarnation of Oberon OS with GUI and very responsive. Languages like Oberon can do unsafe stuff for low-level work like OS's. You just use manual, memory management and UNSAFE keyword. Rest that can be GC'd, bounds-checked, etc is by default.
  - ziotom78 10y ago
    A few months ago, I considered Oberon as a viable alternative to C for my pet projects. Horace, after some time spent playing with it, I was scared by a fewserious limitations: (1) there is no support for UTF-8 strings, native strings are just sequences of ASCII characters, (2) lack of libraries and available bindings (e.g., SQLite, GSL, FFTW...), (3) scarcity of tools like package managers and Doxygen-like tools, (4) very few resources available on the web (Wirth's book is exceptional, but it does not cover use cases that are common in 2016.)
gragas 10y ago
Obligatory: why is Zig meant to replace C? Why is it a better replacement than Rust (when Rust is considered a C replacement)? Interesting work nonetheless.
- parenthephobia 10y ago
  I'd rather use Zig than Rust because I wouldn't have to learn about how to work with Rust's memory management model. Even though I understand Rust at a technical level, actually getting my brain to work that way has proven difficult. Being able to directly import existing C header files is also attractive. Having said that, I'd rather Zig had been Go-inspired than Rust-inspired. Go plus Zig's approach to generics and error handling would be nearly perfect! (Notwithstanding that Zig's error handling is basically Rust's with added syntax sugar!)
z0xcd 10y ago
One question: Why is Zig implemented in C++? What was the reason behind the choice?
- AndyKelley 10y ago
  It's mostly C, with some templates sprinkled in. Zig depends on libclang and LLVM. Both of these are C++ APIs. Both expose a C API wrapper, but with not all features exposed that zig needs to use.
yyhhsj0521 10y ago
Is Zig compatible with C? No? End of the story. Edit: I know that you can include a C header in Zig, and cross-compilation is possible and made easy. But you can't continue develop on current C projects if you switch to Zig. I guess that you have to change the Makefiles too.
- parenthephobia 10y ago
  But... Zig is compatible with C. It goes to some lengths to make sure of it.
  - emmelaich 10y ago
    I guess @yyhhsj0521 means source compatible. Which was my thought too. I mean, as source compatible as possible; which may not be much.
  - ajarmst 10y ago
    Unfortunately, that tends to demand the observation that C is really compatible with C.
parenthephobia 10y ago
Syntax looks very Rust-inspired, but it lacks Rust's OCD. I also catch hints of other syntaxes, like Ruby/Smalltalk-style block parameters, and a defer very much like go's. I find it interesting that it implements generics by passing types as normal arguments. Say, `list(i32, 1, 2, 3)` rather than `list<i32>(1, 2, 3)`.
- dilap 10y ago
  i love this
necessity 10y ago
Don't fix what's not broken.
- theoh 10y ago
  I apologize in advance but... "necessity"... Surely not THE "necessity", mother of invention? I guess that would absolutely give you a veto on other people "scratching their own itches". Snark aside, the issue is surely whether, if designing C now, the last 40 years of programming language theory would not have some impact.
- adamnemecek 10y ago
  C isn't broken?
  - necessity 10y ago
    Why would you think it is?
    - adamnemecek 10y ago
      Not memory safe, bad type system, terrible 'macro' system, no/minimal(C11) support for generics, minimal standard library, pretty verbose (it's hard to build any good abstractions), lack of functional programming support, undefined behavior. Dealing with dependencies and headers in any but the simplest of projects gets old really quickly. Just about bigger project I've seen abuses the language to some extent. The list goes on and on.
- wolf550e 10y ago
  Basically every deployed C codebase contains "undefined behavior".
  - necessity 10y ago
    Which is intended. Suggested reading: http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/213
sotojuan 10y ago
Cool to see a fellow Recurser in HN!
qwertyuiop924 10y ago
The thing is, you will never replace C. Supplement it, extend it, yes, but not replace it The fact is, C is still probably the lowest level HLL still used. It's the lowest level you can be, while still providing the HL constructs we're all used to. There is always going to be code that wants or needs to be there. Code where anything further up either can't give the performance, or provides impedance to the design or actual goal. You still want to replace C? Fine. What will you write your bootstrapping compiler in? :-D.
- lifthrasiir 10y ago
  > You still want to replace C? Fine. What will you write your bootstrapping compiler in? :-D. There are several examples of language implementations that are built directly from machine code incrementally. (In that case, the "bootstrap" happens via an already-built compiler of the previous version, or of the same version in the different architectures.) Also, you don't strictly need C for the bootstrapping compiler... Rust's one was OCaml for example.
  - qwertyuiop924 10y ago
    And what's OCaml written in? How about the assembler? If you really want to replace C, You'll need to be able to compile the language without ever having C on your system (at least, in theory). This is almost impossible, although you can do it, if you slowly work towards it.
    - ajarmst 10y ago
      That's not really fair. If you go far enough back in the ancestral compiler list on any language, you'll probably hit C. You'll definitely hit hit assembly and bare-metal machine code. Heck, at some point you might run into hand wire-wrapped microcode---but I don't think that's an argument that we should be using it. That's just an artifact of the history of operating system development, and the fact that C spent (is spending) a considerable period as the de facto standard for OS development. That it was first doesn't necessarily make it better. A few events turning out differently in history, and you'd be making the exact same arguments about lisp, BCPL or Fortran.
matthewhall 10y ago
Not with that logo it won't.
- AndyKelley 10y ago
  hahaha. I would gratefully accept an improved logo if anyone is willing to take the time to make one.
  - majewsky 10y ago
    You still have a few hours to submit Zig into https://news.ycombinator.com/item?id=12372118 https://news.ycombinator.com/item?id=12372118
girvo 10y ago
Interesting language. Somewhat reminds of me "ooc"[0], though I believe ooc is ref-counted/garbage-collected (? I think. I can't remember, been a while since I've touched it); but being able to easy use C libraries from a relatively low-level language that has nicer high-level constructs is still a beautiful idea, in my opinion. The language I'm using these days for that exact feature set though is Nim[1] -- being able to use {.compile.} pragmas and bring in header/source files, along with the great C type support is wonderful; but again, garbage collector (albeit one that can be tuned and/or turned off). Zig seems to be targeting the "true C replacement" niche, which I'm going to have to keep an eye on! [0] http://ooc-lang.org/ http://ooc-lang.org/ [1] http://nim-lang.org/ http://nim-lang.org/
CaliforniaKarl 10y ago
I don't know. C is very close to the hardware, and it's pretty portable, too. I'd suggest doing what some other languages do, and get yourself to the point where almost all of the code for Zig is written in Zig. In other words, you'd first write a `microzig` that's written in C++, and microzig knows enough to make `minizig`, which knows enough to make the rest of zig. This is what Perl does, and I expect other languages do the same thing. On the other hand, zig is supposed to be able to cross-compile really well, so maybe you can skip that: Have version 0.9.9 be the last version written in C++. Then, for version 1.0, re-write the entire toolchain in Zig, and use the 0.9.9 compiler to compile Zig 1.0. At that point you are in full dogfood mode. Finally, since it's called Zig, I get to close with this sentence: "You have no chance to survive make your time."
- toomanybeersies 10y ago
  AKA Bootstrapping: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
- dllthomas 10y ago
  > C is very close to the hardware At this point, I'd more say that the hardware does an awful lot of work trying to look like it's close to C.
  - bradhe 10y ago
    It's an interesting phenomenon, specifically how processor companies (erm, Intel), who make "general purpose" CPUs, have clearly made trade offs to optimize for OSes that behave like UNIX or Windows varients!
    - dbcurtis 10y ago
      Well, in fact, Intel and all the other major makers spend a huge amount of effort benchmarking important workloads. It isn't a decision to optimize for Unix or Windows, it is a decision to chase dollars. They will optimize processors for your favorite workload, too. Just demonstrate how many millions of dollars of business your workload represents, and create some sound benchmarks for it. Easy.
ajarmst 10y ago
Intend in one hand, and ... well, you get the picture.
wyager 10y ago
> Maybe type instead of null pointers. It's often a bad sign when a language advertises this high up on its features list. It means that they didn't really get the true takeaway of the Maybe type (which is that you should support algebraic data types to properly constraint data to valid states), but instead saw a single specific use case of ADTs (Maybe) and thought that's all there was to it. I've run into this with Java 8. Optional is pretty common now and has eliminated the need for the null pointer in much of everyday code, but they still don't have something like Either to eliminate the need for exceptions. Maybe is extremely useful, but it's a small fraction of the usefulness you get with true ADT support.
- AndyKelley 10y ago
  Zig also has algebraic data types.
  - fspeech 10y ago
    Are they ML like ADTs with pattern matching? That would be awesome.
  - wyager 10y ago
    Any examples? There were none at OP's link.
Gankro 10y ago
I can't seem to find any details on safety other than > Safe: Optimality may be sitting in the driver's seat, but safety is sitting in the passenger's seat, wearing its seatbelt, and asking nicely for the other passengers to do the same. Is Zig memory-safe? How? (Specifically, is there some useful safe subset ignoring the obvious FFI and "explicitly unsafe operations" exceptions every language gets?) If it's not, is that even a goal?
- AndyKelley 10y ago
  It's not memory safe. There is some compile time safety and some runtime safety, but it's not comprehensive. Nullable pointers are handled by the type system at compile time. Integer wrapping (signed or unsigned) will crash at runtime, unless you use explicit wrapping operators. Array out of bounds will crash at runtime for slices. There is no direct pointer arithmetic, but you can convert a pointer to a slice, and then index into the slice (which has array bounds checking). This is an example where the language is unsafe but it sort of guides the programmer into writing safe code.
  - Gankro 10y ago
    Not being memory-safe is a bit of a bummer. Do you have a story for taking advantage of all the tooling thats been built up to defend against C's pervasive unsafety? Sanitizers being the most notable. On balance even without them this'll probably be safer than C (as long as you're avoiding like, 90% of its pitfalls). Either way, hope this works out for ya!
Koshkin 10y ago
C is beautiful in its way and it is rather minimalist from the syntax point of view (especially the pre-C99 variants). Judging by the code examples shown on the page, this new language has a pretty noisy (compared to C, downright ugly) syntax. Granted, it may be dictated by some logic and possibly even its inner beauty, but on the surface it does not seem to be much of an improvement compared to the languages we already know and love (or love to hate), including Perl and JavaScript.
kzhahou 10y ago
Almost half the comments here are just to remind everyone that C can/will never be replaced. Is that really the most insightful we can be? Is HN so pedantic now that we can't analyze an interesting language idea, but just nitpick at its existence?
- AndyKelley 10y ago
  My plan to replace C is simple and pragmatic. 1. Make a language and compiler that fills the same niche as C but does it significantly better, taking into account all the lessons we've learned in the last 44 years. 2. Make a build tool that competes with autotools, cmake, make, etc. Similar to Python build.py, you'll have a build.zig, import a library and use it. The library does everything configure/make does except better. 3. Package management on par with NPM and Cargo. Minimal overhead to publishing reusable code. Although I don't plan to have a central repository, rather the ability to put a URL or source control URL with a hash. 4. Zig can import and export .h files, and you can target .o files that are compatible with the rest of your C codebase. 5. Now there is minimal cost to replace bits and pieces of your codebase with Zig.
  - versteegen 10y ago
    Plenty of us know it can be done, and is an extremely worthwhile goal; keep up the fantastic work! Zig may be the language I've been waiting for, so I'll make it the next language I learn, although I realise it's not even reached a first release.
  - ashitlerferad 10y ago
    Don't forget item 6, which is quite essential: 6. Talk about Zig at conferences and promote it in other ways
  - otabdeveloper1 10y ago
    Points 1, 4 and 5 are exactly the same in C++ too. What makes you think you can do better than the guys who are driving C++ development? (Honest non-rhetorical question.) Points 2 and 3 don't really belong in a programming language.
fspeech 10y ago
The first thing I would want to use something like this for is to write C API for a C++ library. Is that possible with the current state of Zig?
- AndyKelley 10y ago
  I think the best language to do that in is C++. You write a C .h file, and then a C++ .cpp file that implements the C functions using the C++ API. Zig doesn't know how to use the C++ ABI. It's pretty complicated.
  - fspeech 10y ago
    You are right that C++ methods need to be invoked in C++ code. However C container types are too weak/inconvenient to wrap C++ code. I am wondering if something like Zig can be used to create STL like containers that can be used at the API level?
adrianratnapala 10y ago
Well I am impressed. And I am very glad to see more and more languages in this space. I particularly like that Zig seems to be minimalistic -- a lot more fun to look at (for me) than C++ or Rust. But I didn't see anything in Zig similar to Rust's lifetimes. Well it's nice to be rid of that complexity, but I don't see how you are going to do C-like pointer stuff safely without them. Can anyone explain what these languages (e.g. Zig, Myrddin, Nim) do instead?
- steveklabnik 10y ago
  Nim has a GC. Myrddin doesn't, but I can't quite remember what it does for safety, if anything. The language spec does say "pointer arithmetic is not allowed." For Zig, see here: https://news.ycombinator.com/item?id=12380078 https://news.ycombinator.com/item?id=12380078
dsego 10y ago
This man is a prolific genius. http://genesisdaw.org http://genesisdaw.org http://libsound.io http://libsound.io http://groovebasin.com http://groovebasin.com
- a-nikolaev 10y ago
  Yeah, he is awesome~ cannot upvote this twice. And I think, his design decisions are very clear and straightforward too.
pmontra 10y ago
How is the goal of readability being addressed? I didn't find it particularly readable. Basically it's C with better types. A few suggestions about the syntax, based on what many languages did in the last 25 years. 1) No mandatory () around conditionals. Make {} mandatory even for one liners instead. They remove bugs and are a common suggestion in the style guides of several languages. 2) The multine string syntax is verbose and uninviting. Use heredocs or a string delimiter reserved for that purpose. 3) Try to do without the ; line terminator As a huge bonus, to reduce clutter, try to implement automatic import. I don't know of any language doing it, it's IDE territory right now (or editor's [1]). Still it's very useful because there is little as boring as going through a long list of imports at the beginning of each file. They should be there only when there is an ambiguity to resolve. About readability, those {var v; while (cond) {}} blocks in the examples are puzzling. Finding a }} alone on a line was an "is this a syntax error?" moment, or just bad style. Anyway, it seems to have generics so it's already ahead than Go, which seems to be stuck in the 60s regarding this feature (they've been pioneered by ML in 1973 according to [2]). For the rest, it's in the average of what we've seen in the past decades, so not shiny but not bad. Plenty of successful languages are like that and maybe it's a reason for their success: being average they don't scare away people. I'm thinking especially of Python, which smells oddly of C with its __underscores__ and the explicit self argument, reminding me of how we used to do OO in C passing around struct pointers (those structs were the objects, holding data and function pointers to methods). [1] http://www.vim.org/scripts/script.php?script_id=325 http://www.vim.org/scripts/script.php?script_id=325 [2] https://en.wikipedia.org/wiki/Generic_programming https://en.wikipedia.org/wiki/Generic_programming
- tom_mellior 10y ago
  One more syntax issue: http://andrewkelley.me/post/intro-to-zig.html http://andrewkelley.me/post/intro-to-zig.html shows the const number = parse_u64(str, 10) %% |err| return err; pattern and then goes on to say that you can avoid repeating "%% |err| return err" all the time by writing const number = %return parse_u64(str, 10); instead. I don't think that's particularly nice; it looks too much like "return the result of the call" when that's only what happens in the error case. I would have expected something more like this: const number = parse_u64(str, 10) %% return error; where the compiler would turn "return error" into "|_some_var| return _some_var".
web007 10y ago
return if (value >= radix) error.InvalidChar else value; That is just painful to parse. Suffix-If sometimes makes sense and simplifies things, but it always makes code flow more difficult to understand.
- perfunctory 10y ago
  I don't think this has anything to do with "suffix-if".
  - majewsky 10y ago
    Yeah, that's just if as an expression, replacing the ?: operator. Compare to return (value >= radix) ? error.InvalidChar : value;
    - naasking 10y ago
      I actually prefer a ternary arrangement that lets you chain arbitrary such expressions like a truth table: return (value >= radix) ? error.InvalidChar: (comeCondition) ? error.OtherError: ... value;
      - drjeats 10y ago
        I like doing that too, but the Zig syntax doesn't prevent that kind of arrangement, just makes it a bit wider. return if (value >= radix) error.InvalidChar else if (comeCondition) error.OtherError else ... value; or maybe this, but it seems uglier to me: return if (value >= radix) error.InvalidChar else if (comeCondition) error.OtherError ... else value;
  - web007 10y ago
    True, which only makes my poorly-targeted point on bad parsability. Reading the code requires backtracking around a conditonal control statement, and in a format more verbose than ternary. Most places I've worked have bans or limits on ternary to single boolean cases for the same reason: It's hard for people to understand the control flow of operations around conditional assignment. A new language that lets you perpetuate painful code isn't helping as much as it could. It's much simpler for people to parse the more verbose case with an IF and two return blocks, and the compiler shouldn't care since it can generate the same code either way.
lisper 10y ago
You lost me at hello world. Or maybe I should say you lost me @ %hello %%world. If you want to prioritize for readability the first thing you have to do is get rid of all that weird non-standard punctuation.
- codygman 10y ago
  https://github.com/andrewrk/zig/issues/176 https://github.com/andrewrk/zig/issues/176
deleted 10y ago
[deleted]
wmu 10y ago
I would love to see a comparison to C, C++, Ada, Rust, maybe Cyclone. After reading the page I can't find an answer why Zig is better than any of established languages. (Haven't read comments yet) Speaking of readability... well, still smells like C. And multiline string syntax is weird. :)
dschiptsov 10y ago
Modern amateur language designers usually are not aware of decades of research and breakthroughs in old-timer's languages, such as Algol, Scheme, Common Lisp, Standard ML and recently Haskell. They miss the beautiful specialized syntactic sugars in Standard ML (for defining and calling curried functions), Octave/Matlab matrix syntax, and the beautiful Common Lisp's looping and SETF macros, which inspired Python's for loop syntax for iterable collections and assignment operator overloading. Instead of spending time to learn and understand pros and cons and nuances they rush headlong to implement everything from scratch. Really smart guys, however, are trying to leverage old-school languages, to climb on the shoulders of Titans. David Moon created the PLOT language that leverages Lisps http://users.rcn.com/david-moon/PLOT3/ http://users.rcn.com/david-moon/PLOT3/ , Rich Hickey did almost the same with Clojure. Scala has been a leverage of Standard ML, similar to Ocaml. Now Swift is trying to distillate Scala, at least in terms of standard idioms and syntax choices. Julia has been build upon the big ideas from CLOS. Python incorporated lots of good ideas and bits of syntax and managed to balance the syntax and unify semantics and since 3.5+ earned reputation of a well-designed language (clear, balanced, complementing each other semantics from the Lisp world, and carefully chosen syntax). It is also famous for its culture. So, for those who wish to change the world by developing a new language, it might be a good idea to look at Standard ML and its derivatives and try to relax some constraints and balance the syntax according to modern conventions. I personally would prefer to start from David Moon's PLOT3 and, perhaps, try to marry it with some lightweight type-system based with optional annotations. Btw, Haskell's choice of not mixing type information and function definitions and use annotations with its own DSL for types is a really big idea. It reduces cognitive load, makes code extremely readable, and in general, it seems, the best of both worlds. Python's optional type annotations are clever, but less elegant.
renox 10y ago
While I find interesting the idea of a new C (instead of a new C++ like D, Nim, etc), I'm a bit sad that there is both the Zig AND the Jay projects.. It reminds me why Pascal lost (IMHO): too many incompatible Pascal 'clone'.
Matthias247 10y ago
Error handling mostly with error codes seems like an OK compromise for me since it doesn't require any dynamic memory allocation (like Gos error interfaces). I guess one would use some custom return type or a GetLastError equivalent if more details are required. However I'm not sure if purely compiler assigned error numbers will work out for a systems language. Of course it works when you build the whole application, but if you build only a part of it (a library, an application that (dynamically) links against a library, ..., where do you get the information from which error codes are already occupied by them?

237 points by vmorgulis 10y ago

This is interesting from a technical point of view, but looking at the Hello World example [0] really makes me wonder... who wants to write code like this? I have been a touch typer for half my life now, but things like > %% unreachable{}; > main(args: [][]u8) -> %void really make my fingers and eyes itch. [0] https://github.com/jmi2k/zig-playground/blob/master/src/hello_world.zig https://github.com/jmi2k/zig-playground/blob/master/src/hell...

abricot 10y ago
Try that on a nordic keyboard: % - SHIFT + 5 { - ALT + 7 } - ALT + 0 ; - SHIFT + , ( - SHIFT + 8 : - SHIFT + . [ - ALT + 8 ] - ALT + 9 ) - SHIFT + 9 > - SHIFT + < % - SHIFT + 5 Just for the bit you quoted.
dilap 10y ago
yeah i agree the specific choice of % seems unintuitive, ugly, not great to type, but i love the functionality...
codygman 10y ago
https://github.com/andrewrk/zig/issues/176 https://github.com/andrewrk/zig/issues/176

ocschwar 10y ago

Once you've made the decision to leave C for a systems programming project, why would one not just go over to Rust?

quacker 10y ago
Maybe easier integration with existing C libraries? They give an example of a tetris clone in Zig. This is how they include GLFW with Zig: https://github.com/andrewrk/tetris/blob/master/src/c.zig https://github.com/andrewrk/tetris/blob/master/src/c.zig and all other locations in the project just import this c.zig file. In contrast in Rust, I think you have to actually declare all the functions you want to use from a C library. For example: https://github.com/PistonDevelopers/glfw-rs/blob/master/src/ffi/mod.rs#L331 https://github.com/PistonDevelopers/glfw-rs/blob/master/src/....
- tomjakubowski 10y ago
  There are C library binding generators for Rust which do the boring work for you. It's not perfect, but rust-bindgen was pretty good last time I tried it (~15 months ago): https://github.com/Yamakaky/rust-bindgen https://github.com/Yamakaky/rust-bindgen
  - skissane 10y ago
    When a language has built-in support for easy binding to C, that's a positive. When other languages such as Rust offer that feature through external tools, that's not as good, since I need to evaluate which of those external tools to use (when there is more than one), and it is something else to download/install/learn and another step to add to the build process. So it looks to me like Zig handles this better than Rust does (of course, Rust has clear advantages over Zig in other areas: much more mature / widely used, and more advanced memory management.)
  - ycombinatorMan 10y ago
    not nearly as attractive as inline C or direct C imports
    - deleted 10y ago
      [deleted]
    - Ygg2 10y ago
      Pfft, pretty sure you could inline C in Rust. No one was brave enough to develop said compiler plugin.
      - Gankro 10y ago
        C++ close enough? https://github.com/mystor/rust-cpp https://github.com/mystor/rust-cpp
        Ygg2 10y ago
        Eh, C++ isn't really C :P I kid, it's really impressive work.
c3534l 10y ago
Yeah, I really hope Rust becomes the default C replacement. It's such a well-designed language, it's just very early in its development right now.
- aninteger 10y ago
  Rust seems very complex and C is more about simplicity (in the sense that K&R is a short read). Other languages with the same spirit of simplicity would be Tcl and perhaps Go. I just wish Go had more supported machine architectures.
  - ocschwar 10y ago
    My feeling is that one should use Python or Go to prototype a program, and then move to Rust to make it systems-ready.
andrewchambers 10y ago
Yes. One flavour of icecream is all we need. (I hope people can see the sarcasm)
- nickpsecurity 10y ago
  "My qbe C frontend is actually written in myrddin which is a lot like rust/ocaml. To be honest, C is not well suited to places where there is adversarial input such as servers, but when it comes to logical correctness of code I do not see amazing benefits from languages like ocaml." Did you mean two? Or did you come to new conclusions after that experience? Or did I misunderstand that entirely? ;)
  - andrewchambers 10y ago
    There ARE benefits to correctness from better languages, just not as amazing as people think. I'm just saying a vulnerability in C is just going to be an out of bounds exception in another language. both cases the code is not correct, one is just safer than the other when it comes to exploits. Keep making more languages, we can't know for sure if we don't try.
    - nickpsecurity 10y ago
      I can see where you're going but I don't think it's correct. There are clearly cases where an error will mess you up whether it goes as far as in C or not. Other times, the language or tooling prevents the error before runtime to ensure correctness. Are you aware of the benefits of Design-by-Contract (Ada/Eiffel), static proving (SPARK), or dependent types (ATS), though? The correctness criteria you can encode in them can straight-up prevent errors at interface or algorithmic expression levels. Three of these have been used for low-level code with two often in real-time and one for an 8-bitter. Depending on automation or interactive use involved, the errors caught at compile-time can increase pretty far past what a basic, low-level, type system can do. So, we already know we can knock out extra classes of errors with such languages. It was proven in theory and in the field. Using or improving them is just good engineering. We can also make more languages in trial-and-error discovery process to see if we find more benefits. Exceeding C's benefits, though, is already empirically proven to be worthwhile whether it's a Myrddin, a SPARK, or an ATS.
DSMan195276 10y ago
I've thought alot about this before. Rust doesn't really have very great interoperability with C - most languages really don't, because the API for C programs revolves around functions, structs, macros, etc. Most languages can only really get part of that, and then the rest gets essentially a separate implementation in the language you're porting too - leading to a certain amount of manual duplication and intervention necessary (We don't call it porting when you use a C library in C). Design goals Rust has made compound the issue a bit more: For example, Rust uses the C++ ABI, not C. Rust can't generally use header files directly. The Rust<->C conversion loses a lot of information and can result in fairly messy code by Rust standards, etc. This makes combining Rust into already existing C code a hassle, as it is generally worse then even just trying to use C and C++ together which is already fairly annoying and error-prone. This is compounded by Rust's safety goals which generally require a different design to a problem then the "C-style" approach would be - IE. You're probably not going to get good Rust code by simply replacing a .c file with a Rust file, because the entire time you're going to have to make use of the unsafe C functions that your program includes. Perhaps the bottom line is that (for good reason) Rust is much more then just an improved C. And because of that, combining C and Rust is always going to feel like combining two separate systems together with a compatibility layer in-between - because that's really what it is - and that's just not very attractive. I know little about Zig (I'm reading about it for the first time now) and don't at all predict it to replace C. That said, I would love a language which has a focus on maintaining very good compatibility with C while fixing the various pieces of its design that are fixable within the bounds of the language. For example, I noticed it mentioned in the README that in Zig that pointers are nonnull by default, and can be made nullable by adding the 'maybe' attribute. This is a feature I would love in C, but really isn't there (gcc has a nonnull attribute, but it is really essentially useless and nothing like you'd want). Essentially, I would like a language where it feels like writing code for the same system, but in a different (better) syntax - where I can drop it into a project and it works together with the system like any other .c file (Though with a different compiler, obviously), but the code inside is much better then what you can do in standard C. I think that such a language could retain the reasons why people (like me) still like C, while fixing a lot of the uglier sides to the language that everybody is aware of but aren't going to get fixed any time soon. And perhaps most importantly, I think such a language is definitely possible (Though it may not be able to employ all the features you may want) - but I don't have the time nor probably the skills to really do it well besides list off the things it should fix and shouldn't fix. As for starting a project though, if you ignore difficulty to learn then I would agree with you: There's probably little reason not to just go for Rust if you're already willing to learn a new language. For most projects the issues I outlined above don't really matter assuming the entire project is written in Rust - besides the want for a language closer to C in design. That said, I readily concede that I have no idea if Rust's borrow-checking semantics could ever work without the extra features they added that take the design away from being 'C-like' - and considering that's one of the definitive features of Rust, is easily worth losing the 'C-like' detail if it is necessary. But when considering a project like the Linux Kernel, the GNU coreutils, git, GTK, and other various large projects where conversion to Rust is probably impossible without a complete rewrite, being able to use a 'better' C while still retaining the aspects that people like would probably be a nice step in the right direction. The chances of it happening are nil, but it would still be a step in the right direction.
daurnimator 10y ago
One of my biggest reasons is the lack of ability to handle OOM when using the standard library. see e.g. https://internals.rust-lang.org/t/could-we-support-unwinding-from-oom-at-least-for-collections/3673/17 https://internals.rust-lang.org/t/could-we-support-unwinding...
- whyever 10y ago
  How can you handle OOM if your process gets killed by the kernel for using to much memory?
  - daurnimator 10y ago
    By never going that far. Turn off overcommit; I advise to never run with it in production.
teacup50 10y ago
Among other things, systems programming projects generally require stability of language syntax, API, and ABI. In terms of ABI stability, Rust has none. In terms of API stability, they seem willing to drop features within a major release cycle or two. In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x). Rewriting for the sake of language updates is a huge resource drain when you're talking about code bases with lifetimes that are likely to be longer than their authors'. For reference, just about every major shipping OS contains significant LoC dating back to the 70s or 80s.
- Gankro 10y ago
  > In terms of API stability, they seem willing to drop features within a major release cycle or two. I don't think any feature/api that was at one point marked as stable post 1.0 (when they started making any guarantees) has ever been removed. > In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x). While it's true that 2.x has the rights to break everything, this is incredibly dishonest to state in a vacuum, because it's a well established point that 2.x should never exist. The devs want all code to work forever, and only a catastrophe would push them to pull the lever. They have of course reserved the right to require fixes in special cases -- e.g. fixing a bug in the type checker might break some code, and that's acceptable. Although even then they'll try to phase in the fix over a few releases. Every release is tested against the entire crates.io ecosystem to try to catch these regressions. You are absolutely correct on ABI stability, though.
  - teacup50 10y ago
    Given the litany of deprecation markers applied to existing APIs, one must presume the intention of removing them, no?
    - Manishearth 10y ago
      Not necessarily. I suspect even in the case of 2.0, most if not all of those apis will survive. Deprecation markers exist to encourage people to use newer, better APIs. I suspect that even if 2.0 happened, the only apis that would be removed would be ones that we're reasonably sure nobody uses (via crater), and even then there would be debate. And like Gankro said, 2.0 is a thing that's not supposed to happen in the first place.
Koshkin 10y ago
Rust? Maybe. But then, why not Go or Swift or Lisp? Personally, if I were to be expelled from C/C++ paradise, I would try Oberon - the only language I know that can compete with C in its simplicity and, despite normally being perceived as garbage-collected, the ability to serve as a truly systems programming language.
- mordocai 10y ago
  As far as vs Go or Swift or Lisp, Rust is much "closer to the hardware"(as discussed in other threads nothing is really close to the hardware anymore) than the other languages, go and most lisps use GC which causes problems in many systems language situations, and last I heard swift still has lackluster cross platform support. I don't really know anything about Oberon so can't speak to that. P.S. Personally, all my hobby projects are in lisp. I write applications though, not system stuff.
  - pjmlp 10y ago
    Oberon was used for writing a complete graphical workstation OS used during the mid-90 at the ETHZ in Switzerland. It was a language and OS, following the same spirit of Xerox PARC OSes.
  - nickpsecurity 10y ago
    The A2 Bluebottle OS is latest incarnation of Oberon OS with GUI and very responsive. Languages like Oberon can do unsafe stuff for low-level work like OS's. You just use manual, memory management and UNSAFE keyword. Rest that can be GC'd, bounds-checked, etc is by default.
- ziotom78 10y ago
  A few months ago, I considered Oberon as a viable alternative to C for my pet projects. Horace, after some time spent playing with it, I was scared by a fewserious limitations: (1) there is no support for UTF-8 strings, native strings are just sequences of ASCII characters, (2) lack of libraries and available bindings (e.g., SQLite, GSL, FFTW...), (3) scarcity of tools like package managers and Doxygen-like tools, (4) very few resources available on the web (Wirth's book is exceptional, but it does not cover use cases that are common in 2016.)

gragas 10y ago

Obligatory: why is Zig meant to replace C? Why is it a better replacement than Rust (when Rust is considered a C replacement)? Interesting work nonetheless.

parenthephobia 10y ago
I'd rather use Zig than Rust because I wouldn't have to learn about how to work with Rust's memory management model. Even though I understand Rust at a technical level, actually getting my brain to work that way has proven difficult. Being able to directly import existing C header files is also attractive. Having said that, I'd rather Zig had been Go-inspired than Rust-inspired. Go plus Zig's approach to generics and error handling would be nearly perfect! (Notwithstanding that Zig's error handling is basically Rust's with added syntax sugar!)

z0xcd 10y ago

One question: Why is Zig implemented in C++? What was the reason behind the choice?

AndyKelley 10y ago
It's mostly C, with some templates sprinkled in. Zig depends on libclang and LLVM. Both of these are C++ APIs. Both expose a C API wrapper, but with not all features exposed that zig needs to use.

yyhhsj0521 10y ago

Is Zig compatible with C? No? End of the story. Edit: I know that you can include a C header in Zig, and cross-compilation is possible and made easy. But you can't continue develop on current C projects if you switch to Zig. I guess that you have to change the Makefiles too.

parenthephobia 10y ago
But... Zig is compatible with C. It goes to some lengths to make sure of it.
- emmelaich 10y ago
  I guess @yyhhsj0521 means source compatible. Which was my thought too. I mean, as source compatible as possible; which may not be much.
- ajarmst 10y ago
  Unfortunately, that tends to demand the observation that C is really compatible with C.

parenthephobia 10y ago

Syntax looks very Rust-inspired, but it lacks Rust's OCD. I also catch hints of other syntaxes, like Ruby/Smalltalk-style block parameters, and a defer very much like go's. I find it interesting that it implements generics by passing types as normal arguments. Say, `list(i32, 1, 2, 3)` rather than `list<i32>(1, 2, 3)`.

dilap 10y ago
i love this

necessity 10y ago

Don't fix what's not broken.

theoh 10y ago
I apologize in advance but... "necessity"... Surely not THE "necessity", mother of invention? I guess that would absolutely give you a veto on other people "scratching their own itches". Snark aside, the issue is surely whether, if designing C now, the last 40 years of programming language theory would not have some impact.
adamnemecek 10y ago
C isn't broken?
- necessity 10y ago
  Why would you think it is?
  - adamnemecek 10y ago
    Not memory safe, bad type system, terrible 'macro' system, no/minimal(C11) support for generics, minimal standard library, pretty verbose (it's hard to build any good abstractions), lack of functional programming support, undefined behavior. Dealing with dependencies and headers in any but the simplest of projects gets old really quickly. Just about bigger project I've seen abuses the language to some extent. The list goes on and on.
wolf550e 10y ago
Basically every deployed C codebase contains "undefined behavior".
- necessity 10y ago
  Which is intended. Suggested reading: http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/213

sotojuan 10y ago

Cool to see a fellow Recurser in HN!

qwertyuiop924 10y ago

The thing is, you will never replace C. Supplement it, extend it, yes, but not replace it The fact is, C is still probably the lowest level HLL still used. It's the lowest level you can be, while still providing the HL constructs we're all used to. There is always going to be code that wants or needs to be there. Code where anything further up either can't give the performance, or provides impedance to the design or actual goal. You still want to replace C? Fine. What will you write your bootstrapping compiler in? :-D.

lifthrasiir 10y ago
> You still want to replace C? Fine. What will you write your bootstrapping compiler in? :-D. There are several examples of language implementations that are built directly from machine code incrementally. (In that case, the "bootstrap" happens via an already-built compiler of the previous version, or of the same version in the different architectures.) Also, you don't strictly need C for the bootstrapping compiler... Rust's one was OCaml for example.
- qwertyuiop924 10y ago
  And what's OCaml written in? How about the assembler? If you really want to replace C, You'll need to be able to compile the language without ever having C on your system (at least, in theory). This is almost impossible, although you can do it, if you slowly work towards it.
  - ajarmst 10y ago
    That's not really fair. If you go far enough back in the ancestral compiler list on any language, you'll probably hit C. You'll definitely hit hit assembly and bare-metal machine code. Heck, at some point you might run into hand wire-wrapped microcode---but I don't think that's an argument that we should be using it. That's just an artifact of the history of operating system development, and the fact that C spent (is spending) a considerable period as the de facto standard for OS development. That it was first doesn't necessarily make it better. A few events turning out differently in history, and you'd be making the exact same arguments about lisp, BCPL or Fortran.

matthewhall 10y ago

Not with that logo it won't.

AndyKelley 10y ago
hahaha. I would gratefully accept an improved logo if anyone is willing to take the time to make one.
- majewsky 10y ago
  You still have a few hours to submit Zig into https://news.ycombinator.com/item?id=12372118 https://news.ycombinator.com/item?id=12372118

girvo 10y ago

Interesting language. Somewhat reminds of me "ooc"[0], though I believe ooc is ref-counted/garbage-collected (? I think. I can't remember, been a while since I've touched it); but being able to easy use C libraries from a relatively low-level language that has nicer high-level constructs is still a beautiful idea, in my opinion. The language I'm using these days for that exact feature set though is Nim[1] -- being able to use {.compile.} pragmas and bring in header/source files, along with the great C type support is wonderful; but again, garbage collector (albeit one that can be tuned and/or turned off). Zig seems to be targeting the "true C replacement" niche, which I'm going to have to keep an eye on! [0] http://ooc-lang.org/ http://ooc-lang.org/ [1] http://nim-lang.org/ http://nim-lang.org/

CaliforniaKarl 10y ago

I don't know. C is very close to the hardware, and it's pretty portable, too. I'd suggest doing what some other languages do, and get yourself to the point where almost all of the code for Zig is written in Zig. In other words, you'd first write a `microzig` that's written in C++, and microzig knows enough to make `minizig`, which knows enough to make the rest of zig. This is what Perl does, and I expect other languages do the same thing. On the other hand, zig is supposed to be able to cross-compile really well, so maybe you can skip that: Have version 0.9.9 be the last version written in C++. Then, for version 1.0, re-write the entire toolchain in Zig, and use the 0.9.9 compiler to compile Zig 1.0. At that point you are in full dogfood mode. Finally, since it's called Zig, I get to close with this sentence: "You have no chance to survive make your time."

toomanybeersies 10y ago
AKA Bootstrapping: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
dllthomas 10y ago
> C is very close to the hardware At this point, I'd more say that the hardware does an awful lot of work trying to look like it's close to C.
- bradhe 10y ago
  It's an interesting phenomenon, specifically how processor companies (erm, Intel), who make "general purpose" CPUs, have clearly made trade offs to optimize for OSes that behave like UNIX or Windows varients!
  - dbcurtis 10y ago
    Well, in fact, Intel and all the other major makers spend a huge amount of effort benchmarking important workloads. It isn't a decision to optimize for Unix or Windows, it is a decision to chase dollars. They will optimize processors for your favorite workload, too. Just demonstrate how many millions of dollars of business your workload represents, and create some sound benchmarks for it. Easy.

ajarmst 10y ago

Intend in one hand, and ... well, you get the picture.

wyager 10y ago

> Maybe type instead of null pointers. It's often a bad sign when a language advertises this high up on its features list. It means that they didn't really get the true takeaway of the Maybe type (which is that you should support algebraic data types to properly constraint data to valid states), but instead saw a single specific use case of ADTs (Maybe) and thought that's all there was to it. I've run into this with Java 8. Optional is pretty common now and has eliminated the need for the null pointer in much of everyday code, but they still don't have something like Either to eliminate the need for exceptions. Maybe is extremely useful, but it's a small fraction of the usefulness you get with true ADT support.

AndyKelley 10y ago
Zig also has algebraic data types.
- fspeech 10y ago
  Are they ML like ADTs with pattern matching? That would be awesome.
- wyager 10y ago
  Any examples? There were none at OP's link.

Gankro 10y ago

I can't seem to find any details on safety other than > Safe: Optimality may be sitting in the driver's seat, but safety is sitting in the passenger's seat, wearing its seatbelt, and asking nicely for the other passengers to do the same. Is Zig memory-safe? How? (Specifically, is there some useful safe subset ignoring the obvious FFI and "explicitly unsafe operations" exceptions every language gets?) If it's not, is that even a goal?

AndyKelley 10y ago
It's not memory safe. There is some compile time safety and some runtime safety, but it's not comprehensive. Nullable pointers are handled by the type system at compile time. Integer wrapping (signed or unsigned) will crash at runtime, unless you use explicit wrapping operators. Array out of bounds will crash at runtime for slices. There is no direct pointer arithmetic, but you can convert a pointer to a slice, and then index into the slice (which has array bounds checking). This is an example where the language is unsafe but it sort of guides the programmer into writing safe code.
- Gankro 10y ago
  Not being memory-safe is a bit of a bummer. Do you have a story for taking advantage of all the tooling thats been built up to defend against C's pervasive unsafety? Sanitizers being the most notable. On balance even without them this'll probably be safer than C (as long as you're avoiding like, 90% of its pitfalls). Either way, hope this works out for ya!

Koshkin 10y ago

C is beautiful in its way and it is rather minimalist from the syntax point of view (especially the pre-C99 variants). Judging by the code examples shown on the page, this new language has a pretty noisy (compared to C, downright ugly) syntax. Granted, it may be dictated by some logic and possibly even its inner beauty, but on the surface it does not seem to be much of an improvement compared to the languages we already know and love (or love to hate), including Perl and JavaScript.

kzhahou 10y ago

Almost half the comments here are just to remind everyone that C can/will never be replaced. Is that really the most insightful we can be? Is HN so pedantic now that we can't analyze an interesting language idea, but just nitpick at its existence?

AndyKelley 10y ago
My plan to replace C is simple and pragmatic. 1. Make a language and compiler that fills the same niche as C but does it significantly better, taking into account all the lessons we've learned in the last 44 years. 2. Make a build tool that competes with autotools, cmake, make, etc. Similar to Python build.py, you'll have a build.zig, import a library and use it. The library does everything configure/make does except better. 3. Package management on par with NPM and Cargo. Minimal overhead to publishing reusable code. Although I don't plan to have a central repository, rather the ability to put a URL or source control URL with a hash. 4. Zig can import and export .h files, and you can target .o files that are compatible with the rest of your C codebase. 5. Now there is minimal cost to replace bits and pieces of your codebase with Zig.
- versteegen 10y ago
  Plenty of us know it can be done, and is an extremely worthwhile goal; keep up the fantastic work! Zig may be the language I've been waiting for, so I'll make it the next language I learn, although I realise it's not even reached a first release.
- ashitlerferad 10y ago
  Don't forget item 6, which is quite essential: 6. Talk about Zig at conferences and promote it in other ways
- otabdeveloper1 10y ago
  Points 1, 4 and 5 are exactly the same in C++ too. What makes you think you can do better than the guys who are driving C++ development? (Honest non-rhetorical question.) Points 2 and 3 don't really belong in a programming language.

fspeech 10y ago

The first thing I would want to use something like this for is to write C API for a C++ library. Is that possible with the current state of Zig?

AndyKelley 10y ago
I think the best language to do that in is C++. You write a C .h file, and then a C++ .cpp file that implements the C functions using the C++ API. Zig doesn't know how to use the C++ ABI. It's pretty complicated.
- fspeech 10y ago
  You are right that C++ methods need to be invoked in C++ code. However C container types are too weak/inconvenient to wrap C++ code. I am wondering if something like Zig can be used to create STL like containers that can be used at the API level?

adrianratnapala 10y ago

Well I am impressed. And I am very glad to see more and more languages in this space. I particularly like that Zig seems to be minimalistic -- a lot more fun to look at (for me) than C++ or Rust. But I didn't see anything in Zig similar to Rust's lifetimes. Well it's nice to be rid of that complexity, but I don't see how you are going to do C-like pointer stuff safely without them. Can anyone explain what these languages (e.g. Zig, Myrddin, Nim) do instead?

steveklabnik 10y ago
Nim has a GC. Myrddin doesn't, but I can't quite remember what it does for safety, if anything. The language spec does say "pointer arithmetic is not allowed." For Zig, see here: https://news.ycombinator.com/item?id=12380078 https://news.ycombinator.com/item?id=12380078

dsego 10y ago

This man is a prolific genius. http://genesisdaw.org http://genesisdaw.org http://libsound.io http://libsound.io http://groovebasin.com http://groovebasin.com

a-nikolaev 10y ago
Yeah, he is awesome~ cannot upvote this twice. And I think, his design decisions are very clear and straightforward too.

pmontra 10y ago

How is the goal of readability being addressed? I didn't find it particularly readable. Basically it's C with better types. A few suggestions about the syntax, based on what many languages did in the last 25 years. 1) No mandatory () around conditionals. Make {} mandatory even for one liners instead. They remove bugs and are a common suggestion in the style guides of several languages. 2) The multine string syntax is verbose and uninviting. Use heredocs or a string delimiter reserved for that purpose. 3) Try to do without the ; line terminator As a huge bonus, to reduce clutter, try to implement automatic import. I don't know of any language doing it, it's IDE territory right now (or editor's [1]). Still it's very useful because there is little as boring as going through a long list of imports at the beginning of each file. They should be there only when there is an ambiguity to resolve. About readability, those {var v; while (cond) {}} blocks in the examples are puzzling. Finding a }} alone on a line was an "is this a syntax error?" moment, or just bad style. Anyway, it seems to have generics so it's already ahead than Go, which seems to be stuck in the 60s regarding this feature (they've been pioneered by ML in 1973 according to [2]). For the rest, it's in the average of what we've seen in the past decades, so not shiny but not bad. Plenty of successful languages are like that and maybe it's a reason for their success: being average they don't scare away people. I'm thinking especially of Python, which smells oddly of C with its __underscores__ and the explicit self argument, reminding me of how we used to do OO in C passing around struct pointers (those structs were the objects, holding data and function pointers to methods). [1] http://www.vim.org/scripts/script.php?script_id=325 http://www.vim.org/scripts/script.php?script_id=325 [2] https://en.wikipedia.org/wiki/Generic_programming https://en.wikipedia.org/wiki/Generic_programming

tom_mellior 10y ago
One more syntax issue: http://andrewkelley.me/post/intro-to-zig.html http://andrewkelley.me/post/intro-to-zig.html shows the const number = parse_u64(str, 10) %% |err| return err; pattern and then goes on to say that you can avoid repeating "%% |err| return err" all the time by writing const number = %return parse_u64(str, 10); instead. I don't think that's particularly nice; it looks too much like "return the result of the call" when that's only what happens in the error case. I would have expected something more like this: const number = parse_u64(str, 10) %% return error; where the compiler would turn "return error" into "|_some_var| return _some_var".

web007 10y ago

return if (value >= radix) error.InvalidChar else value; That is just painful to parse. Suffix-If sometimes makes sense and simplifies things, but it always makes code flow more difficult to understand.

perfunctory 10y ago
I don't think this has anything to do with "suffix-if".
- majewsky 10y ago
  Yeah, that's just if as an expression, replacing the ?: operator. Compare to return (value >= radix) ? error.InvalidChar : value;
  - naasking 10y ago
    I actually prefer a ternary arrangement that lets you chain arbitrary such expressions like a truth table: return (value >= radix) ? error.InvalidChar: (comeCondition) ? error.OtherError: ... value;
    - drjeats 10y ago
      I like doing that too, but the Zig syntax doesn't prevent that kind of arrangement, just makes it a bit wider. return if (value >= radix) error.InvalidChar else if (comeCondition) error.OtherError else ... value; or maybe this, but it seems uglier to me: return if (value >= radix) error.InvalidChar else if (comeCondition) error.OtherError ... else value;
- web007 10y ago
  True, which only makes my poorly-targeted point on bad parsability. Reading the code requires backtracking around a conditonal control statement, and in a format more verbose than ternary. Most places I've worked have bans or limits on ternary to single boolean cases for the same reason: It's hard for people to understand the control flow of operations around conditional assignment. A new language that lets you perpetuate painful code isn't helping as much as it could. It's much simpler for people to parse the more verbose case with an IF and two return blocks, and the compiler shouldn't care since it can generate the same code either way.

lisper 10y ago

You lost me at hello world. Or maybe I should say you lost me @ %hello %%world. If you want to prioritize for readability the first thing you have to do is get rid of all that weird non-standard punctuation.

codygman 10y ago
https://github.com/andrewrk/zig/issues/176 https://github.com/andrewrk/zig/issues/176

deleted 10y ago

[deleted]

wmu 10y ago

I would love to see a comparison to C, C++, Ada, Rust, maybe Cyclone. After reading the page I can't find an answer why Zig is better than any of established languages. (Haven't read comments yet) Speaking of readability... well, still smells like C. And multiline string syntax is weird. :)

dschiptsov 10y ago

Modern amateur language designers usually are not aware of decades of research and breakthroughs in old-timer's languages, such as Algol, Scheme, Common Lisp, Standard ML and recently Haskell. They miss the beautiful specialized syntactic sugars in Standard ML (for defining and calling curried functions), Octave/Matlab matrix syntax, and the beautiful Common Lisp's looping and SETF macros, which inspired Python's for loop syntax for iterable collections and assignment operator overloading. Instead of spending time to learn and understand pros and cons and nuances they rush headlong to implement everything from scratch. Really smart guys, however, are trying to leverage old-school languages, to climb on the shoulders of Titans. David Moon created the PLOT language that leverages Lisps http://users.rcn.com/david-moon/PLOT3/ http://users.rcn.com/david-moon/PLOT3/ , Rich Hickey did almost the same with Clojure. Scala has been a leverage of Standard ML, similar to Ocaml. Now Swift is trying to distillate Scala, at least in terms of standard idioms and syntax choices. Julia has been build upon the big ideas from CLOS. Python incorporated lots of good ideas and bits of syntax and managed to balance the syntax and unify semantics and since 3.5+ earned reputation of a well-designed language (clear, balanced, complementing each other semantics from the Lisp world, and carefully chosen syntax). It is also famous for its culture. So, for those who wish to change the world by developing a new language, it might be a good idea to look at Standard ML and its derivatives and try to relax some constraints and balance the syntax according to modern conventions. I personally would prefer to start from David Moon's PLOT3 and, perhaps, try to marry it with some lightweight type-system based with optional annotations. Btw, Haskell's choice of not mixing type information and function definitions and use annotations with its own DSL for types is a really big idea. It reduces cognitive load, makes code extremely readable, and in general, it seems, the best of both worlds. Python's optional type annotations are clever, but less elegant.

renox 10y ago

While I find interesting the idea of a new C (instead of a new C++ like D, Nim, etc), I'm a bit sad that there is both the Zig AND the Jay projects.. It reminds me why Pascal lost (IMHO): too many incompatible Pascal 'clone'.

Matthias247 10y ago

Error handling mostly with error codes seems like an OK compromise for me since it doesn't require any dynamic memory allocation (like Gos error interfaces). I guess one would use some custom return type or a GetLastError equivalent if more details are required. However I'm not sure if purely compiler assigned error numbers will work out for a systems language. Of course it works when you build the whole application, but if you build only a part of it (a library, an application that (dynamically) links against a library, ..., where do you get the information from which error codes are already occupied by them?