C used to be my favorite language, but there were still some things I didn't like about it. Zig seems like everything I wish C was, really excited for the 1.0 release
before I learned about Zig I had been fantasizing about creating a C-like language that addresses various flaws and has a wee bit of modernity (like defer from Go); was just going to do this as my own little research project. Now that I've seen Zig, well it checks off everything I wanted to address, its open source, has a going community, and a fair amount of maturity of implementation even though its such a new language. Am now going to spend all that time learning about Zig.
I'm not hyped by Zig's syntax, I'm still on the fence, but I have to admit this guy is right down to earth: *_"If we're always gonna be lazy, then we better make the lazy path the correct one."_* Exactly. People are always trying to change what realistically will never change. You cannot solve a problem by going against the natural way of things and having unrealistic expectations about people. If the road goes left, the solution has to involve turning left.
Yeah, and people try solve problem of turning left by turning right, and when they fail they say "we didn't turn right enough", which is true (270° + 360° * N turn is always possible), but utterly ridiculous.
"natural way of things" what exactly is the natural way of things I think you are fundamentally underestimating how hard it is to answer that question. After all if we use natural in it's literal sense. Programming languages are artificial constructs not natural in any way. So I don't see how we can know the natural way. I do agree with your broader point about making languages "safer" because we are inherently "lazy"
@@monsterhunter445 clearly the natural way for people to go is to write less code and cleaner, rather than more code and cluttered. It's not hard to see it. At the very least, though, when you try to go against something and it still never goes the way you want, then you know that's one way it will ever go. I can think of quite a few unrelated examples where people keep trying to make things go the way they never will.
I am not a coder or tech guy...im a business person trying to learn enough to understand why the tech world can't solve my problems in a way that is fast, secure and reasonably future proof. What a fascinating world you all live in and I'm glad people are trying improve things.
It's a very complex issue, I will try to outline the 3 main reasons: 1) There's a strong market pressure to release ASAP, even at a sacrifice for quality. It almost doesn't matter how bad your product is, because if it's the only product for a year before any other release, well, there's just no alternatives. It's such a massive first mover advantage that the whole industry is geared towards releasing things fast, so a lot of the tools and decisions stem from that, and this ecosystem naturally forces others to incorporate these tools, or releases take even longer, because now everything needs to be done from scratch. 2) Another strong pressure is towards making the tech accessible to as many people as possible. The good programmer pool is pretty limited and there's an extremely strong competition. In many cases, a medium programmer or even a bad programmer is better than no programmer, but if the tools are too complex, well, the medium and bad programmers can't use them. This creates a trend of dumbing down the tools so that more people can use them, which in turns means there are more programmers who can get the job done, meaning there's less competition, because not every application is an airplane software. This is generally good, but the side effect is that you get the majority of the tools and programmers that do a bad job, and from your perspective, it's very difficult to separate the weed from the chaff. In other words, it's not so much that the tech world can't solve your problems, it's more like it's very difficult to find people and tools in the tech world that can, and this will continue to be the case until there's more demand for software than there's supply of competent programmers. 3) It's beneficial for programmers to write bad software, and write it moderately slowly. If you write clean, maintainable, fast code and do it quickly, well, in a year you won't have a job, because you've done the lion's share of work, and now a cheaper, less qualified person can maintain it. On the other hand, if you write a convoluted mess that nobody except you can touch without the risk of it breaking, take your pace and leave a lot of room for "improvements", you've secured a job for a long time.
@@jstenberg3192 Sir, please explain me what motivates you to learn at this age and not even a tech guy anymore. Probably your motivation will be inspiration for me to get in discipline.
@peezieforestem5078 That is a poor and weak way of thinking(about 3), one should do things good wherever it is done. If you lose your job doing the good way, the job is possibly bad and more importantly you finished your mission there, in your scenario you become bad in a bad job that you created or is reinforcing while there are better ones out there. Improve the life for you and the others doing what is good. Also, think with me, doing the good is a thing, giving all your time and life energy is another. There are lots of people giving lots of energy but still doing a bad work, that is a lack of self-control and learning.
Really excited to see this language grow and develop. Many higher lever languages are first written in C. I wonder how quality will increase as more projects adopt zig? In particular, my interest is in security and distributed systems. Zig seems like the perfect language to design a secure higher level language in.
And yet Zig has no ambition of being a secure language; it only explores elegant ways to solve some of C's fundamental problems. Arguably higher-level language implementations are complex software in and of themselves, with no low level ambitions, they don't manipulate hardware directly, they receive text and output machine code of some kind (real machine or virtual machine), and would benefit more from being developed in a security and correctness oriented language, and they also benefit quite a bit from expressive capabilities of higher level languages, so C++ seems to be more commonly used than C, but i might be wrong, i haven't actually done a tally. The most common strategy for higher level languages is for the canonical implementation being written in itself, examples being D, Rust, Nim, Ocaml, Scala, Vala, Sather, Go and so on. The first implementation in this case was usually written in C or C++ but after a short development stage of usually only a handful months, nothing of this implementation remains. The initial implementation (bootstrapper) is usually quite deliberately shoddy, as it needs to only be able to compile the smallest useful subset of the language, from where on it's better off rewritten in the target language, and its quality and development velocity wouldn't necessarily improve by choosing a better language, and is also irrelevant over the useful life of the target language.
If you want secure, Rust is a lot closer than Zig. We still don't quite have the language that *really* cares about security as a whole, to my knowledge, at least with the C ABI, no GC restrictions in this talk.
@@SimonBuchanNz I'm not too crazy about Rust. The languages that care about security often make use of capabilities-based security. Check out the Pony programming language and look into Mark Miller's work.
@@leosanchez9115 I thought pony talked a good game, but I'm yet to be convinced by the little I've seen so far. Capability based security is clearly the way to go in general though.
Amazing. The elegance of the solutions described here are just ... wow. As a recent convert to Go, part of me wishes somehow the two could combine, but Go started down a road of requiring an (albeit very good IMHO) GC and segmented/copied stack architecture which is incompatible with plain C (without the usual use of language bindings, etc.), making any sort of bi-directional ABI compabitility with plain C such as Zig offers, implausible. So... with zig's deep ability to both *use* C headers/libs, and its ability to *emit* true C-world ABI binaries, there is an amazing opportunity here to *incrementally* (key word) migrate the C-based foundation of all modern OSes and standard libraries to a safer, cleaner language. If zig could become self-compiling (eliminate LLVM, or port LLVM to zig).. C could be eliminated? Existing OSes (even compilation units within an existing kernel -- imagine re-writing Linux, file by file, to zig without breaking compatibility), drivers and userspace utils could be eventually transformed to pure zig with no release interruption, no world-breaking forks. One day, release notes would simply state "... C support is now deprecated. OS/product X builds with zig, by default.", bootloader to kernel to userspace. Even if Rust can do all of the above -- if zig is just more natural to use for C programmers, it might have a very good chance.
I cut my teeth on C 2 decades ago. This dude knows the pain points and I'm glad he has enough time and resources to deliver. If Zig is the eventual outcome, so be it. It looks fine to me. Great job
I've been following a language for some time now called V and it was a cool little project for awhile. It was tiny, had decent C interop, and was geared toward addressing problems with some modern programming languages. And it was simple. You could learn the language in a couple of days. I took a break from programming for a few months and I updated it and it's a mess. 7:38 really speaks to that - it's trying to be everything to everyone. It wants to be low-level and very memory safe, meanwhile its own stdlib has cross-platform window handling and opengl included natively. Excited to check zig out, I'm happy for it's uncompromising nature.
@@TheMrKeksLpif it’s the language I’m thinking of, they basically made claims about their memory model (guaranteed memory safety with neither a GC nor a borrow checker) that would have been impossible to fulfill without magic.
A few days ago, I watched Herb Sutter's talk "The Evolution of C++ - A Typescript for C++" and he highlighted the importance of an easy migration path (i.e. backward compatibility) when evolving a language (the decade it took to move from Python 2 to 3 being a prime example). That's where my mind went when Andrew mentioned that Zig can compile C code. I do a lot of embedded systems work at the moment, and the cross-compilation feature plus the ability to easily work with C has my interest.
This is particularly toolchain support rather than language support of C. You can declare a C function/type in zig and use it as long as you link it. The build system makes it easy to link C files after building them, but you can't just act as if a C function exists or by pointing it at a .h file. You can generate a .zig file from a .h file though and use it, but you can do that with a lot of languages. So the interop is not as easy as using C from C++, but the build system makes up for the language limitation.
@@nextlifeonearth you can, practically though? @cImport, then you can basically #include etc. yes, this is done by converting it to .zig, but also, like, its builtin and as simple as doing a #include really.
I'm SO pleased that there's finally someone out there among the "movers and shakers" throwing a little shade at the C preprocessor... I've been quietly hating it for about 25 years now.
It depends. If you’re a C programmer, than yes, the syntax of Zig is practically the same. But if you’re a modern C++ programmer and/or a ML programmer, then Rust’s syntax is much more readable. ReasonML and Rust are quite close when it comes to syntax.
@@awwastor I came from C++ and Rust is pretty unreadable. For example: `Has => (1..=3).contains` This looks nothing like C++, nor anything intelligible.
@@totheknee Yeah that’s true. That looks like ML or even python. I like the Rust syntax more tbh.. “Has => (1..=3).contains” In this case I’m guessing you mean pattern matching(in a macro or match), but then Has needs to be an enum value, and the (1..=3).contains would need to be an instruction, so contains(x) I guess. It seems pretty readable to me, though it is quite far away from C++. For me the most unreadable thing in rust are c-style casts (the “as” keyword).
I am a C++ user and sometimes I miss this simplicity like Zig. On the other side, part of that complexity is also useful. I am with an eye on Rust, D, Nim and Zig lately. But for now, I stick to C++ and C#. I like to get the job done so anything that is not viable to finish full software is discarded directly on my side.
yep, I always think of Rust as "the better C++", while Zig is "the better C". i personally really love both, but of course theres nothing wrong with sticking to C or C++ as long as they work out for you
@@rustmc i am really excited about zig, but if you want to get the job done rust has already great support for many libraries, you can definitly write production code with it.
I've been using D many years ago. Even made a small project at work using it. But I've dropped it. D is kind of stagnating and what's worse - it doesn't introduce any new ideas.
Herb Sutter confirmed in a recent Cppcon talk that thrown C++ exceptions allocate memory on almost every platform, so you can't use them to catch a bad alloc, at least not if you are very close to the memory limit.
@@Knirin Well you could pass them back on the stack like Rust does with Result, but that would increase the stack size and break the ABI. There is no free lunch…
"why can't it *just* be this way" well you see.... there's over 40 years of history behind that reason and many architectures in-between. I look forward to new programming languages in 20 years where a young language designer goes "why didn't they *just* do it this way in the 2020's??!?!?!?" Zig is interesting. We'll see how it goes.
Re defer and errdefer: Is it possible to mark a type as "resource" so you get a compile error when you forget to call defer or errdefer and just return from the code that creates it WITHOUT giving the resource to anyone?
I like this idea a lot! I don't know whether it fits into the Zig ethos of simplicity, but it's certainly worth an RFC. If I had to guess, it'd probably be relegated to "user-land" to write an IDE tool. But even that would be super handy. Little IDE warnings when structs that have destroy/close/release methods do not call them in the same scope. I like it.
I would reformulate "the simple, lazy way to write code must perform robust error handling". Robust error handling is a difficult problem. I would reformulate it as "the simple, lazy way to write code must fail safely or handle the error but never ignore it". I think this is a better way of looking at it. Imagine I want to create a piece of software, it reads from disk, does some operations and on the way to that it must read data (could fail), parse it (could be incorrect). If I need robust handling for each step, now I have a program where I have to write the code and the failure handlers, both. But I could be interested in just handling happy path (assume that if the reading fails or the parsing fails just finish the program, but without ignoring the error silently). Doing so would save time, because now I do not need to think of the error handling but I am still sure that it will fail safely. Later, if I ever need, I can add more robust error handling. This robust error handling can be as complicated as the program itself almost: ignore parse error vs no parse error, ignoring parse situation is safe vs is not safe... if the error for parsing makes the whole thing lose information or can be reconstructed from some redundant info... as you can see this is as complicated or more than writing the happy path maybe. So all in all, the important thing is that errors are not ignorable. This is a good property of exceptions, even if exceptions are not a panacea.
thats exactly what try and ! are for though. just write the happy path and let the calling context handle it. they basically behave the same as exceptions but you target the specific calls that trigger them, rather than the standard try block which has so much room for misuse and abuse
@@johnbotris8187 The happy path would not be putting "try" and "!" everywhere when you use the happy path. It's pointless clutter because when it comes to things like out of memory errors, you aren't going to handle it down in the bowels of your code. So all you're code is going to end up putting these useless decorations until you get to a top level error handler. This is what Java did by default, and it's wrong.
How is this better? 17:48 If I understand this correctly, this code seems to be executed at runtime to determine the operating system. At least in this IF block there is no comptime keyword that indicates otherwise. So if this is evaluated at runtime, this would have the advantage that the binary could run anywhere, but it also comes at the cost of making the binary larger. And if this occurs in time-critical places, it will be slower than a solution where the code is simply replaced by platform-specific code at compile time using a preprocessor, as in C.
I think it's that we can be bad at what we do. You don't have to be particularly smart to be a programmer, in other branches of engineering if your product isn't designed really well it usually fails, ours it's okay if it fails so long as it works a good majority of the time, most of our stuff is not at all well designed, due to business constraints, and really blind leading the blind tbh.
I got my hopes up to be able to cross compile C code from Linux to macOS using Zig: The only other desktop OS I can cross compile to is Windows (with GNU libc).
45:56 It's a pity, that inline assembly is not allowed. I love assembly language. But i understand, why they do it. But I would still have preferred it if it were possible.
Preprecessors sometimes usefull, you do not want linux branches active windows even if those branches are not executed. Those code sections are striphed off before compilation.
Can I use zig to cross compile a simple command line C application on Linux for macOS? With mingw it is easily possible to cross compile on Linux for Windows, but targeting macOS is a different (and horrible) story.
I really want to know what Zig brings to the table over a feature-restricted C++. You can do most, if not all of these things in C++, and you don't HAVE TO use the nasty stuff.
He's fixing C, great, but then why scramble all the syntax? It would have been far more useful to the rest of the world if he maintained as much of the C syntax as possible.
I am not an expert by any means, but from what I understand C (and especially C++) are deceptively complicated to parse. For example, in c a function call can be ambiguous with a variable declaration. So when you parse C you need to do a certain amount of semantic analysis at the same time. While this won't be a bottle neck when creating release builds, frontend performance is more important for debug builds and language servers. This can be mitigated by incremental compilation, but the complexity trade off is steep because now the compiler is a function of the current source and previous collateral. Eli Bendersky has several interesting blog posts talking about some of the complexities in parsing c and c++ if you are interested. Zig also lacks multiline comments (and has a unique multiline string syntax) so that each line can be tokenized individually. This means that syntax highlighting in a text editor only needs to be concerned with the lines on the screen. By contrast, in c the multiline comments mean that you must always scan up the file to see if you are in a comment or not. This can cause performance issues in editors when working on large files, so some tools limit the length that will be scanned, but this can cause desyncs where it inverts what should be a comment. @@HairyPixels
Which needs objects which introduces complexities and implicit behaviour Explicit is better than implicit, it makes you reason about code easily Also, defer works best with c code Also, defer makes the code linear, you don't introduce a wrapping around an object to provide a destructor, you just call existing c init function and just call its free in the next line. Much simpler, you know there is destruction without looking around the code for destructor you didn't notice for each object you meet
I am not an embedded dev, so could you explain to me what other options would be preferable? My thinking would be that as you can handle panicking, you can handle OOM just fine.
@@sergeifomin9901 In Rust, panics cannot be caught or handled. Only on thread boundary - so, you'd have to have a master thread that manages/restarts a child thread. It might not be doable on embedded. Check out Zig in Production by Jens Goldberg talk. Jens mentions that OOM is the primary reason he doesn't use Rust (aside from slow compilation of course).
Not good: 13:44 So i can use this function during compile time and get for example a result, that is very hardware specific. I could for example use my MAC of my network card. Then i compile the code, create a binary and sent it to my friend and there the software will fail, because my MAC isn't identical with his MAC.
34:35 not so fast, where is checking for close errors? "A careful programmer will check the return value of close(), since it is quite possible that errors on a previous write(2) operation are reported only on the final close() that releases the open file description. Failing to check the return value when closing a file may lead to silent loss of data. "
std.os.close does not return any errors in zig because what are you going to do with it? Obviously not retry close(2). An application which wants to ensure writes have succeeded before closing must call fsync before close. "A careful programmer who wants to know about I/O errors may precede close() with a call to fsync(2)."
That's the documentation for libc close. The close OS syscall does not have the possibility of failure. That's something libc introduced into the equation. With Zig you are not forced to use libc.
@@AndrewKelley Linux source is obviously available online. In include/linux/syscalls.h, we can see: asmlinkage long sys_close(unsigned int fd); In fs/file.c we can see that close syscall calls close_fd function. And we can see that close_fd can return -EBADF then calls filp_close from fs/open.c which tries to flush and may also return other error codes. By the way there is the "same" issue in Rust standard library (fd.rs): close call result is ignored. And it is not an oversight: this is by design. "drop" must not fail, just like C++ destructors must not fail either. For me that is a major flaw of RAII. In C you can try to write perfect error handling (checking results of close, CloseHandle, HeapFree...) with a bunch of gotos. I guess in Zig deferred code is not supposed to fail (return an error code)?
umh, but what does it mean for "language" to have it? like the fxn u're showing - aint that like compiler itself.... umh ohw wait, by language u mean the zig standard libs so to speak right?
@@origamibulldoser1618 that still leads to heap fragmentation which causes even more cpu slowdown. babysitting / garbage collection is never a good idea for serious software where performance is concerned
25:00 isn't that a leaking file descriptor? Ok, its the main function, so it doesn't matter, but if it wouldn't be and if write would fail it would return an error and not close the file.
What I don’t understand is if he just wanted it to be C with improvements, why did he change the syntax so drastically? It’s quite an adjustment to write var name: type = value Instead of type name = value I’m sure it has a reason, maybe to make it easier to differentiate functions and variables? But he didn’t really talk about it.
I like the language, but the name of it is a bit unfortunate. As a citizen of East European country I can't help but remember a certain greeting where the first word sounds like Zig and the second word sounds like Heil.
On the "Why doesn't this work" slide (12m00s into the video), isn't the solution in C to use "enum { buffer_len = 100 };"? I like the Zig approach, but I think this example might need revisiting.
7:19 Eventually, someone is going to download the source-code off github & start adding C++ features to Zig and it'll become a Zig++ monstrosity like C++. Instead, he should put these extra features in the Zig++ spec, but that doesn't mean he has to implement them... Instead, if he gets ahead & the game & takes control of the software specification for Zig++ then he can at least hopefully prevent some of the insanity that found it's way into C++ while also making Zig & Zig++ 100% compatible.
C++ back then added so much onto C that it made a lot of sense for people to use it instead of C. I am pretty sure that if someone were to create "zig++", when there's no reason to and nobody probably ever will, it will just die silently with nobody using it. It's really rare for PL authors to resist the temptation of adding new cool features but Andrew Kelley is doing an amazing job at this. Zig might be aimed to be a better C but it doesn't need to have as low of productivity as C; it's 2020 ffs.
I don't think so. Have you ever seen a software engineer say "fully digital voting is great, we don't need a hardcopy paper trail or an independent verification method; let's put all our eggs in one basket, the technology is guaranteed perfect and can't possibly go wrong or be manipulated invisibly." Circumstances can demand compromises, that we can agree to begrudgingly.
12:58 TFW the creator of a language you're interested casually puts "hail Satan" in the middle of his talk and you're trying to decide if it's a joke or a dog whistle.
C's biggest problems are the lack of abstraction or standard library which makes it unproductive to use and the absense of any safety. Zig addresses safety but other languages do as well like Rust, Ada, Nim. C++ does not address safety and also lacks powerful language abstractions. It just has verbose syntax and complicated rules. I only watched this video but I don't see a unique solution which D or Nim wouldn't have. * compile-time constants are "enum" in D * conditional compilation has "version", "debug" or "static if" in D. * "comptime" is "static" or "enum" in D. But explicit compile-time code makes code harder to maintain. It typically leads to "brain methods". However, Zig's solution is admittedly simpler, particularly simpler than explicit "template" concepts. * "comptime" arguments are template parameters (with complicated type system they can become dangerous for productivity very fast). * stack traces are pretty standard. * "defer" and "errdefer" is like "scope(exit)" and "scope(failure)" in D. Nim's lead programmer almost wanted to kill this feature from Nim. Fortunately not. * switch in the catch-clause looks like "final switch" in D * own build system. * D features an own C compiler which doesn't support VLAs however. Error handling problems apparently not solved: separating responsibilities. Error handling should be separated from the correct paths but cramming them in the same function makes it hard to maintain and read. The real future would be productive safety: code synthesis (automatic code generation from specifications) and verification features like using ghost variable information at runtime and solver-aided programming abstracted via language concepts for very simple use. That's a point where D won't have success. Another thing: Powerful iterator abstraction instead of pointers. Automatically generate optimal iteration code based on where the abstraction is used without using indices or other meaningless helper variables. I'd like to see clever aspect-oriented features to separate code and data structures into separate parts which can be combined automatically. Uninspired pesky tasks like transforming data structures and complex values into reordered or subset data structures should be auto-generated code. Physical structure of objects could be abstracted away completely, be interchangeable and only needs to be explicit for interfacing with foreign languages / machines.
one of the biggest issues I have working with C is that its just not human readable. Compare that with something like swift where code reads out like English sentences.
Looks like that's a TODO: github.com/ziglang/zig/blob/057a5d4898f70c6a8169c99375fbb8631e539051/src/translate_c.cpp#L4365 Just a matter of figuring out the libclang API and setting is_packed to true on the AST node.
"Perl applications are not going to do advantage of a python library...", that's a false statement! There is a module in perl, allowing to use an inline python in perl code and use python libraries. In addition, there are many other interesting modules in perl, like allowing inline and library C, ASM, TCL and some others.
3:17 given that the most used programming languages in the industry are garbage collected, even for HFT like Java/C# and for the web are still Java/C#/PHP/Python/Ruby the title of that slide is a little too wrong. Those languages are widely used, and they were designed for those specific use-cases because no one wants to invent a hammer to nail everything including screws, remember "right tool for the job" And docker yes, I agree that was the case, at least in part, but mostly was about ensuring that also testing and the execution of the applications was reproducible because most programming languages with a few exceptions like anything that runs on the jvm, clr, beam or anything that uses memimage-based development ala smalltalk/common-lisp suck at isolation from the OS because the most popular languages like php, ruby, python, c, perl are tightly integrated into Linux. with anything that runs on the jvm/clr/beam you can easily distribute a precompiled signed package to deploy it easily. it can be compiled easily anywhere as long as it remains in this curated environment easily because all you need is the SDK of each of them. With memimage/beam is even easier because you don't even have to restart the environments. the problem and the culprits are the shitty php/python/perl/ruby/nodejs
we'll see how long that lasts when zig compiles several orders of magnitude faster. 15 minute compile times are a hefty price to pay for the borrow checker.
"C was broken, and I fixed it" -- haha, love it.
C used to be my favorite language, but there were still some things I didn't like about it. Zig seems like everything I wish C was, really excited for the 1.0 release
I agree
before I learned about Zig I had been fantasizing about creating a C-like language that addresses various flaws and has a wee bit of modernity (like defer from Go); was just going to do this as my own little research project. Now that I've seen Zig, well it checks off everything I wanted to address, its open source, has a going community, and a fair amount of maturity of implementation even though its such a new language. Am now going to spend all that time learning about Zig.
frfr really excited
Wish they would drop the const keyword though
@@drygordspellweaver8761 mutability is important.
I'm not hyped by Zig's syntax, I'm still on the fence, but I have to admit this guy is right down to earth:
*_"If we're always gonna be lazy, then we better make the lazy path the correct one."_*
Exactly. People are always trying to change what realistically will never change. You cannot solve a problem by going against the natural way of things and having unrealistic expectations about people. If the road goes left, the solution has to involve turning left.
Yeah, and people try solve problem of turning left by turning right, and when they fail they say "we didn't turn right enough", which is true (270° + 360° * N turn is always possible), but utterly ridiculous.
@@bogdanpanchuk296 I don't think you understand what analogies are.
@@fennecbesixdouze1794 "we need MORE layers of the abstraction" etc.
"natural way of things" what exactly is the natural way of things I think you are fundamentally underestimating how hard it is to answer that question. After all if we use natural in it's literal sense. Programming languages are artificial constructs not natural in any way. So I don't see how we can know the natural way. I do agree with your broader point about making languages "safer" because we are inherently "lazy"
@@monsterhunter445 clearly the natural way for people to go is to write less code and cleaner, rather than more code and cluttered. It's not hard to see it.
At the very least, though, when you try to go against something and it still never goes the way you want, then you know that's one way it will ever go. I can think of quite a few unrelated examples where people keep trying to make things go the way they never will.
I love the involuntary case study of the slideshow breaking just as Andrew was making a joke about software being broken.
I am not a coder or tech guy...im a business person trying to learn enough to understand why the tech world can't solve my problems in a way that is fast, secure and reasonably future proof. What a fascinating world you all live in and I'm glad people are trying improve things.
It's a very complex issue, I will try to outline the 3 main reasons:
1) There's a strong market pressure to release ASAP, even at a sacrifice for quality. It almost doesn't matter how bad your product is, because if it's the only product for a year before any other release, well, there's just no alternatives.
It's such a massive first mover advantage that the whole industry is geared towards releasing things fast, so a lot of the tools and decisions stem from that, and this ecosystem naturally forces others to incorporate these tools, or releases take even longer, because now everything needs to be done from scratch.
2) Another strong pressure is towards making the tech accessible to as many people as possible. The good programmer pool is pretty limited and there's an extremely strong competition. In many cases, a medium programmer or even a bad programmer is better than no programmer, but if the tools are too complex, well, the medium and bad programmers can't use them.
This creates a trend of dumbing down the tools so that more people can use them, which in turns means there are more programmers who can get the job done, meaning there's less competition, because not every application is an airplane software. This is generally good, but the side effect is that you get the majority of the tools and programmers that do a bad job, and from your perspective, it's very difficult to separate the weed from the chaff.
In other words, it's not so much that the tech world can't solve your problems, it's more like it's very difficult to find people and tools in the tech world that can, and this will continue to be the case until there's more demand for software than there's supply of competent programmers.
3) It's beneficial for programmers to write bad software, and write it moderately slowly. If you write clean, maintainable, fast code and do it quickly, well, in a year you won't have a job, because you've done the lion's share of work, and now a cheaper, less qualified person can maintain it. On the other hand, if you write a convoluted mess that nobody except you can touch without the risk of it breaking, take your pace and leave a lot of room for "improvements", you've secured a job for a long time.
Are you really not a tech guy?
You are watching a video that programmers don't even watch or get to know.
@@shrin210 Finance major Econ minor. I mean I play Hell Let Loose and did a simple BASIC program in 1984....so if that is a tech guy..ok!
@@jstenberg3192
Sir, please explain me what motivates you to learn at this age and not even a tech guy anymore.
Probably your motivation will be inspiration for me to get in discipline.
@peezieforestem5078 That is a poor and weak way of thinking(about 3), one should do things good wherever it is done. If you lose your job doing the good way, the job is possibly bad and more importantly you finished your mission there, in your scenario you become bad in a bad job that you created or is reinforcing while there are better ones out there. Improve the life for you and the others doing what is good. Also, think with me, doing the good is a thing, giving all your time and life energy is another. There are lots of people giving lots of energy but still doing a bad work, that is a lack of self-control and learning.
I think he makes a lot of good points and I use C a lot.
The native printf language support with the comptime support then showing how comptime supports generics was awesome. Nicely done!
Really excited to see this language grow and develop.
Many higher lever languages are first written in C. I wonder how quality will increase as more projects adopt zig?
In particular, my interest is in security and distributed systems. Zig seems like the perfect language to design a secure higher level language in.
And yet Zig has no ambition of being a secure language; it only explores elegant ways to solve some of C's fundamental problems. Arguably higher-level language implementations are complex software in and of themselves, with no low level ambitions, they don't manipulate hardware directly, they receive text and output machine code of some kind (real machine or virtual machine), and would benefit more from being developed in a security and correctness oriented language, and they also benefit quite a bit from expressive capabilities of higher level languages, so C++ seems to be more commonly used than C, but i might be wrong, i haven't actually done a tally. The most common strategy for higher level languages is for the canonical implementation being written in itself, examples being D, Rust, Nim, Ocaml, Scala, Vala, Sather, Go and so on. The first implementation in this case was usually written in C or C++ but after a short development stage of usually only a handful months, nothing of this implementation remains. The initial implementation (bootstrapper) is usually quite deliberately shoddy, as it needs to only be able to compile the smallest useful subset of the language, from where on it's better off rewritten in the target language, and its quality and development velocity wouldn't necessarily improve by choosing a better language, and is also irrelevant over the useful life of the target language.
If you want secure, Rust is a lot closer than Zig. We still don't quite have the language that *really* cares about security as a whole, to my knowledge, at least with the C ABI, no GC restrictions in this talk.
@@SimonBuchanNz I'm not too crazy about Rust. The languages that care about security often make use of capabilities-based security. Check out the Pony programming language and look into Mark Miller's work.
@@leosanchez9115 I thought pony talked a good game, but I'm yet to be convinced by the little I've seen so far. Capability based security is clearly the way to go in general though.
You predicted the future ;) we now have Bun in the javascript world.
Amazing. The elegance of the solutions described here are just ... wow.
As a recent convert to Go, part of me wishes somehow the two could combine, but Go started down a road of requiring an (albeit very good IMHO) GC and segmented/copied stack architecture which is incompatible with plain C (without the usual use of language bindings, etc.), making any sort of bi-directional ABI compabitility with plain C such as Zig offers, implausible.
So... with zig's deep ability to both *use* C headers/libs, and its ability to *emit* true C-world ABI binaries, there is an amazing opportunity here to *incrementally* (key word) migrate the C-based foundation of all modern OSes and standard libraries to a safer, cleaner language.
If zig could become self-compiling (eliminate LLVM, or port LLVM to zig).. C could be eliminated?
Existing OSes (even compilation units within an existing kernel -- imagine re-writing Linux, file by file, to zig without breaking compatibility), drivers and userspace utils could be eventually transformed to pure zig with no release interruption, no world-breaking forks. One day, release notes would simply state "... C support is now deprecated. OS/product X builds with zig, by default.", bootloader to kernel to userspace.
Even if Rust can do all of the above -- if zig is just more natural to use for C programmers, it might have a very good chance.
I think it has a non-LLVM backend now
deep sh*t. like.
I cut my teeth on C 2 decades ago. This dude knows the pain points and I'm glad he has enough time and resources to deliver. If Zig is the eventual outcome, so be it. It looks fine to me. Great job
I come from time to time to this talk to remind myself how awesome is zig. Now I’m even using it at my work :)
I love your approach. Rust sounds like something that can get very complicated.
I've been following a language for some time now called V and it was a cool little project for awhile. It was tiny, had decent C interop, and was geared toward addressing problems with some modern programming languages. And it was simple. You could learn the language in a couple of days.
I took a break from programming for a few months and I updated it and it's a mess. 7:38 really speaks to that - it's trying to be everything to everyone. It wants to be low-level and very memory safe, meanwhile its own stdlib has cross-platform window handling and opengl included natively.
Excited to check zig out, I'm happy for it's uncompromising nature.
Just FYI, V is pretty much a confirmed scam/vaporware at this point
@@TheMrKeksLp I would like to know more about this. Is the somewhere I can read about this?
@@TheMrKeksLpif it’s the language I’m thinking of, they basically made claims about their memory model (guaranteed memory safety with neither a GC nor a borrow checker) that would have been impossible to fulfill without magic.
40:21 "It all comes together in this vortex of synergy" Oh my gosh, I just can't handle this. :-D
go also has error return traces, but requires the programmer to manually wrap errors before returning them. Zig seems a lot nicer.
After doing a few months of Zig after nothing but Go and Python, it's easy to notice that Go's error handling really sucks ass.
A few days ago, I watched Herb Sutter's talk "The Evolution of C++ - A Typescript for C++" and he highlighted the importance of an easy migration path (i.e. backward compatibility) when evolving a language (the decade it took to move from Python 2 to 3 being a prime example). That's where my mind went when Andrew mentioned that Zig can compile C code. I do a lot of embedded systems work at the moment, and the cross-compilation feature plus the ability to easily work with C has my interest.
This is particularly toolchain support rather than language support of C. You can declare a C function/type in zig and use it as long as you link it. The build system makes it easy to link C files after building them, but you can't just act as if a C function exists or by pointing it at a .h file. You can generate a .zig file from a .h file though and use it, but you can do that with a lot of languages.
So the interop is not as easy as using C from C++, but the build system makes up for the language limitation.
@@nextlifeonearth you can, practically though? @cImport, then you can basically #include etc. yes, this is done by converting it to .zig, but also, like, its builtin and as simple as doing a #include really.
I'm SO pleased that there's finally someone out there among the "movers and shakers" throwing a little shade at the C preprocessor... I've been quietly hating it for about 25 years now.
This is probably the single best talk I've ever seen, bravo
This reminds me a lot of Jonathan Blow's JAI language. I'll be watching both with enthusiasm.
I think aspects of it are inspired by jai. I think the github readme references it a few times^^
I follow both too. One major difference is that I've been able to write programs in Zig and that gives it a big headstart in mindshare =)
Same, but I'm starting to wonder if JAI is becoming too complex and Zig will now be the _de facto_ Better C.
@@totheknee JAI will probably a decent C++ replacement, so I'm not to worried if it goes above and beyond the strict code zig has to take on C.
Zig vs Rust? My understnading:
Rust is to replace C++
Zig is to replace C
Great talk, Andrew!
Much more readable than Rust.
It depends. If you’re a C programmer, than yes, the syntax of Zig is practically the same. But if you’re a modern C++ programmer and/or a ML programmer, then Rust’s syntax is much more readable. ReasonML and Rust are quite close when it comes to syntax.
@@awwastor I came from C++ and Rust is pretty unreadable. For example: `Has => (1..=3).contains` This looks nothing like C++, nor anything intelligible.
@@totheknee Yeah that’s true. That looks like ML or even python. I like the Rust syntax more tbh.. “Has => (1..=3).contains” In this case I’m guessing you mean pattern matching(in a macro or match), but then Has needs to be an enum value, and the (1..=3).contains would need to be an instruction, so contains(x) I guess. It seems pretty readable to me, though it is quite far away from C++. For me the most unreadable thing in rust are c-style casts (the “as” keyword).
23:03 that was top quality programmer humor :D
The one and only time the audience actually reacted (audibly) during the talk.
I am a C++ user and sometimes I miss this simplicity like Zig. On the other side, part of that complexity is also useful. I am with an eye on Rust, D, Nim and Zig lately. But for now, I stick to C++ and C#. I like to get the job done so anything that is not viable to finish full software is discarded directly on my side.
yep, I always think of Rust as "the better C++", while Zig is "the better C". i personally really love both, but of course theres nothing wrong with sticking to C or C++ as long as they work out for you
@@rustmc i am really excited about zig, but if you want to get the job done rust has already great support for many libraries, you can definitly write production code with it.
I've been using D many years ago. Even made a small project at work using it. But I've dropped it. D is kind of stagnating and what's worse - it doesn't introduce any new ideas.
Also, check out Odin and Jai, 2 very promising systems programming languages.
Herb Sutter confirmed in a recent Cppcon talk that thrown C++ exceptions allocate memory on almost every platform, so you can't use them to catch a bad alloc, at least not if you are very close to the memory limit.
My understanding is that exceptions require memory allocation by the spec.
@@Knirin Well you could pass them back on the stack like Rust does with Result, but that would increase the stack size and break the ABI. There is no free lunch…
"why can't it *just* be this way" well you see.... there's over 40 years of history behind that reason and many architectures in-between. I look forward to new programming languages in 20 years where a young language designer goes "why didn't they *just* do it this way in the 2020's??!?!?!?" Zig is interesting. We'll see how it goes.
Great stuff! I really like the look and syntax and the build system seems awesome.
Awesome work Andrew. Keep going!! 👍🏻👏🏻
Re defer and errdefer: Is it possible to mark a type as "resource" so you get a compile error when you forget to call defer or errdefer and just return from the code that creates it WITHOUT giving the resource to anyone?
I like this idea a lot! I don't know whether it fits into the Zig ethos of simplicity, but it's certainly worth an RFC. If I had to guess, it'd probably be relegated to "user-land" to write an IDE tool. But even that would be super handy. Little IDE warnings when structs that have destroy/close/release methods do not call them in the same scope. I like it.
I would reformulate "the simple, lazy way to write code must perform robust error handling". Robust error handling is a difficult problem. I would reformulate it as "the simple, lazy way to write code must fail safely or handle the error but never ignore it". I think this is a better way of looking at it. Imagine I want to create a piece of software, it reads from disk, does some operations and on the way to that it must read data (could fail), parse it (could be incorrect). If I need robust handling for each step, now I have a program where I have to write the code and the failure handlers, both. But I could be interested in just handling happy path (assume that if the reading fails or the parsing fails just finish the program, but without ignoring the error silently). Doing so would save time, because now I do not need to think of the error handling but I am still sure that it will fail safely. Later, if I ever need, I can add more robust error handling. This robust error handling can be as complicated as the program itself almost: ignore parse error vs no parse error, ignoring parse situation is safe vs is not safe... if the error for parsing makes the whole thing lose information or can be reconstructed from some redundant info... as you can see this is as complicated or more than writing the happy path maybe. So all in all, the important thing is that errors are not ignorable. This is a good property of exceptions, even if exceptions are not a panacea.
thats exactly what try and ! are for though. just write the happy path and let the calling context handle it. they basically behave the same as exceptions but you target the specific calls that trigger them, rather than the standard try block which has so much room for misuse and abuse
@@johnbotris8187 The happy path would not be putting "try" and "!" everywhere when you use the happy path. It's pointless clutter because when it comes to things like out of memory errors, you aren't going to handle it down in the bowels of your code. So all you're code is going to end up putting these useless decorations until you get to a top level error handler. This is what Java did by default, and it's wrong.
40:55 there should have been a standing ovation instead of a cough
How is this better?
17:48 If I understand this correctly, this code seems to be executed at runtime to determine the operating system. At least in this IF block there is no comptime keyword that indicates otherwise. So if this is evaluated at runtime, this would have the advantage that the binary could run anywhere, but it also comes at the cost of making the binary larger. And if this occurs in time-critical places, it will be slower than a solution where the code is simply replaced by platform-specific code at compile time using a preprocessor, as in C.
I think it's that we can be bad at what we do. You don't have to be particularly smart to be a programmer, in other branches of engineering if your product isn't designed really well it usually fails, ours it's okay if it fails so long as it works a good majority of the time, most of our stuff is not at all well designed, due to business constraints, and really blind leading the blind tbh.
IME any IDE with clang-based code model will work flawlessly when you use macros. Some even support displaying the post processed text on mouse over.
*Qt Creator* does that, what other IDEs do you know?
@@nxxxxzn I believe Clion and KDevelop (with the clang plugin enabled) support it too but I'm a QtCreator user myself.
I got my hopes up to be able to cross compile C code from Linux to macOS using Zig: The only other desktop OS I can cross compile to is Windows (with GNU libc).
45:56 It's a pity, that inline assembly is not allowed. I love assembly language. But i understand, why they do it. But I would still have preferred it if it were possible.
Preprecessors sometimes usefull, you do not want linux branches active windows even if those branches are not executed. Those code sections are striphed off before compilation.
17:12
Move Zig. For great justice.
Can I use zig to cross compile a simple command line C application on Linux for macOS? With mingw it is easily possible to cross compile on Linux for Windows, but targeting macOS is a different (and horrible) story.
It can. Check this tweet from Andrew: twitter.com/andy_kelley/status/1043597913304260608
yes
12:48 you got me there
28:31 stack trace & error trace..
it would have been good to see this in the stderr output itself
30:46 forced nullability
i need to read why that is bad? i just barely know about NPE, but not its implications
I really want to know what Zig brings to the table over a feature-restricted C++. You can do most, if not all of these things in C++, and you don't HAVE TO use the nasty stuff.
Awesome talk Andrew, sorry the audience was full of wet napkins...
He's fixing C, great, but then why scramble all the syntax? It would have been far more useful to the rest of the world if he maintained as much of the C syntax as possible.
Because C syntax is ugly compare to Zig. Zig has a python-like and readable syntax.
@@sarfaraz73 That's all subjective. I'm not a c programmer but I'd be curious if they think C is ugly and what parts they want changed on average.
I am not an expert by any means, but from what I understand C (and especially C++) are deceptively complicated to parse. For example, in c a function call can be ambiguous with a variable declaration. So when you parse C you need to do a certain amount of semantic analysis at the same time. While this won't be a bottle neck when creating release builds, frontend performance is more important for debug builds and language servers. This can be mitigated by incremental compilation, but the complexity trade off is steep because now the compiler is a function of the current source and previous collateral. Eli Bendersky has several interesting blog posts talking about some of the complexities in parsing c and c++ if you are interested.
Zig also lacks multiline comments (and has a unique multiline string syntax) so that each line can be tokenized individually. This means that syntax highlighting in a text editor only needs to be concerned with the lines on the screen. By contrast, in c the multiline comments mean that you must always scan up the file to see if you are in a comment or not. This can cause performance issues in editors when working on large files, so some tools limit the length that will be scanned, but this can cause desyncs where it inverts what should be a comment. @@HairyPixels
@@sarfaraz73 Disagree, I'm checking this Zig language out and I don't like the syntax at all, specially arrays.
C has some bad syntax too, like switch statements.
Zig is a monster!... in a very good way.
Why most Lisps? Why not all Lisps? If most Lisps, which are not crossed out? Lisp newbie here.
very amazing
Was it moved for great justice though?
the need for defer could be mitigated entirely via RAII semantics and just have the handle close itself when it leaves a block
Which needs objects which introduces complexities and implicit behaviour
Explicit is better than implicit, it makes you reason about code easily
Also, defer works best with c code
Also, defer makes the code linear, you don't introduce a wrapping around an object to provide a destructor, you just call existing c init function and just call its free in the next line. Much simpler, you know there is destruction without looking around the code for destructor you didn't notice for each object you meet
1:32 so the slide was really stuck lol!!
How necessary is the Zig package manager? Can I have a project on an air-gapped computer just getting all the packages through a USB drive?
The zig package manager doesn't exist currently. Pretty sure a tarball would work for copying deps
The package manager is just a convenience. You can simply copy-paste deps to your project and it will work.
really good
@52:13 What happens on OOM in Rust? ;-)
Panic/Crash?
I am not an embedded dev, so could you explain to me what other options would be preferable?
My thinking would be that as you can handle panicking, you can handle OOM just fine.
@@sergeifomin9901 In Rust, panics cannot be caught or handled. Only on thread boundary - so, you'd have to have a master thread that manages/restarts a child thread. It might not be doable on embedded. Check out Zig in Production by Jens Goldberg talk. Jens mentions that OOM is the primary reason he doesn't use Rust (aside from slow compilation of course).
Ok I thought I would be able to comprehend because I did some stuff in python... nah... if my brain had a compiler, it would self destruct
This is what I hate about programming. You have to compile and execute code in your head every time you have to read it.
Feel in love, just wow
Not good:
13:44 So i can use this function during compile time and get for example a result, that is very hardware specific. I could for example use my MAC of my network card. Then i compile the code, create a binary and sent it to my friend and there the software will fail, because my MAC isn't identical with his MAC.
Zig for C devs
11:56 seems to work fine in C. I guess the screenshot is for a particular version of GCC? seems to undermine the point though.
I tried it out on my setup. It worked with Clang, but not with GCC.
GNU gcc (GCC) 10.2.0
clang version 11.1.0
34:35 not so fast, where is checking for close errors?
"A careful programmer will check the return value of close(), since it
is quite possible that errors on a previous write(2) operation are
reported only on the final close() that releases the open file
description. Failing to check the return value when closing a file
may lead to silent loss of data. "
std.os.close does not return any errors in zig because what are you going to do with it? Obviously not retry close(2). An application which wants to ensure writes have succeeded before closing must call fsync before close.
"A careful programmer who wants to know about I/O errors may precede
close() with a call to fsync(2)."
That's the documentation for libc close. The close OS syscall does not have the possibility of failure. That's something libc introduced into the equation. With Zig you are not forced to use libc.
@@AndrewKelley
Linux source is obviously available online.
In include/linux/syscalls.h, we can see:
asmlinkage long sys_close(unsigned int fd);
In fs/file.c we can see that close syscall calls close_fd function.
And we can see that close_fd can return -EBADF then calls filp_close from fs/open.c which tries to flush and may also return other error codes.
By the way there is the "same" issue in Rust standard library (fd.rs): close call result is ignored. And it is not an oversight: this is by design. "drop" must not fail, just like C++ destructors must not fail either. For me that is a major flaw of RAII.
In C you can try to write perfect error handling (checking results of close, CloseHandle, HeapFree...) with a bunch of gotos.
I guess in Zig deferred code is not supposed to fail (return an error code)?
@@rt1517 Just tried it. And yes, "try" is not allowed inside defer expression.
This looks like a hacked up version of rust.
Amazing
26:02 ohw, so, this is similar to "import std as std" in python right?
"const std = @import("std");"
amazing
Please make documentation easy to read
Oh no, prefix "try" :(
so if it isn't safe then it has no quality.
20:17 rust print formatting errors....
umh, but what does it mean for "language" to have it? like the fxn u're showing - aint that like compiler itself.... umh ohw wait, by language u mean the zig standard libs so to speak right?
at 5:08 what about webassembly.
I don't think anyone writes programs in straight webassembly =)
I wish to buy the book?
Does RAII serve the same purpose as errdefer? And if so, why was a new concept and/or nomenclature introduced? If not, what's the difference?
But Zig doesn't have RAII. defer is for cleanup on both success and error. And errdefer is for cleanup only on error.
RAII eats up valuable CPU cycles for things you don’t need to have babysat
@@drygordspellweaver8761 a trivial destructor will most likely not even be called. So What remains is work you want to do. Like free().
@@origamibulldoser1618 that still leads to heap fragmentation which causes even more cpu slowdown. babysitting / garbage collection is never a good idea for serious software where performance is concerned
@@drygordspellweaver8761 how does a function call affect memory layout?
25:00 isn't that a leaking file descriptor? Ok, its the main function, so it doesn't matter, but if it wouldn't be and if write would fail it would return an error and not close the file.
Yep. Andrew may not like the complexity of C++ but one of things it does right is make this particular error hard to write.
Yes, but it could be fixed by moving the close up and deferring it, like destroy at 31:15.
😁when your app is lower than c, someone will rewrite it. hahah
9:36
"accidental variable length array"
??
It's statically allocated using buffer_len.
No buffer overflow happening there at all.
Wow, I got an idea. Let's do Zig++
36:35 who, WHO said msvc 12GiB download is easier to install??????
So basicaly now we can have runtime errors at compile time 0.0
Lol, that's awesome.
What I don’t understand is if he just wanted it to be C with improvements, why did he change the syntax so drastically? It’s quite an adjustment to write
var name: type = value
Instead of
type name = value
I’m sure it has a reason, maybe to make it easier to differentiate functions and variables? But he didn’t really talk about it.
I like the language, but the name of it is a bit unfortunate. As a citizen of East European country I can't help but remember a certain greeting where the first word sounds like Zig and the second word sounds like Heil.
yes, In Morocco: Zig: means fraud and deception
That's spelled sieg, and IMHO taboos shouldn't live forever. Some appropriations are better reversed.
Sieg (victory) would be a cool connotation. It triumphs over inferior languages :D
That's my number 2 issue with the language. Number 1 was already fixed on the master branch.
On the "Why doesn't this work" slide (12m00s into the video), isn't the solution in C to use "enum { buffer_len = 100 };"? I like the Zig approach, but I think this example might need revisiting.
That's a workaround demonstrating the problem.
14:30 the need for comptime is surprising, as fibonacci(7) is a perfectly constant expression
there's difference between "const" and "comptime const"
7:19 Eventually, someone is going to download the source-code off github & start adding C++ features to Zig and it'll become a Zig++ monstrosity like C++.
Instead, he should put these extra features in the Zig++ spec, but that doesn't mean he has to implement them... Instead, if he gets ahead & the game & takes control of the software specification for Zig++ then he can at least hopefully prevent some of the insanity that found it's way into C++ while also making Zig & Zig++ 100% compatible.
people are free to do what they will
does not mean he should be the one to do it
C++ back then added so much onto C that it made a lot of sense for people to use it instead of C. I am pretty sure that if someone were to create "zig++", when there's no reason to and nobody probably ever will, it will just die silently with nobody using it. It's really rare for PL authors to resist the temptation of adding new cool features but Andrew Kelley is doing an amazing job at this. Zig might be aimed to be a better C but it doesn't need to have as low of productivity as C; it's 2020 ffs.
I'm already doing that. I called it ZigZag
C++ didn’t add any new features to C- only complexity then endless ways to work around the complexity they themselves introduced.
WTF!! Eye opener!
With composition and functional std lib like golang + http standard servers this lang will rock
0:49 Aged like milk
How so? It's still terrifying :D
I don't think so. Have you ever seen a software engineer say "fully digital voting is great, we don't need a hardcopy paper trail or an independent verification method; let's put all our eggs in one basket, the technology is guaranteed perfect and can't possibly go wrong or be manipulated invisibly."
Circumstances can demand compromises, that we can agree to begrudgingly.
9:00
Who says its "supposed to work"?
globals are static.
Define len in main.
Or do you propose a different storage for file scope and if so, why?
12:58 TFW the creator of a language you're interested casually puts "hail Satan" in the middle of his talk and you're trying to decide if it's a joke or a dog whistle.
C's biggest problems are the lack of abstraction or standard library which makes it unproductive to use and the absense of any safety.
Zig addresses safety but other languages do as well like Rust, Ada, Nim. C++ does not address safety and also lacks powerful language abstractions. It just has verbose syntax and complicated rules.
I only watched this video but I don't see a unique solution which D or Nim wouldn't have.
* compile-time constants are "enum" in D
* conditional compilation has "version", "debug" or "static if" in D.
* "comptime" is "static" or "enum" in D. But explicit compile-time code makes code harder to maintain. It typically leads to "brain methods". However, Zig's solution is admittedly simpler, particularly simpler than explicit "template" concepts.
* "comptime" arguments are template parameters (with complicated type system they can become dangerous for productivity very fast).
* stack traces are pretty standard.
* "defer" and "errdefer" is like "scope(exit)" and "scope(failure)" in D. Nim's lead programmer almost wanted to kill this feature from Nim. Fortunately not.
* switch in the catch-clause looks like "final switch" in D
* own build system.
* D features an own C compiler which doesn't support VLAs however.
Error handling problems apparently not solved: separating responsibilities. Error handling should be separated from the correct paths but cramming them in the same function makes it hard to maintain and read.
The real future would be productive safety: code synthesis (automatic code generation from specifications) and verification features like using ghost variable information at runtime and solver-aided programming abstracted via language concepts for very simple use. That's a point where D won't have success.
Another thing: Powerful iterator abstraction instead of pointers. Automatically generate optimal iteration code based on where the abstraction is used without using indices or other meaningless helper variables.
I'd like to see clever aspect-oriented features to separate code and data structures into separate parts which can be combined automatically. Uninspired pesky tasks like transforming data structures and complex values into reordered or subset data structures should be auto-generated code. Physical structure of objects could be abstracted away completely, be interchangeable and only needs to be explicit for interfacing with foreign languages / machines.
one of the biggest issues I have working with C is that its just not human readable.
Compare that with something like swift where code reads out like English sentences.
Does zig handle `#pragma pack` in C headers correctly?
Looks like that's a TODO:
github.com/ziglang/zig/blob/057a5d4898f70c6a8169c99375fbb8631e539051/src/translate_c.cpp#L4365
Just a matter of figuring out the libclang API and setting is_packed to true on the AST node.
@Andrew Kelley Hey Andrew - is it possible to remove the const and fn keywords? I’m lazy and want to type as little as humanly possible
19:22 - How is that not known at compile-time? It's a string literal, right? Is that not stored as a static value at compile-time?
its in a function that takes a noncomptine string thus it is not compile time known
Another Esperanto of programming language?
10:16
No, you don't (need a preprocessor directive).
You've allready demonstrated that though while going on about a non existant buffer overflow.
Tough crowd haha
"Perl applications are not going to do advantage of a python library...", that's a false statement!
There is a module in perl, allowing to use an inline python in perl code and use python libraries.
In addition, there are many other interesting modules in perl, like allowing inline and library C, ASM, TCL and some others.
Of course there is
1:03 "We can do better than this". Some seconds later...
I liked the idea but Syntax is not good.
The fact that it uses TypeScript's method of defining types for parameters and variables, but NOT for functions is making me irrationally angry
very like a rustified Ada，i think zig should keep borrow more from Ada like contract
3:17 given that the most used programming languages in the industry are garbage collected, even for HFT like Java/C# and for the web are still Java/C#/PHP/Python/Ruby the title of that slide is a little too wrong. Those languages are widely used, and they were designed for those specific use-cases because no one wants to invent a hammer to nail everything including screws, remember "right tool for the job"
And docker yes, I agree that was the case, at least in part, but mostly was about ensuring that also testing and the execution of the applications was reproducible because most programming languages with a few exceptions like anything that runs on the jvm, clr, beam or anything that uses memimage-based development ala smalltalk/common-lisp suck at isolation from the OS because the most popular languages like php, ruby, python, c, perl are tightly integrated into Linux.
with anything that runs on the jvm/clr/beam you can easily distribute a precompiled signed package to deploy it easily. it can be compiled easily anywhere as long as it remains in this curated environment easily because all you need is the SDK of each of them. With memimage/beam is even easier because you don't even have to restart the environments.
the problem and the culprits are the shitty php/python/perl/ruby/nodejs
Programming language popularity list is missing Rust, which is voted #1 on many lists including stackoverflow
It wouldn't help his argument.
Correction: #1 loved on stackoverflow. likability != popularity.
He said TIOBE list. Rust is only number 24 there (as of August 2021).
we'll see how long that lasts when zig compiles several orders of magnitude faster. 15 minute compile times are a hefty price to pay for the borrow checker.
@@Beefster09 if compile time was the only metric for a language go use c89.