[Off-topic] Another programming language website with no code examples front/center on the homepage?
When you click "Download & Documentation" there's a link under the headline "master" to the long-form documentation which has some examples: https://ziglang.org/documentation/master/
Interesting to see how the language has evolved away from using "%" in the original Hello world:
const std = @import("std");
pub fn main(args: [][]u8) -> %void {
// Print "Hello World!", and believe that no errors will happen
std.io.stdout.printf("Hello World!\n") %% unreachable{};
// Short version:
%%std.io.stdout.printf("Hi!\n");
}
Compared to the newer version :
const std = @import("std");
pub fn main() !void {
// If this program is run without stdout attached, exit with an error.
const stdout_file = try std.io.getStdOut();
// If this program encounters pipe failure when printing to stdout, exit
// with an error.
try stdout_file.write("Hello, world!\n");
}
Zig's new release has a ton of improvements: new targets (e.g. LLVM 8, WASM, support tiers), C pointers, Vector type, better docs, and my personal favorite: Zig now makes things as static as possible by default.
I love seeing all the progress with Zig, V, Muon, and Rust. All these languages are potentially-better systems languages than C/C++, with better safety, better definitions, and better semantics. Zig has an explicit goal to be better than C and to replace it.
Honestly, I don't see it happening. Zig and rust and jai and d all feast on c's remains, but the result can only be fragmentation. And then you lose one of the big draws of c: ubiquity. Zig has two compilers. Rust has one (serious) compiler. Jai has 1, d has either 1.5 or 3.5 (depending on how you count). And although all those languages want to replace c as the language-that-you-use-for-everything, and they might each be better than c as a language-that-you-use-for-everything, but for a given use a 'lighter' language like python is frequently even better. And it gets to the point where the only languages that allow you to program anything (lisp and perl6, really) are garbage collected and have heavy runtimes, so they won't be taking over games or the os.
I don't see any single thing replacing C (or C++) but what's interesting here is many of these languages work very well with the C ABI, not just as an FFI concept but with notions of memory and data layout. The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions). This lowers the barrier significantly.
The hard part is build tool compatibility but I think there are a lot of good ideas being worked on actively, Zig and Rust being two examples of advanced programatic control over the build process. With a reasonable linker, it should be possible to combine these and more languages today.
An interesting counter example to the binary interface compatibility story has been Go, which seems to let cgo become less and less functional in each release. The pressure to keep everything in Go is an interesting trade-off. I wonder if certain kinds of systems will be paying for this lock-in later down the line while other languages give much easier ways to gradually evolve and reuse code or adopt libraries from multiple communities removing the need to do yet-another-rewrite in language X kinds of projects. Or perhaps this kind of interoperation is overrated? Time will tell.
> The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions)
That already works, not a hypothetical. I can write, right now, a zig function, call it from rust, slap the whole thing into a library and wrap it with d. It hasn't taken the world by storm because these languages provide support the system c abi and calling convention, but do not embrace it. If I write a fancy templated function in zig, d, or rust, the name mangling, type-information, templating, maybe even call conventions -- are all different. This is why I have been and continue to be disappointed that things like COM or the jvm or cli aren't more popular, because they actually work that way. I can write, right now a clojure function, call it from java and then pass it into kotlin. Effortlessly, it's just an import away. Sure there are, for example, stdlib conflicts in scala but overall it's a much more frictionless experience. The problem? COM is windows-specific, jvm and cli are managed runtimes and people don't like managed runtimes.
Another place I look for a solution is racket, but again it wants to manage too much of the runtime to be practical. What zig is doing with the build system is great, the fact that the build script is actually a fully customizable script means it has a much better chance of taking off, but until I can import a jai module from d and call it in zig, we're gonna have problems.
EDIT: something which possibly almost could have had a good chance of pulling this off is llvm. Except that llvm comes too late in the compilation process to be used to resolve imports and symbols. Something like libclang, maybe, except not specific to c and c++.
Wouldn't a managed runtime mean it isn't suited for systems programming? The benefit of something like Rust is it provides a lot of the benefits of a managed language while producing native code and "zero-cost abstractions". A runtime adds a lot of overhead etc.
C also has a runtime, that is what takes care of calling main(), handling VLAs, floating point emulation, constructor/destructors (GCC C extensions), ...
Besides there are plenty of OSes written in type safe system languages to learn from, including surviving mainframe OSes.
The operative word here is managed runtime. Jvm wants to completely own your program, heart and soul. You can also write freestanding code in c (and rust, d, zig I assume although I don't know enough about it). I believe there is a dialect of c# that allows you to write freestanding code, but it's not really c# so much as c#-flavoured c with some extra features, so it's inferior to other c alternatives.
I feel much of the negativity that you like to express towards C is unwarranted. Fact is, it's both very easy and efficient to interface with "C" or more specifically, platforms' standard ABIs.
That Quora post is really only relevant when using Java applets. If you're running a local program, you're faced with similar vulnerabilities as with any other language with a managed runtime. Still doesn't make it relevant as a competitor to C or C++.
It has a sane subset which is basically C with a slightly saner syntax than C (the begin...end and lacking data initialization syntax are terrible though!), and with a proper module system and much better compile times.
On the other hand, it was crippled by missing a usable preprocessor and an ecosystem that has bought into each hype since the 90's, resulting in 23 incompatible kinds of strings, 101 different dynamic arrays, and about 5 (really) incompatible object models with different kinds of memory management. Programmers with many years in the language don't really understand all the ways memory is managed in this language.
Now try writing something on top of the broken RTTI for that. Even official guides basically concede the fact by writing quirky code that easily breaks.
Also you have to declare typealiases for every little thing like pointer-to-types, before you can use that type in a function signature. This alone renders it almost completely unusable for my purposes.
It has a culture of goto-considered-harmful where people like to indent 13 times instead of using return/continue/break, which would yield readable control flow. If you want to return something, you need to write two lines - assigning to the result and calling exit(). You can't call exit() though when the current class has a method called exit(), since that method is closer in scope (REALLY REALLY WEIRD).
I know what I'm talking about. I've been paid to work in it, and refactored a subsystem written in idiomatic Delphi to be halfway maintainable, achieving real speedups of 100-1000x by following a straightforward "data-oriented" approach, just like I would write it in C, writing complicated code only where the straightforward approach was not feasible in the language. Despite completing the project successfully (there hasn't been a single problem since the rewrite), in the end I was burnt out due to having to work with the original code. Didn't work for 5 months afterwards.
Except for when I write Assembly, the last time I used raw goto on an high level language, my MS-DOS 5.0 box was still relatively new.
System.exit was always a thing to avoid namespace clashes and since Delphi 2009, you could have used System.exit(value) instead. Next time better read the docs.
Regarding strings, you mean like 8 bit, 16 bit, wchar_t, DBCS, GString and many others used across C libraries?
Nominal typing is much safer for large scale engineering than type aliases, which don't provide a mechanism to prevent incorrect usage of types.
Do you suggest I should use System.exit everywhere (even though all the code you find on the net uses just "exit")? Just to be sure that Delphi will never ever choose the wrong function to call WHICH IT SHOULD NEVER HAVE DONE IN THE FIRST PLACE OMG IT'S TOO FRIGGING COMPLICATED PLEASE DELPHI APPLY SOME COMMON SENSE.
It's beyond me why I should write a function call and incur symbol resolution for such basic control flow in the first place.
> the last time I used raw goto
I was mainly speaking about return, break, continue, which don't seem to be popular in Delphi. Examples of Delphi code that isn't a messy nesting fest? As for goto, there are perfectly valid uses for it, in fact some where goto is the clearest and most maintainable choice when you simply skip downwards over a chunk of code without requiring an extra flag.
> Regarding strings
I'm talking about the culture. The culture around C is not one that makes anti-modular "abstractions" (at least if you stay away from MS). You will never see me using wchar_t, GString or any of that god-awful Microsoft string mess. I get along just fine with only char. In fact, the string handling I get by using C is the most painless, most modular I've ever gotten in any language. (No, I don't want to use split() or use any other high-level stuff that would do allocations when that isn't necessary).
In Delphi, different story. Everything you find in this culture is built around String and AnsiString and UnicodeString and WideString and what not. Try googling how to access command-line parameters. The stuff is pervasive. Entirely different story.
> Nominal typing is much safer for large scale engineering than type aliases, which don't provide a mechanism to prevent incorrect usage of types.
Exactly, typealiases are bad. And now explain to me why Delphi forces me to make a type alias (for use in function signatures) when that is worse than immediate Pointer syntax in every conceivable aspect? (Having written a compiler I know the answer: because it requires less code in the compiler to check for type equality).
So I guess I should just avoid pointers altogether and use only GC'ed boxed OOP NOMINAL types. And finally have some time for coffee again while my application takes 5-10 minutes to start up (as it did before I reworked the thing), instead of 1 sec.
COM is not windows specific any more! Or rather there is a portable COM-like thing which looks like a good fit for cross language development
https://github.com/Microsoft/xlang
On Windows we just use COM/UWP or .NET libraries most of the time, no need to be stuck with C ABI.
Same applies on Android, where using a Java based library, even if stuck on their Java 6 - 8 world is much more desireable than having to deal with NDK and JNI boilerplate.
Likewise IBM and Unisys mainframes make use of their language environments instead of C based ABIs.
Assuming with COM/UWP you mean "UWP's flavor of COM" instead of "COM and/or UWP", is anyone actually using that outside of mobile trash and game engine backends for XB1?
All the Windows software i use and see people make are either Win32 or (much more often) built on top of Win32 (well, UWP is technically also built on top of Win32, but you are supposed to ignore that and act as if it isn't the case).
Yes they are, UWP is the future of Windows APIs since Windows 8, like it or not.
Win32 is slowly being migrated into sandbox model with each Windows 10 release and hasn't seen any big update since Vista. All major APIs introduced since then are based on COM.
I believe Windows will sooner become completely irrelevant than UWP becoming the dominant API to write Windows applications. Also seeing how MS is switching the system browser to Chromium, and kills the UWP version of MS Office, it looks like most people in Microsoft have lost faith in UWP too.
Microsoft didn't kill the UWP version, they merged it. Office is only becoming increasingly a hybrid. An increasing number of the controls are becoming UWP XAML-based.
It doesn't look like Microsoft has lost faith in UWP, only that they gained faith in UWP/Win32 hybrids (and all the complicated engineering work to make that happen), and Office seems to have helped lead the way there. For instance, Office is way more sandboxed than it has ever been before. (Office's own App-V work as far back as Office 2010 helped prototype the sandboxing approach Microsoft is applying to all of Win32 with the now focused opt-in MSIX installer.)
It's probably still too early to tell exactly how much UWP Microsoft will add to their Chromium mix, but there's already some bits there. For instance, the Chromium-based Edge still supports Netflix because they already integrated a UWP Island to (UWP API) Windows Media Foundation to support hardware-accelerated PlayReady DRM.
Based on previous history, chances are Microsoft will first abandon UWP (but leave its zombified corpse in Windows for backwards compatibility) and introducing something new-but-incompatible-with-anything-existing before Windows become irrelevant. Actually, they might do this 2-3 times before that.
> Yes they are, UWP is the future of Windows APIs since Windows 8, like it or not.
Well, i don't, but my two main gripes is that it seems to be an evolution of WPF which i never liked and that it is tied to a more locked down mobile-like approach that i abhor.
> Win32 is slowly being migrated into sandbox model with each Windows 10 release
What are you talking about?
> and hasn't seen any big update since Vista.
I'd say that it hasn't seen any big update since Windows 98 :-P but as long as it works i do not care.
> All major APIs introduced since then are based on COM.
That is for store stuff though, not Win32 itself and the vast majority of applications are not written for the store nor distributed through it (some do use it as a secondary means of distribution but from what i've heard the limitations are not worth it and the store itself is bad from a UX perspective).
Maybe I'm a bit of a rust fanboy and a bit of a skeptic but
Zig and Jai aren't going anywhere. Zig appears to be a largely single contibutor (https://github.com/ziglang/zig/graphs/contributors the creator has < 2/3 of commits).
Jai does not have a public compiler and is not likely to get a public release anytime soon.
As for rust we don't know yet how big of a chunk of marketshare it will take from new c and c++ code.
Not many people still use c code for "everything", most have already switched.
What is the actual argument that you support with pointing out that Zig is "largely single contributor"? Linux was largely a single contributor up to a point.
There is nothing wrong with single contributor languages. But for every C there are thousands of flatlined github repositories of single contributor languages. Building a language is a marathon, not a sprint. It takes years and years to grow something worthwhile, and this requires a lot of persistence. In the meantime, technical challenges, finances, family, and even busses get in the way of languages being fully realized. Having a team rather than a BDFL increase the chances of a language flourishing and persisting.
Aside from starting Zig as his personal project, Zig is also Andrew's job now. As far as I'm aware that is not true of any other contributor, so it makes sense he'd have the lion's share of contributions.
I feel like C hasn't been a "language-that-you-use-for-everything" for some time, so it's more about replacing C in the situations where C is currently a reasonable choice for new development.
Naïve thought of the day: What if instead of replacing c with another c-like language, there was a c library that you included in your code that overloaded operators and functions into safer ones? You would gain some of the benefits and retain the ubiquity.
That's not particularly charitable. The accidental AMA that happened on HN a few weeks back gave me the impression that V lang isn't as polished as a concept as some of the other offerings out there. BUT the author seemed tp have something brewing. And regardless we'll have some more evidence in the coming months.
Regardless, V lang is another data point that something besides C is a possibility with the modern tools that we have available to us. Whether or not it pans out is almost immaterial. Just the fact that so many people are finding some sort of success or making some sort of progress in this space is enough for me to continue to watch for any new progress in the C competitors.
Yes, V is at a very early stage. I merely created an "about" page, then it got posted, got lots of attention, so I created a website and recently released a playground:
I'm sorry, I was mistaken. That was incredibly rude of me.
I mistakenly assumed based on the title of the original post "About V, the language Volt is written in" that the post was about V, but as you pointed out, based on the parent comment it was actually about Volt.
I think I'm just excited to see your source code for V :-)
Release the code of your doom3 to v translation, release the code of your sqlite translation.
You can't because they don't exist. And don't say "release coming in 3 days" or some other BS like you normally do. It seems like a way to divert attention until people forget to check again.
It won't work. I can see 300 dollars a month on your patreon, which is probably why you exaggerate so much.
Release dates have been consistently been pushed back for basically the last year. For months your program's website looked like it supported a lot of programs it didn't. Be clear and upfront about what you can do and people will trust you more.
Right now, the only way to actually see the language in action is to tune in to Jonathan's livestreams on Twitch. He is writing his next game entirely in Jai. He also streams compiler development every now and then (last night was a compiler stream).
> All these languages are potentially-better systems languages than C/C++
No they are not. C++ has spent decades building "a better C/C++". Any language that ignores those lessons and takes the stance of "learning C++ is too hard, let's go shopping" is doomed to fail.
<rant>
For all the time and work poured into C++, it has remarkably little to show over plain old C99.
Some of those new "better C" languages are the work of individuals and very small teams, yet they are able to build more progressive "better C" languages than C++ can ever be because it is held back by the need for backward compatibility for 'failed features' and 'design-by-committee'.
If all that ever comes out of those small 'better C' languages is some sort of consensus of which core-set of features actually makes a 'better C', than they have already contributed more to programming language development than C++.
</rant>
> For all the time and work poured into C++, it has remarkably little to show over plain old C99.
Exactly. I think of it as a path-finding problem. C was obviously not where people wanted to be. As with any path-finding problem, it's possible to make a wrong turn. Often, attempts to recover without backtracking only make things worse. I contend that C++ has done exactly this. They're at point where a mature, reasonable person would admit their error and backtrack until a better path can be found.
I doubt that many of C++'s critics are arguing from ignorance or afraid of complexity. More often, they're objecting to spurious complexity because they know how to do better. I've written compilers, and they're not even close to being the most complex things I've written. It's not so much "let's go shopping" as "let's return this defective merchandise" and build something that works. It's only the lemmings who insist on rushing further down the wrong path. "Turning around is hard; maybe if I get enough others to come with me they'll break my fall."
Without starting a rant myself about people that think C++ has nothing to offer over C, what is in your opinions then the reason for any large company to develop their code in C++ and not C? I'm thinking of virtually all Adobe Products, anything related to the creative industry really, Google, CERN, Microsoft... No-one in their right mind would try to develop Adobe Photoshop in C.
- RAII: Only useful with 'smart' data which must run code for initialization, destruction or copying. It's entirely valid to work with 'dumb' data only which is zero-initialized, and can be copied and deleted without any additional custom actions.
- Exceptions: too brittle and complex, modern languages have switched mostly to option-return values, which contain both an error code and success-result.
- Classes, objects, inheritance: left-over artefacts from the OOP hype of the 90's
- Templates: Not the only option to write generic code, other languages do this better. Programming entirely without generics isn't too bad either, not all code benefits from this.
- STL: not sure what to say here, it's the main contributor to slow compile times, excessive hidden memory allocation, slow debug performance and bloated executables. There are not many parts of the STL that are 'acceptable', but of course that's entirely subjective.
Well you learn to appreciate the value of RAII and exception working on high-availability software. It's almost impossible to have correct error paths and deinitialization without. I'm very doubtful the new crop of languages without exceptions and RAII actually care about correctness in the wild.
Better than template without uniform representation? template is just copy-paste you don't _have_ to use it. Same remark for STL. You want a hashmap of arrays of string, you can have it in C++ in one line. In C you would end up with a linked list instead of picking the right data structure.
Objects and inheritance are not a hype. See this page, which uses CSS, which implements inheritance. Having subtyping is a basic premise of being a useful language (or, a GUI language).
I've been writing C++ code since around '98, and have only recently moved back to mostly C. To be honest, features in C++ that I thought are a "must have" are actually a variant of Stockholm Syndrome, after a little while (a few weeks to months) one realizes that the world would keep turning without C++ ;)
> Well you learn to appreciate the value of RAII and exception working on high-availability software.
Alternatively, you'll learn to not appreciate the value of exceptions working on high-availability software. Not personal experience, but AFAIK Google (definitely lots of highly-available software) disallows using exceptions in C++.
> Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions[....] Things would probably be different if we had to do it all over again from scratch. - https://google.github.io/styleguide/cppguide.html#Exceptions
"Left-over artifacts from the OOP hype of the 90's".
Sorry, but anyone that bashes on OOP can't be taken seriously. There's no problem with OOP, it can be misused of course, but the same is true of any other paradigm. Every programmer with any worth uses OOP, Functional, Data-Oriented, etc, where they are most effective. They are complements to one another not replacements.
Which of these languages do you think hasn’t learned the lessons of C++? Rust, for instance, has liberally encoded “modern C++” whilst plan not providing a lot of the features that make C++ problematic.
"Zig is aggressively pursuing its goal of overthrowing C as the de facto language for system programming."
If there's one truth I've learned in my decades of dealing with computers, it's that you can't beat C at being C.
Before now, I'd never heard of Zig in particular, but I can think of several other languages that have tried or are currently trying. A lot of people seem to think they can make something a little better than C, in some ways, and that will be enough. I doubt that even C18 itself, if it were invented from scratch today, would be able to unseat another systems programming language.
Everybody forgot about Worse-is-Better: "Unix and C are the ultimate computer viruses". Any language which isn't more 'viral' than C (in terms of being ported, and attracting users) has no chance. You're starting tiny, and growing less quickly.
> If there's one truth I've learned in my decades of dealing with computers, it's that you can't beat C at being C.
Have you ever seen a language that has made a serious attempt?
The last few years, the only significant one I know of is Rust. But it's not really a C replacement. C is essentially fancy assembly. Rust is conceptually quite advanced.
Zig is one of very few languages I've seen that makes a serious attempt at being a better C. No garbage collection, no fancy borrowing checker, but quite a few improvements/features that actually matter to low-level/embedded programming.
My use-case is microcontrollers, and I've tried a few different new languages for fun. Zig is the first one where I actually came out of it wanting to use it for real. The only problem is it's still not finished.
A couple of things have changed though. LLVM exists, we are being flooded by parser frameworks that make that whole business much more pleasant than the lex/yacc days, the llvm and Regehr blogs both spelled out some info on undefined behavior that previously people either didn't understand or refused to believe, the size of software engineering has grown to include many different niches, computer architectures have by and large grown more homogeneous (and where they're different you aren't going to be exploiting their power with lowest common denominator C), memory hierarchies aren't flat and it's becoming the determining factor in program speed, etc.
It's not obvious what needs to come next, which is the only reason that C is still here. Most likely several languages are needed to fully replace it. And our industry is starting to feel that out now.
D, Go, Rust, Jai, Zig, P, C# low level primitives. Things are changing. Even C++ seems to want to be a different language with some of it's latest developments.
Have you got an example of a C replacement that was actually better than C, got as far as Zig and is now abandoned? I can't think of one. I've been look for a better C for 15 years and Zig is the best candidate I've found. I don't think DasbetterC counts, since it is a side effort to the greater goals of D.
Interesting choices. They're all very old. I feel we must have learned something since the 1970s that could be used to improve a systems programming language.
I don't really want to restart a flame war that was extinguished decades ago but Kernighan's critique of Pascal (http://www.lysator.liu.se/c/bwk-on-pascal.html) is an interesting read today - if only because it reminds me how much simpler things were back then - no mention of memory safety or multi-threading.
I have no knowledge of Object Pascal and Modula-2, so won't comment.
Kernighan's critique was very biased and he focused on plain ISO Pascal on purpose to get his point across.
Cleverly not mentioning that many issues were fixed on ISO Extended Pascal and other dialects.
Also that back then outside Bell Labs, most C compilers were actually dialects of the real thing, like Small C and RatC. So it was not like C wasn't without its portability issues outside UNIX.
As for memory safety and multi-threading, check Concurrent Pascal and Solo OS from Per Brinch Hansen.
> Cleverly not mentioning that many issues were fixed on ISO Extended Pascal and other dialects.
Yes, Kernighan was “clever” in 1981 to ignore ISO Extended Pascal, a standard published in 1991. (I'm also not sure if there was ever more than one implementation of Extended Pascal, though Free Pascal claims it as a planned future feature.)
> "Zig is aggressively pursuing its goal of overthrowing C as the de facto language for system programming."
I think it's fine to have aspirational but unrealistic goals.
> If there's one truth I've learned in my decades of dealing with computers, it's that you can't beat C at being C.
You can't, but as the realm of computing expands, it makes space for new languages. There's a lot of room in the space adjacent to C. We have embeddable languages -- schemes, lua, even Python to some extent. We have languages like Zig, Rust, and D, that can compile to object files that look as if they came from C. And we have other languages that generate C, like lisps and ocaml have done for 20 years now.
C doesn't have to be a language anybody writes, to be a language that everybody uses.
I've played with it for a few hours now and it feels promising. But also very hard to get into. There is not a lot of documentation nor code examples to look at. I'm trying to write the equivalent of int main(...) { for (int i = 0; i < argc; i++) { for (int j = 0; j < strlen(argv[i]); j++) { printf("%d %d %c\n", i, j, argv[i][j]); } } } in Zig, but figuring out how to do formatted output in the language wasn't so easy.
Another small annoyance was Zig rejecting \r in line endings. Thankfully, I'm using Emacs so it only took me 15 minutes to google the right fix. But it felt a little "gratuitous" if you know what I mean.
The code itself should be up to date for most, but I'm aware of a few examples than need touch-ups. Unfortunately there is a bit more boilerplate compared to other languages for some simple tasks, since Zig requires you to be quite explicit about things (e.g. i/o, memory allocation).
Regarding the rejection of '\r', there is the intention for `zig fmt` to handle these minor issues and reformat code as needed which hopefully reduces this barrier. There was a long issue regarding hard tabs with discussion here: https://github.com/ziglang/zig/issues/544
The Zig language has a great premise, it's worth reading the above link or watching a bit of this video https://youtu.be/Z4oYSByyRak?t=150 just to question our assumptions that certain language features need exist at all.
It's been a real pleasure seeing Zig grow, hopefully it can fill that niche for a high performance, portable, modern language that isn't filled with OOP cruft
Edit: Just confused myself, comments are // and multiline literals are \\. Thanks to laszlokorte for catching my mistake!
Zig claims very proudly it is about clarity but shortly into reading through the documentation I already found this extremely surprising:
"Multiline string literals have no escapes and can span across multiple lines. To start a multiline string literal, use the \\ token. Just like a comment, the string literal goes until the end of the line."
I could not have tried to make a more confusing token for multiline string literals if I tried. The difference between a string literal and comments is literally whether or not the lines are preceded by an open =.
Note that Zig has line-independent tokenization. As a text editor of Zig code, you can have correct tokenization by scanning to the previous \n and starting from there.
> Python has an even closer relationship between comments and string literals: its multiline comments are just string literals that get never used.
That's not entirely true. A literal string immediately following a class or function is inspectable via its __doc__ member.
E.g.
class Foo:
"I am Foo."
def bar(self):
"I am Foo.bar"
Foo.__doc__ will have "I am Foo.", and Foo.bar.__doc__ will have "I am Foo.bar".
This is rarely used programattically, but at least one standard module uses this for running tests: doctest
Edit: not sure why it's not formatting correctly, as I am spacing the code a 4 space indent, but at least on my phone, it is not properly formatting as code. I apologize.
These are used by python's documentation tools to extract documentation from running objects by importing and examining __doc__ of objects, instead of extracting docs from comments like Java or c++ doxygen. It also makes it easier to document python modules written in c since you just attach their docstrings and examine them at runtime same as any python module
Either pythons stdlib crappy pydoc module
`python -m pydoc -w ModuleName`
the simple pdoc tool
`/path/to/pdoc --html ModuleName`
or the complicated and fully featured sphinx (too complicated for a single command
`sphinx-apidoc ModuleName` to generate a default project
and `make`/`make.bat` to run it
)
They are also useful print help in repl (with `help(obj)` or `obj?` in IPython)
Also in python comments are everything after a hash # till end of line.
Non assigned Literal strings in python are just literal objects not comments.
If they are the first thing in a class/function they become the class/function/method __doc__ attribute.
If they aren't they have no use but are simply created and then garbage collected because there are no references pointing to them(cpython the default python implementation uses reference counting and the occasional cleanup of unreachable cycles so it would be deleted right after creation). Its the same with literal numbers or dictionaries.
def a():
5
[]
"whoop de do"
is a legal (and totally pointless) python function that will do nothing(other then allocate then cleanup some objects).
It's on one hand a bit annoying that each line is prefixed, because you can't paste like you can in Python, but on the other hand, the prefix allows it to be indented in a not-ugly way.
Why this algo in particular? Is this a security feature? I suppose wrt "Reflections On Trusting Trust" it may be. But if it didn't need to be secure it could probably be a lot faster (assuming this is a critical path for cache hits).
I didn't put a lot of consideration into the algorithm in particular. I was going to do SHA-256 but somebody told me Blake was faster.
I haven't tested the performance of any other algorithms, but that's a completely swappable component. I'm sure the hash function will be swapped with a different one before 1.0.0 is done.
As an example, xxHash [1] would probably get you an easy 5-10x performance improvement over Blake2b. So there are some easy improvements if the cryptographic requirement is not needed.
I have one criticism: although zig has advertised very early on an amazing array of targets (probably taken from clang/llvm itself), some of the most esoteric ones have never worked for me, like powerpc (32bit) and MIPS. The blame is not entirely in zig but also in LLVM.
It would be more fair to not even mention them as supported _at all_, or at the very least to document them as Tier 4.
I made that mistake before and I apologize for that. For this release cycle, I went through and tested creating a simple object file for all the targets, when categorizing them into tiers. So I think that if you try powerpc (32bit) and MIPS again you will find that they work now (probably because of LLVM improvements). If that is not the case, that is a bug and I would like to know about it.
I'll file some bug report. Because I've tried to build a plain hello_world.c for ppc (without using stdio even) and encountered issues with libunwind (had to fix the assembler syntax which apparently does not work anymore with modern llvm) and both musl and gnu libc were both complaining and could not be build.
Andy, if you have the time I think it would be interesting to read a retrospective from time to time. If you were to start over with the knowledge you have gained, what would you do differently? What would you rather have postponed? What would you have started earlier?
I'm surprised nobody is pointing out the similarities with Nim in terms of features: multiple targets (binary, js...), C interoperability, easy cross-compilation, metaprogramming, targeting many architectures, artifact caching.
Its goal is similar to that of Rust. I'm sure it has more goals than only replacing C. Effectively it can become yet another systems programming language, but potentially one of the best, and thus replace C (or work alongside C in existing programs).
I haven't played with Zig but it looks a lot more appealing than e.g. Rust to me.
In the end though, I'll prefer plain old C (C99 or C11).
* seemingly pointless "const" (can you define a mutable import?)
* unnecessary verbosity defining an identifier for the import when there's almost never a need for naming it differently (i.e. it should default to "const std" if you just type "import 'std'"...
I like Go because it avoids pointless verbosity most of the time.
but then you've just imported all of std into your own namespace. (probably not using the correct terminology here).
At any rate the const indicates you're not changing, and the std is the name given to the root of the hierarchy for importing "std" into.
Sure go lets you do this too, but has shorthand.
import "fmt"
can also be done as
import fmt "fmt"
but why would you do that?
The go equivalent of zig's "use" is
import . "fmt"
"." means "the current working directory" on unix so it's familiar to folks in that sense perhaps. Principle of least surprise is nice when the syntax is terse.
Still, I think I like zig. I feel like I want to try to write something non-trivial with it when I look at the features.
I've already done that a few times with Go, and I enjoy that too.
First time I saw a presentation on Zig by its creator it left a bad taste in my mouth: I looked like a "simplified Rust", with a lot of suspiciously similar names on the standard libraries and default types, yet there were zero references to Rust in any part of the presentation. In fact, it seemed like there was an active effort to avoid mentioning Rust, even though a lot of the things addressed by the language are/were some pain-points in Rust.
It's noticeable that there are a lot of differences, and some things seem to have been deliberately made different (even if they are in essence very similar and only syntactically different), so for me it looks a bit odd that most references to Rust on his blog nowadays are of adversarial nature (ie, "look how better we are than Rust").
Last, but not least, it also doesn't help with the big picture that the one continuously posting links about Zig here is just self-promoting their own creation...
When you click "Download & Documentation" there's a link under the headline "master" to the long-form documentation which has some examples: https://ziglang.org/documentation/master/
Edit: also found a blog post with a nice introduction: https://andrewkelley.me/post/intro-to-zig.html and an examples directory: https://github.com/ziglang/zig/tree/master/example
Interesting to see how the language has evolved away from using "%" in the original Hello world:
Compared to the newer version :