14 ms·
Why Zig When There Is Already C++, D, and Rust?
- AndyKelley 3y agoI don't know why this article keeps showing up on HN every other year but since it's up, I took the time to read it and fix all the outdated facts. Notably, when it was written before there was not a package manager available. Now there is, so I rewrote that section. It should finish deploying in a couple minutes.
- david2ndaccount 3y agoSince you’re updating it anyway, the very first example says "D has @property functions, which are methods that you call with what looks like field access, so in the above example, c.d might call a function.” It is true that `c.d` might call a function, but it’s not because of @property functions (which exist but are discouraged), it’s because the parens are optional to call a function/method if there are no arguments.
- k__ 3y agoPhilosophically speaking, is it really hidden control flow if a function call just happens to look like a attribute access?
- dymk 3y agoI've only seen flow control used in the context of conditional branching, so if the function contains no branches, I don't see why it would. Hidden overhead or indirection, sure, but not necessarily flow control, for the same reason e.g. indirect pointer access isn't.
- PH95VuimJjqBqy 3y agofunction calls are, themselves, branches. underneath there is literally assembly to take current state, push it to the stack, then jump into another location in memory and start executing. And then when done, do the reverse. jump back to another memory location and pop everything back off the aforementioned stack and into registers.
- dymk 3y agoYes, but that's not a conditional branch, and that's the distinction I've always seen made for flow control versus indirection
- PH95VuimJjqBqy 3y agotry/catch/finally is also considered control flow and it's not conditional, although, unfortunately I've seen people use it as a control flow mechanism. interrupts are also control flow but, again, there are no conditionals there. control flow is about the order of execution, one common way to get there is using conditionals, but it's not the only way. Having said that, even if you disagree with Andrew's wording, the overarching idea remains. You always know explicitly if the flow changes.
- Akronymus 3y agotry/catch seems very conditional to me. If there is an error condition, jump to the error handling code. Or am I missing something?
- PH95VuimJjqBqy 3y agoI could also describe a JMP instruction as "if you got here, jump to there", but just because I can doesn't necessarily mean I should.
- epcoa 3y agoBut Try, catch and throw are in themselves not conditional, they are fancy gotos with bookkeeping. Those constructs don’t typically deal with conditions. However I think the notion that “flow control” has to do only with conditionals is not a common one. FWIW the definition on Wikipedia, which aligns with my experience is not this restrictive… the lowly goto is flow control. Basically anything that controls the program location is flow control.
- Akronymus 3y ago
- zdimension 3y agoWhen reading code in a low level setting you may want to know whether one line calls a function or simply reads a field from memory. Not that it would matter that much, but it's a valid point for some. Reading a field is usually expected to not induce any control flow
- gpderetta 3y ago> When reading code in a low level setting you may want to know whether one line calls a function or simply reads a field from memory. Unless you ditch optimizations completely, it is hard to know without looking at the generated asm. Of course you can make educated guesses.
- WalterBright 3y agoThe idea in D is to make the following unnecessary: struct S { int m_field; int field() { return m_field; } void field(int c) { m_field = x; } } just to future proof the field access. Don't bother with the access functions until they are actually needed.
- zozbot234 3y agoThe actual feature that languages should implement is lenses, prisms and optics which are like properties except made properly composable and enabling high-level optimizations, for a similar efficiency to "bare" field access.
- xigoi 3y agoI’ve never heard of those. Do you have a link explaining them?
- deepsun 3y agoI found a use for the overriding field access once, when there was a large data structure bit-packed into a byte array. I didn't really need to convert it to a different data structure, but to just extract some values, and pack it back to the byte array. So I overrode the field access that operated directly on the byte array. PS: It was in Kotlin, using @get/@set, but it doesn't matter for the philosophy.
- throwawaymaths 3y agoYes. That can affect performance and also cause spooky action at a distance. Suppose someone less careful put some code in the accessor function mutates global state. Do you want to be checking all of your objects all the time to see if they are doing something counterintuitive?
- Semaphor 3y agoInteresting that this is seen as a negative, C# has getters/setters that look like property access, but I don’t think I ever heard anyone complain about this.
- shp0ngle 3y agozig and c# each scratch a different itch.
- Semaphor 3y agoYeah, of course. But the issue would still be the same in this case.
- steveklabnik 3y agoWhile the issue is the same, context can make things different. In Ruby, I love proxy objects returned from accessors. In Rust, I wouldn't even support adding accessors to the language. Different goals and objectives.
- int_19h 3y agoC# inherited it from Delphi, so there's plenty of experience showing that this is not an issue in practice. Thing is, if you don't have accessor methods (or some equivalent syntactic sugar as in D) in a OO language, you end up with them anyway, just ad hoc like Java's get/set methods. And then you still have to think about which methods that look like they're pure queries might actually mutate shared state. If anything, I would argue that explicit accessors make it clearer because in e.g. C# you can't write a method that looks like a getter (but mutates state) by accidentally naming it as such. If someone made something a property, that's because they thought its semantics are property-like, which includes not mutating global state. Sure, people will still get that wrong occasionally, just as they run mutating "get" methods, but it is surprisingly rare.
- StreetChief 3y ago"If a tree falls in the woods and no one is around to hear it, does it still make a sound?" Attribute access is reading a value, invoking a function is different (as mentioned, using a stack, etc.), although it is certainly possible a function only reads and returns a value. All that to say my answer is yes, providing flow control mechanisms makes it flow control... and falling trees make a sound!
- brabel 3y agoProbably because it's a sort of call to arms to those languages to try and improve things where Zig is currently on top :D. Some of those can't be fixed (e.g. hidden control flow, hidden allocations) but some can (e.g. I think D has an alternative allocator API, it can now compile C/C++ code as well, and I believe its package manager is trying to add support for system dependencies as well).
- WalterBright 3y agoD has a pluggable GC, if that's what you mean. It makes trying out various GC strategies easy without modifying the compiler. D also supports the following memory allocation strategies: 1. RAII 2. stack allocation 3. malloc/free 4. custom alloctors Each has its tradeoffs, you can pick the most appropriate one. The D compiler itself uses all of them :-/
- tarruda 3y agoHi Andrew. I once saw a video (at least I think it was a video) where you suggested the possibility of Zig reaching language stability in 2025. Is that still accurate?
- reactordev 3y agoThe Bun team I guess doesn't care and went ahead with 1.0 launch a few months ago. If they are willing to bet it all on zig, I'm sure it will be around for a while. It's quite mature as it stands now. Personally, I think the road to zig 1.0 should be made methodically and without any timeline.
- charlotte-fyi 3y agoI don't know that this is an endorsement of zig rather than an indictment of bun.
- reactordev 3y agoTotal endorsement - thanks for forcing clarification.
- fl0ki 3y agoI don't recommend choosing technologies this way. Elm is one of many recent, prominent examples of how years of promising language work can still leave production users stranded, both with backwards-incompatible changes that are deal-breakers for many projects, and then stalling further updates anyway even for the users still able to use the latest version. I'm not saying Zig will go the same way, I hope it succeeds. But success in industry funding is not a guarantee, successful transition to large team contributions is not a guarantee, and even if all of that does pan out, by then the language may be markedly different. Look at Rust in 2012 vs its 1.0 in 2015 and ask yourself if you'd want you and your team to have to make so many changes to production code. Ask yourself how many unknown costs you are willing to risk in exchange for whatever you believe is the actual upside of using Zig for a particular project. Sure, somebody has to break that cycle by making those bets, but be sure before deciding to be among them. Somebody else making that bet only changes the odds so much.
- dandigangi 3y agoCool to see the Bun team used Zig.
- RationPhantoms 3y agoI think most recently, I saw Mitchell Hashimoto endorse it on Twitter.
- hiccuphippo 3y agoHe's building a terminal emulator with zig: https://mitchellh.com/ghostty https://mitchellh.com/ghostty
- lioeters 3y agoBy chance, after I read your comment I found a talk he gave about his project Ghostty. Ghostty - A new terminal emulator written in Zig - https://zig.show/episodes/32/ https://zig.show/episodes/32/
- ruffrey 3y agoGreat, concise summary. Note: the original article title could perhaps be updated to include Golang as it is mentioned a few times.
- u8 3y agoWhat about the Go try/catch claim? There is no try/catch in Go. Returning errors and values is closer to Rust and Zig than D and C++.
- TwentyPosts 3y agoGo has panics. You can unwind them, and recover from them. Using these for control flow is heavily discouraged and therefore it's rarely ever an issue, but they are a type of exception handling, or at least very close to that.
- cesarb 3y agoRust has panics too, which also unwind, and you can also recover from them; they are also a type of exception handling. Unless the project was compiled with panic=abort, in which case they don't unwind at all and you can't recover from them; the existence of the panic=abort option means one cannot reliably use them for control flow, which makes it harder to abuse. But even then, you still have to make sure your code is "panic safe" when writing library code (usually through clever use of RAII guards, instead of expecting the code flow to always reach the end of a function).
- AndyKelley 3y agoAlso worth noting is that while they are discouraged, the very same Go devs who discouraged this pattern chose to use it in the standard library for basic things.
- StreetChief 3y agoNew people will constantly be finding zig, and they will constantly be wondering why they should pick up zig, they will find that reference, and share it to educate others! You can see this happening with the duplicate stories that show up on Hacker News; in general, it's a good thing: “There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup
- daxfohl 3y agoDoes the requirement to pass around an allocator end up causing a "what color is your function" problem?
- seabrookmx 3y agoNo if anything it solves that. It's inversion of control.. the caller chooses the bahavior not the callee. Using async/await as an example, you have to have an async implementation (red) of a function and a non-async implementation (blue). In this case, the callee chooses the behavior. If instead you had a function that took some sort of runtime as a parameter that it could use to run downstream code synchronously or asynchronously, then you'd have something comparable to Zig's allocator. The red and blue functions would instead be one function where you pass a different runtime.
- bvrmn 3y agoAdding additional function argument is quite a stretch to be called as color change. For application code you could use global allocator though.
- deleted 3y ago[deleted]
- defen 3y agoFrom a syntactic perspective, no, because there is an Allocator vtable interface in the stdlib. Anything that implements alloc, resize, and free can be used interchangeably in any function that takes a `std.mem.Allocator` argument. You don't need to type different things on your keyboard in order to handle different allocators within a function. From a code organization perspective, slightly, only in the sense that must ensure that you free memory using the same allocator that allocated it.
- spenczar5 3y agoThis page seems only halfway there. These are not quite terminal arguments. No hidden allocations, standard lib is optional, simplicity - all cool! But the question is, when are those the right tradeoffs? For example, I could see these being attractive in embedded work. I could see the simplicity becoming a headache in other contexts, like making abstracted all-purpose numerical libraries a la Eigen. Maybe I am wrong about those particulars! But I would like the arguments completed: Zig has X distinctive features, which you should prefer if you do Y. This is relevant to my interests right now: I am working on scaling up some scientific algorithms for astronomy research which have been well prototyped in Python, but which need to be faster. I am currently, unhappily, doing my work in C++ after abandoning Rust for being too immature in its CUDA and SIMD support, while also feeling pretty complex. Would Zig do well enough for me? I want a little more ink on the page to help me think this through.
- reactordev 3y agoI think the opinions on how a language is used should be left to the developer of in question. If zig said "Zig has X distinctive features, which you should prefer if you do Y" would alienate everyone doing Z and C and D. If ruby did that, we would never have rails. "Ruby has easy coding features, which you should prefer if you do scientific programming". Rails wouldn't exist. So, read the article and determine - "Does Zig with X features solve my use case of me trying to build Z after trying with Y"?
- deleted 3y ago[deleted]
- geodel 3y agoI read a point about lowering activation energy on JDK website about making language more approachable. Though Zig is lower level language and much of use for typical enterprise devs like me it does have vibe of low activation energy. I feel a lot of useful software will be written in Zig once it is picked by young/upcoming clever developers.
- AnimalMuppet 3y agoYeah. How little do I have to know to be able to do a little? It really matters. But then, it also matters that it not trap you. It's easy to only have to learn a little when a little is all there is. But you don't want to use a language like that for something major, because it won't do enough for you. So what you need is something like what the UI people call "progressive disclosure". Are there any languages that do that well?
- anonymoushn 3y agoIt happens that a little is all there is, and you can do everything with it. Languages large enough to need progressive disclosure have made mistakes that prevent things from being as simple as they are.
- andersa 3y agoA better question is, why zig when you could use jai instead?
- themerone 3y agoYou can't use Jai. It is an unreleased pet project of one developer.
- andersa 3y agoIt will be released soon however.
- dymk 3y agoWhere can I learn more about Jai's release timeline?
- adamrezich 3y agothe only current public information on the topic is this post https://twitter.com/Jonathan_Blow/status/1746338114564489291 https://twitter.com/Jonathan_Blow/status/1746338114564489291
- deleted 3y ago[deleted]
- posix_monad 3y agoIf Blow released it openly then I would consider it.
- MarcusE1W 3y agoLast time I looked Jai was in a closed beta.
- the__alchemist 3y agoJai has no embedded support.
- n0ot 3y ago> If you never initialize a heap allocator, you can be confident your program will not heap allocate. This is true for the standard library, where I can trust that no hidden allocations will be made. If I pull in a third party package, nothing guarantees that that lib won't init a new `std.heap.GeneralPurposeAllocator(...)`, right?
- chongli 3y agoRight, but that would be unidiomatic and the third party package should be criticized for doing that. Proper form would be for the allocator to be chosen by the user of the package, supplied as a parameter.
- OskarS 3y agoNo, and it would be impossible to prevent as well: obviously library code can do anything it wants, including asking the kernel for memory. But this is one of those things which just wouldn't happen in practice: custom allocators are so embedded in the Zig philosophy that I cannot imagine competent Zig programmers writing a library that did something like this. It's just not what you do in Zig.
- brabel 3y agoIt's not impossible to prevent. Some languages do just that using capabilities. You can get capabilities by declaring them in your main function, for example, and only passing the capabilities you want to code downstream, such that it becomes literally impossible for any code to get IO access or allocate memory, for example, if the code is not explicitly given that capability. I believe Pony and Unison are examples of languages that do that (not for allocation, admittedly as they are both GC'd, but the concept would work in a language like Zig).
- OskarS 3y agoThe thing you're talking about is just not possible in a low-level, runtime-less language like Zig. Like, utimately Zig. libraries need to generate arbitrary assembly to run on your architecture (like if you want to write a driver or something), so you can't stop someone from just writing a thing that does the syscalls itself. The kind of "capabilities" style languages you are talking about almost always have either a runtime that handles the actual syscalls, or they don't have the capability to compile directly to the assembly you need, everything has to pass through some library. Zig does not fit into either category: it has no runtime, and the whole point of the language is to be a low-level C replacement.
- dymk 3y ago> Examples of hidden allocations: > Go’s defer allocates memory to a function-local stack. Not really hidden if there's keyword indicating it's happening, no? I guess you could argue that "defer" isn't called "defer_and_allocate", but on the other hand, the docs make it clear that it allocates.
- hellcow 3y agoI think it’s fair to say that knowing what allocates in Go requires in-depth knowledge of its internals, well beyond the `defer` example. Every possible allocation is not obvious to the typical Go programmer. It is obvious in Zig.
- vacuity 3y agoAlthough with a language like Go, I would think programmers should expect that allocations occur frequently, and rely on the GC and language design to ensure decent performance or whatever is being asked for. It won't hold true all the time and sometimes more knowledge is needed, but the baseline wouldn't involve that.
- Dwedit 3y agoLack of destructors/RAII is the deal breaker for me. I know that this causes a function call to be made when a variable goes out of scope, which is "hidden control flow" and therefore banned by the language design.
- pixelpoet 3y agoSame with lack of vector operators for me. I've asked a lot :(
- anonymoushn 3y agoWe have them.... for SIMD vectors.
- pixelpoet 3y agoThis forces us to use homogeneous 4D vectors for 3D ops ({vec3, 0} for directions and {vec3, 1} for points), which basically wastes registers when we're doing the right thing with the right vec3 types on a e.g. 32-wide vector machine. If Zig really wanted to do the best job here, it should recognise that we're semantically not using this 4th padding dimension if we're not doing 4D projective stuff. If it really is going to force you up to 4D space, then it should be doing compile time checks e.g. sorry, you tried to add point plus a point which makes no sense, unlike vectors, or vectors and points. This might become more important if Zig to GPU code translation becomes a thing...
- anonymoushn 3y agoRight, clearly SIMD vector primitive ops are not what you want for a 3d math lib.
- zozbot234 3y agoIf you can avoid all hidden control flow, that's actually a great choice. Rust couldn't do this originally because it needed panics, which must auto-destruct objects on the stack.
- adontz 3y agoI'm confused by "No hidden control flow" To me control flow is "if", "switch", "?:", etc. What article describes are abstractions. Abstractions are not bad. They, just like anything else, can be abused. Maybe one may argue are easy to abuse or tend to be abused. But "Zig has no abstractions" is hardly a selling point. On the other hard there are statements like "defer" and "try" which actually are very hidden and unusual control flow statements. Why the naming? Who the hell knows. I see try, I look for catch/except/finally, but there are none. Try in Zig means something else. "defer" is literally "try/finally", but less explicit about the scope. "A Portable Language for Libraries" "A Package Manager and Build System for Existing Projects" "drop-in GCC/Clang command line compatibility with zig cc" Is it still so after ditching LLVM?
- sapiogram 3y ago> To me control flow is "if", "switch", "?:", etc. What article describes are abstractions. Thank you for articulating this, I also don't understand why the author puts operator overloading in the same bucket as exceptions and `defer()`. Yes, `+` might call a function, but it will never affect the control flow of the parent function. Not more than a regular function call, at least.
- PH95VuimJjqBqy 3y agosee my response here: https://news.ycombinator.com/item?id=39092430 https://news.ycombinator.com/item?id=39092430
- kweingar 3y agoI think you have a different interpretation of “hidden” than Andy. He is talking about control flow that is not visible to the programmer at all. In Zig, you can understand the control flow of a particular code snippet just by learning Zig. In some other languages, operator overloading means that when you are reading unfamiliar code, you can never be sure what functions might be called.
- adontz 3y ago
- bachmeier 3y agoThese discussions usually focus on features. How about a simple "because you tried Zig and you enjoyed writing it more than language X"?
- __loam 3y agoThat's not really a substantive case in favor of using the language.
- the__alchemist 3y agoThe lack of operator overloading is a bummer for mathematics code, eg involving matrices, vectors, tensors, complex numbers etc.
- bvrmn 3y agoUnless you don't need full fledged operator overloading to do math. For example there is @Vector.
- habitue 3y agoI am a big rust fan, but I'll say I don't think a language should need to justify its existence and whether it's redundant or not. Zig exists because its developers and users want it to. People like coding in it, that's all the justification it needs. I'm glad people make new programming languages without asking permission from the world whether it provides enough value to exist. (TBC, I realize this page is more about answering questions about differences between zig and other languages, emphasizing its strengths, I just think the framing of the question is unfortunate)
- EchoChamberMan 3y agoThat page could be titled "Advantages of Zig," and it seems to me rather normal that a developer might ask "What are the advantages of Zig/Rust/Python/D over other languages?" and each language has a cost/benefit analysis that is different than what other languages made. I do think justification is useful though - Why should one use Rust, for instance? Well, one obvious answer is that it places a high priority on memory safety, and so, if memory safety is a critical concern, Rust should be something to look at. I am also thinking of the xkcd comic on specifications, and how creating a new one merely confuses the already crowded space, but I'm having trouble making the corollary here.
- Gibbon1 3y agoI'm really unlikely at this point to use zig or even less likely to use rust. But as an embedded firmware guy I'm happy to see people working again to advance the state of the art of actual low level compiled languages. That stopped in the early 90's when we went off the rails with Java and C++ OOP madness. So it's nice to see it again.
- dandigangi 3y agoThis is a good way to look at it. Definitely would say with the size of the landscape makes pro/con comparisons a necessity.
- cmrdporcupine 3y agoI agree and as a person working full time in Rust there are a lot of things in Zig I'm jealous of. I'm now at the "somewhat disillusioned" phase of working in Rust and if I wasn't so heavily buried in Rust projects (both personally and professionally) I'd consider starting a project in Zig. Well, mostly Cargo and Crates.io are my complaints around Rust. But also the lack of progress on allocator-api, and portable SIMD. I would, however, really miss ADTs/pattern-matching if I made the switch to Zig.
- Solvency 3y agoBecause D's tooling and ergonomics are awful. But how are Zigs?
- foresto 3y ago> D's tooling and ergonomics are awful. Can you elaborate?
- jokoon 3y agoI don't really agree about the simplicity: to me, C3 feels like it's closer to C, and C is just simpler to learn. Although among those new statically compiled languages, zig would be my favorite choice. I just wish it was just even simpler.
- bvrmn 3y ago> C is just simpler to learn But there is a huge gap between ability to learn C and ability to write working software in C. I've inherited a small (500 loc) C codebase with ldpreloadable library. Guess how many crashes I've fixed already? 7! And it's a security sensitive code supposed to run under root.
- skybrian 3y agoThere’s some tension between the first section about what Zig guarantees and later sections about having great interoperability with C. If you have a lot of C dependencies because it’s easy, what guarantees can you have? Doesn’t the C code need a system allocator? Maybe this could be resolved by distinguishing between writing new libraries in Zig and building applications. New libraries can be clean and reusable even if the applications are a hodgepodge of dependencies. For libraries, reuse versus rewrite is still a question. With any new language ecosystem that provides new guarantees, there’s a drive to build a new set of libraries within the ecosystem to get those guarantees. This is an enormous effort. An end goal of making libraries more reusable, to stop rewriting them, seems in tension with the means of getting there, which is by rewriting rather than reusing libraries. Also, if you write a library in Zig, aren’t you limiting your audience?
- defen 3y ago> Also, if you write a library in Zig, aren’t you limiting your audience? The Zig compiler has a C backend so at worst you could just compile your library to C so that anyone with a C compiler can use it. However you can also export C-compatible functions, which is roughly analogous to having an `extern "C"` interface for your C++ library. The consumer would need a Zig compiler, of course, if they wanted to build from source.
- justincredible 3y ago[dead]
- softirq 3y agoThe standard library being designed to allow freestanding binaries makes Zig a much better language for systems software such as kernels, EFI applications, etc. than Rust. Rust's addition of operator overloading is also a perplexingly bad decision. I don't think there is a single worse design decision in C++ or Rust than allowing someone to redefine what + means on some arbitrary type.
- tnecniv 3y agoEh, I think operator overloads make a lot of sense in the right context. If you created a type that’s a kind of mathematical object, you want a mathematical syntax for it. However, they are horrible when abused.
- thatxliner 3y ago> Rust's addition of operator overloading is also a perplexingly bad decision. I don't think there is a single worse design decision in C++ or Rust than allowing someone to redefine what + means on some arbitrary type. Why is that? Won’t it be more ergonomic than needing to call, say `.add`, when you want to do something clearly similar to addition. It’s just sugar, no? In Java, there is no operator overloading, so if you want to compare 2 strings by contents rather than their memory addresses, you have to use a `.equals` method. Comparing 2 strings by their contents is the most common use case, so it not being the default is a design flaw (similar to how you need to `break` out of a `case` in most languages). If you can’t overload the addition operator, then why have a whole language construct that can only be used on primitive integers and floats?
- zozbot234 3y agoThing is, Rust has full support for hygienic macros so operator overloading could've been added as part of that. You'd just have to write, e.g. int_expr![a + b] or whatever, but that would've made the syntax fully extensible.
- softirq 3y agoMacros are easy to spot, the whole point of operator overloading is that it's a trojan horse. It might do simple addition, it might do a heap allocation and talk to a printer.
- IlliOnato 3y agoIf there is no string concatenation operator (for run time), how do you concatenate strings at run time with Zig? Depends on what you work on, I guess, but in my area of expertise string operations like concatenation are bread-and-butter.
- WalterBright 3y agoEasy string (and array) concatenation is a godsend: string b = "betty"; string s = "hello " ~ b;
- Leherenn 3y agoYou allocate a big enough buffer, and copy the strings in the buffer, same as in C.
- anonymoushn 3y agoYou probably use fmt instead. You provide a format string, an anonymous struct (a tuple) containing the values to be formatted, and a writer or byte slice, and you get the formatted string written to the writer or the byte slice.
- WhereIsTheTruth 3y agoI use D, and there is nothing in that article that's convincing enough for me to switch $ time make build-game real 0m0.387s user 0m0.309s sys 0m0.077s $ time make build-sgame real 0m0.334s user 0m0.245s sys 0m0.057s Complete full rebuilds of my game and game server on linux (on windows it is the double)
- 29athrowaway 3y agoOnly C++, D and Rust? What about Ada, Pascal, Swift, Nim, Crystal, Carbon, Jai, etc.
- EasyMark 3y agoonly so much time in the day/familiarity?
- qprofyeh 3y ago> C++, D, and Go have throw/catch exceptions I believe Go does not.
- latchkey 3y agoI stopped reading the whole article after that bit and came here to find the one comment that called it out. =)
- pjmlp 3y agopanic/recover allow to implement something like exceptions.
- latchkey 3y agoYou and I both know that is nothing like exceptions.
- pjmlp 3y agoThanks to having compilers as part of my major I know that exceptions come in many forms.
- latchkey 3y agoOh right... Person A claims that X is true. Person A is an expert in the field concerning X. Therefore, X should be believed. Error handling != exceptions https://news.ycombinator.com/item?id=4159672 https://news.ycombinator.com/item?id=4159672
- pjmlp 3y agoOh right, the claim to authority kind of reply. If it quacks is a duck.
- 3y ago
- teunispeters 3y agoZig : because language design is better when encouraged by diversity, as so many things are.
- dzonga 3y agoI think the other important thing would be who is using zig in production besides Bun & TigerBeetle ?
- anonymoushn 3y agoWe use zig to trade cipher tokens derivatives.