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

http://ziglang.org/

by vmorgulis • 10 years ago

237 218 10 years ago

ziglang.org

ocschwar3• 10 years 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• 10 years 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 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/....

tomjakubowski• 10 years 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

kbenson• 10 years ago

I think there exists, or work has been done on, a tool to auto generate that data for you. So not quite as simple, but possibly more fine grained control.

c3534l• 10 years 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• 10 years 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.

andrewchambers2• 10 years ago

Yes. One flavour of icecream is all we need. (I hope people can see the sarcasm)

nickpsecurity11• 10 years 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? ;)

DSMan1952765• 10 years 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.

steveklabnik12• 10 years ago

  > ust uses the C++ ABI, not C.

Rust uses its own ABI, not any of the various C++ ones.

Our strategy for interop with C is two-fold: first, a very thin, direct wrapper. These are the various *-sys packages. They know how to link in (and maybe even build!) the underlying C library, and provide functions you can call from Rust. Then, on top, people can write a more idiomatic Rust wrapper, working in Rust's safety guarantees.

That takes some work and time to get right, but hopefully, it means that in the end, Rust users of C libraries shouldn't have to deal with the stuff you're talking about.

pcwalton7• 10 years ago

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

Firefox is shipping Rust code right now. There are various examples of Linux kernel modules written in Rust. There are rewrites of the coreutils in Rust. I don't understand why you claim this.

daurnimator2• 10 years 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...

whyever• 10 years ago

How can you handle OOM if your process gets killed by the kernel for using to much memory?

teacup509• 10 years 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.

Gankro4• 10 years 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.

steveklabnik12• 10 years ago

To re-iterate what gankro said, we care a _lot_ about making sure that it's trivial to update your Rust. Your ABI compatibility comment is correct, but the rest of them aren't. We only break backwards compatibility in very few cases: if there's a soundness hole, or if we have to fix something in certain underspecified areas of the language. For those latter ones, if it's not a trivial fix, then it's a no-go, and even if it is, we do warnings until we don't see them in the ecosystem any longer.

But really, it's not about rules-lawyering over technicalities about what our policies are: the underlying attitude we share towards new Rust versions is that it should be trivial to upgrade. And we collect data to make sure that we're on target there: part of it is the train-based release strategy, part of it is stuff like testing everything on crates.io, part of it is things like the community survey, where most people said their code has never broken, and if it did, it was extremely easy to fix.

pcwalton7• 10 years ago

In terms of API stability, they seem willing to drop features within a major release cycle or two.

This is completely false. Do you have an example?

Besides, this is completely off topic in a Zig thread. From the FAQ: "Zig is not afraid to roll the major version number of the language if it improves simplicity, fixes poor design decisions, or adds a new feature which compromises backward compatibility."

Koshkin2• 10 years 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• 10 years 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.

ziotom78• 10 years 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.)

amyjess• 10 years ago

Honestly, my first thought upon seeing GP's post was "why not Ada?". Designed by the DoD for safe systems programming, it wouldn't really be a bad choice.

gragas• 10 years 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.

parenthephobia3• 10 years 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• 10 years ago

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

AndyKelley7• 10 years 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• 10 years 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.

parenthephobia3• 10 years ago

But... Zig is compatible with C. It goes to some lengths to make sure of it.

emmelaich• 10 years ago

I guess @yyhhsj0521 means source compatible. Which was my thought too.

I mean, as source compatible as possible; which may not be much.

ajarmst3• 10 years ago

Unfortunately, that tends to demand the observation that C is really compatible with C.

parenthephobia3• 10 years 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)`.

dilap2• 10 years ago

i love this

necessity3• 10 years ago

Don't fix what's not broken.

theoh• 10 years 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.

adamnemecek2• 10 years ago

C isn't broken?

necessity3• 10 years ago

Why would you think it is?

wolf550e2• 10 years ago

Basically every deployed C codebase contains "undefined behavior".

necessity3• 10 years ago

Which is intended. Suggested reading: http://blog.regehr.org/archives/213

sotojuan• 10 years ago

Cool to see a fellow Recurser in HN!

qwertyuiop92416• 10 years 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• 10 years 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.

qwertyuiop92416• 10 years 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.

nickpsecurity11• 10 years ago

"but not replace it"

I've long proven you can on a per project basis for both system apps non-C languages and C apps with better, C variants.

"What will you write your bootstrapping compiler in? :-D."

Any language better than C for writing a compiler, esp Ocaml w/ design-by-contract, compiling to target assembler. Worked wonders for Esterel's SCADE. Optionally, any such language transpiling to any other HLL on target system, including C w/ safety checks & no undef behavior. Working wonders for COGENT language team. Or go Wirth-style with a better-than-C (esp Component Pascal) to P-code compiler plus P-code interpreter for target hand-written in assembly. Simple backend + interpreter got Pascal/P on 70 architectures. Any are easier than a whole compiler for complex language (or C) in C using a C compiler.

For doubters:

https://embed.cs.utah.edu/csmith/

qwertyuiop92416• 10 years ago

Fair 'nuff on the compiler stuff. I was talking about replacing C globally, however, and that's not happening any more than we're replacing FORTRAN.

Joof2• 10 years ago

I'll probably write it in Haskell or possibly ML. The Haskell compiler is written in Haskell, so there's nothing to C here.

OTOH, I'm not sure if C needs replacing. It models state machines fairly well. Sure, we could use more systems languages like rust, but at best they replace C++ in some circumstances.

spectral64• 10 years ago

But isn't Haskell's runtime (RTS) written in C?

posterboy• 10 years ago

at hundreds of pages defining the standard, it's not low level at all, sadly. The apparent simplicity is deceiving at first, IMHO.

Low level doesn't mean simple, but yet because of the desire for portability, it's rather abstract. It can't even check for a carry flag. It's not hard to imagine a language that could. Coming from microcontrollers, that is a huge disappointment. That is just the an example. Is there more?

qwertyuiop92416• 10 years ago

It's lowlevel, that's why there's so much spec. And much of it is just defining that behaviour is implementation defined.

And as I said, it's as lowlevel as an HLL can be.

I wish we could check the carry flag. You could totally write a C library for that, I bet, by mixing in some asm, and using conditional compilation. Language extension!

versteegen3• 10 years ago

It's the lowest level you can be, while still providing the HL constructs we're all used to.

I disagree completely. A language much better than C will come along in its niche, and I'll be switching.

C isn't low level enough. It has too much undefined behaviour (and tries to be too portable), each instance of which denies you access to real machine behaviour. Signed ints don't even wrap around! Effectively, C does not even support twos-complement signed integers, as exist on all modern computers since decades ago, without a special compiler flag! You have to resort to tonnes of compiler-specific extensions to get things like leading-zero-count, SIMD, and computed-goto. Even with GCC's zillion extensions that were added for people who have to do really low level work, C is still hopeless for writing maximum-performance VMs, that's why Mike Pall wrote the LuaJIT2 interpreters (one for each architecture) in assembly. Here's one of his explanations why C shouldn't be used for such a thing [1]. I've also tried writing a high performance interpreter in C, and I found that I wasted 80% of my time trying to get the C compiler to output the sequence of instructions I wanted. Next time, maybe I'll just use assembly and save myself a lot of trouble.

Secondly, C is not high-level enough. A low level language like C needs a powerful macro system to let you abstract away the details of your object system or whatever. C's preprocessor has many flaws [2] and is one of the worst in existence. A good macro facility allows compile-time generation of code in a readable (or at least type safe) way, like D and Lisp do. C and C++ users don't realise they have the preprocessor equivalent of a Blub language [3]. Sure, C++ is an extension of C with high-level features, and was a good attempt, but it's too complex and C++'s template meta-programming just about the only compile-time codegen solution worse than C's preprocessor.

[1] https://web.archive.org/web/20160209102431/http://article.gm...

[2] Read any rant, e.g. http://c2.com/cgi/wiki?CeePreprocessor

[3] http://www.paulgraham.com/avg.html

qwertyuiop92416• 10 years ago

Yes, C's preprocessor is weak, but that's a quality of life thing, not a necessity by any stretch.

And as for C not being low-level enough, that was my point - C is as low level as you can be, before you become unportable.

_ph_• 10 years ago

You can bootstrap in any language that is widely available, so today that could be Javascript even. The biggest advantage of C as a language is, that a simple compiler is very easy to write. But I would bootstrap from Lisp (Scheme). A naive interpreter can be easily implemented in assembly and then you have a nice high level language for implementing the target system.

matthewhall• 10 years ago

Not with that logo it won't.

AndyKelley7• 10 years ago

hahaha. I would gratefully accept an improved logo if anyone is willing to take the time to make one.

majewsky6• 10 years ago

You still have a few hours to submit Zig into https://news.ycombinator.com/item?id=12372118

girvo• 10 years 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/

[1] http://nim-lang.org/

CaliforniaKarl• 10 years 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• 10 years ago

AKA Bootstrapping: https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

dllthomas2• 10 years 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• 10 years 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!

lohankin• 10 years ago

This seems to be changing. Hardware is trying to move closer to java -by adding support of GC, bounds checks, etc - something that won't help C programs as much.

AndyKelley7• 10 years ago

https://github.com/andrewrk/zig/issues/89

As long as we rely on libclang and LLVM there will be a part of the compiler written in C++, and I foresee these dependencies sticking around.

tom_mellior2• 10 years ago

C is very close to the hardware, and it's pretty portable, too.

Here you seem to be suggesting that portability is good, but then...

zig is supposed to be able to cross-compile really well, so maybe you can skip that

... you seem to be suggesting that this project should give up its (already existing!) portability. Without saying why.

In 2016, it's not clear at all why having having a compiled language be self-hosting should be considered a worthy goal. It's just a lot of busywork instead of simply using an existing toolchain. Certainly not the right thing to do from a software engineering point of view. Certainly not the right thing to do if you want portability. Certainly not the right thing to do if you want interoperability with existing sanitizers. Certainly not the right thing to do if you want powerful optimizations.

I'd agree that the frontend should probably be bootstrapped, at some point. But the whole toolchain? Just to avoid random HN commenters throwing "every self-respecting programming language is bootstrapped" at you? Nah.

ajarmst3• 10 years ago

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

wyager2• 10 years 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.

AndyKelley7• 10 years ago

Zig also has algebraic data types.

fspeech3• 10 years ago

Are they ML like ADTs with pattern matching? That would be awesome.

wyager2• 10 years ago

Any examples? There were none at OP's link.

Gankro4• 10 years 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?

AndyKelley7• 10 years 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.

Gankro4• 10 years 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!

Koshkin2• 10 years 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• 10 years 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?

AndyKelley7• 10 years 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.

versteegen3• 10 years 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• 10 years ago

Don't forget item 6, which is quite essential:

6. Talk about Zig at conferences and promote it in other ways

otabdeveloper12• 10 years 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.

pjc50• 10 years ago

1-3 are a tremendous amount of work, especially if you want to replicate "everything" that automake does.

gkya• 10 years ago

2,3: Or just use make and use OS package managers. Don't make the users learn yet another tool.

The niche of C is Unix, which is here to stay. C is a part of Unix, it's interfaces are defined in terms of C, and plethora of libraries written in it. If a random library X is impemented in C, it is easily usable in many languages via FFIs. Programs written in C are easily portable to most popular platforms, and C knowledge is transferable from supercomputers to tiny embedded devices. C translates nicely to assembly, and it maps easily to mechanics of computing. These are the areas where languages like Zig need to penetrate.

paulasmuth• 10 years ago

All of those points sound fantastic and zig is one of the most interesting things I've seen on HN in a while.

Still I can't help but ask one question: Your points 2 and 3 (build tooling and package management) seem like they would have the biggest, immediate impact for most current c/c++ users.

Did you ever consider separating the build tooling and dependency management effort from the core language?

I, for one, would be extremely interested in sane build tooling and dependency management for c/c++ (and what you describe sounds great). I would give it a try in no time. However, I'd be much more hesitant to consider a new language for a serious project. Even if the language is tip top, I would still be concerned if it is likely too be around and still relevant in X years. I think build tooling has less of a chicken-and-egg problem to adoption because you could always switch to another tool later. And once somebody uses your build system you're already half the way there to using the full thing.

jwatte3• 10 years ago

Compare to the history of: - D - Jai - Rust Each of which have had a very similar pitch. How is it different this time?

pjmlp10• 10 years ago

Most of which from people that never used anything else and think C was some kind of wonderful invention by two guys at AT&T that just want to have an easy way to implement a compiler, by ignoring what everyone else has done before.

Had UNIX been a commercial OS instead of having the source code available for free, C would just be another footnote on the history of system programming languages.

_pmf_• 10 years ago

Almost half the comments here are just to remind everyone that C can/will never be replaced.

As far as I can tell, this view is completely consistent with this PL's author's view.; he aims to leverage existing C code based and gradually switching parts over where possible; that's embracing C rather than shunning it.

fspeech3• 10 years 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?

AndyKelley7• 10 years 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.

fspeech3• 10 years 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• 10 years 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?

steveklabnik12• 10 years 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

dsego• 10 years ago

This man is a prolific genius.

http://genesisdaw.org

http://libsound.io

http://groovebasin.com

a-nikolaev• 10 years ago

Yeah, he is awesome~ cannot upvote this twice. And I think, his design decisions are very clear and straightforward too.

pmontra2• 10 years 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

[2] https://en.wikipedia.org/wiki/Generic_programming

tom_mellior2• 10 years ago

One more syntax issue:

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".

pmontra2• 10 years ago

Agreed, %return is confusing and sends the reader down a wrong path.

Your last example could work if error is the default name for the error variable, which makes sense.

codygman3• 10 years ago

https://github.com/andrewrk/zig/issues/176

__david__• 10 years ago

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.

No, no no! I really hate that trend in newer languages (rust and go, I'm looking at you). C got this right.

codygman3• 10 years ago

Make issues. I made one for the %% operator:

https://github.com/andrewrk/zig/issues/176

web0072• 10 years 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• 10 years ago

I don't think this has anything to do with "suffix-if".

majewsky6• 10 years ago

Yeah, that's just if as an expression, replacing the ?: operator. Compare to

  return (value >= radix) ? error.InvalidChar : value;

web0072• 10 years 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.

kennell• 10 years 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/hell...

abricot• 10 years 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.

dilap2• 10 years ago

yeah i agree the specific choice of % seems unintuitive, ugly, not great to type, but i love the functionality...

codygman3• 10 years ago

https://github.com/andrewrk/zig/issues/176

lisper• 10 years 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.

wmu• 10 years 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• 10 years 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/ , 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• 10 years 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• 10 years 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?

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

Related Stories