8 ms·
What Zig felt like, coming from Rust
- deleted 14d ago[deleted]
- gigatexal 14d ago“ The language is different from Rust (who could’ve thought that, yeah), but it left a genuinely good impression. It’s straightforward, modern, and blazingly fast. I believe it has real potential to become the true successor to C. On the other hand, it’s still young, and it shows: the shape of the language itself feels unfinished in places, and I suspect it’ll pick up more of the cooler quality-of-life features and syntax sugar as it matures. As for me, I’d like to keep contributing to the ecosystem, and I will, whenever I come across a project worth building.” Idk I don’t write either well enough to have a hand in this but losing out all of this for more Imperative stuff seems like a step back. “ No functional paradigm Rust is technically an imperative language, but it draws heavily on functional concepts: zero-cost iterators, lazy evaluation, ADTs, pattern matching, monadic types, traits, closures, and so on. Having also spent time with Haskell and Erlang, I’ve become fairly inclined toward the functional style, and it shows in this library. It leans heavily on FP idioms: Monadic error control via combinators like Queryable and related types Monadic-style data types like Data<T> with map, flat_map, reduce, and friends Pure, immutable transformations Combinators over iterators instead of loops Closures for local abstraction Declarative macros as a small embedded DSL Sum types and product types”
- api 14d agoI would say Rust is a functional language that has been hammered into the shape of C++. It also draws heavily on ML. I get why, and it makes it a better fit for its obvious “C++ reimagined, cleaner, and better” niche.
- pjmlp 14d agoModern and blazing fast, what we lost leaving behind languages like Modula-2 and Object Pascal, having newer generations to think C and C++ were the only compiled languages alternatives to scripting languages.
- touisteur 14d agoI miss the years of writing CLI tools, web servers and clients, in Ada (and of course, real-time complex distributed system...). Felt so simple and right and fast and robust. The code is still readable today and maintaining it is a zero effort today. Clean Java without the enterprise BS was a close second in ease of programming - boilerplate be damned. I'm glad NVIDIA found a way to make GPUs programmable and got us out of the shaders tarpit, but did it have to be C++...
- pjmlp 14d agoAlso a good one.
- jstimpfle 14d agoYou repeating this weird strawman take a million times doesn't make it true. Why don't you finally just put out some genuinely interesting projects demonstrating how everybody was doing it wrong, so people can make up their own mind and finally be convinced. There must be some true magic in those languages and platforms you mention, that should offset the pain of writing in upper case and with super long KEYWORDs everywhere, and to offset the cost of switching to a culture that has way less mindshare and way less of a software ecosystem around it. FWIW I've actually worked for 6 months on a large old Delphi project. It was some performance work that, as almost always, mainly required getting the language crap out of the way. In the end I got the job done (100x-1000x speedup) but I wouldn't want to switch back to this ecosystem: Licensing costs, weird language warts there too. A slow moving ecosystem. Ultimately, I just need something that does what I tell it to do, reliably and fast, and that doesn't get in the way.
- pjmlp 14d agoIf you don't like, press PgDn.
- AndrewDucker 14d agoPeople should reply on Hacker News. If you disagree with someone's opinion and you have reasons for doing so then the right thing to do is share them.
- cosmic_cheese 14d agoI’m more than a bit out of my depth discussing the topic, but I’m not sure than imperative-dominant languages will ever really go away or that functional-dominant languages will ever become as popular as C and C++. Ugly as they may be, imperative languages seem to be grokked by humans more readily and are more often than not “good enough” for the most part so it’s difficult to see them losing substantial momentum.
- pyrolistical 14d agoUntil there is a machine that is natively functional, there is always going to an incentive to go lower level for more performance. Even hardware (GPUs) that functional language could trivially exploit, it’s still higher performance to write low level code and manages all the memory imperatively
- ModernMech 13d agoI think you’re right about people, but by volume, 99% of all future code will be written by machines. So there’s ample opportunity for other languages to flourish; if humans can’t get past imperative programming, machines can.
- cosmic_cheese 13d agoIn my mind this hinges on whether LLMs become capable of actual comprehension of the code they’re writing. If not, for serious projects (especially those which are mission-critical), it still makes sense to optimize for human understanding when selecting languages so the code can reasonably be verified.
- diek 14d ago> One caveat worth stating up front > Here’s the actual difference, side by side I realize the author put a disclaimer at the bottom that they used AI for styling, but having to wade through this stuff at work all day my brain now actively rejects Claude-isms in prose.
- rtpg 13d agoI don't think they just used it for styling unfortunately, the entire thing felt like this. Why can't people just write shorter bullet pointed lists of things and post that? Just post what you put into the AI!
- bbg2401 14d agoI don’t see the point of letting an LLM generate an article when the topic is your personal, subjective experience which only you, a human, would be able to express.
- metaltyphoon 14d agoSo anything that has em dashes is now considered LLM generated? What made you think this is generated?
- abound 14d agoNot OP, but I think the leading and trailing paragraphs were mostly human-written (and nice to read), but the memory leak example cases had a very different flavor of prose and code comments that smelled very Claude-y to me
- metaltyphoon 14d agoAfter going over that section again I can see it now.
- brilee 14d ago"It's young, and it shows" "Holds up" "not a toy, but not a sprawling project either, and ideally.." "And that’s the trap" ctrl F "real" -> 6 usages ctrl F "genuine" -> 4 usages
- spider-mario 14d ago> The first thing that caught me off guard — and honestly, who would’ve expected this to be the memorable part — was IDE support, or the near-total lack of it. I would have completely expected that.
- tialaramex 14d agoI think when we're looking back on the 2020s we'll be struck by the Allocator obsession All of the Handmade "C successor" languages seem to have this obsession, including not only Zig but Odin, C3 and Jai. For some toy problems you can do clever allocator tricks and get a huge perf win. For example Jai and Odin both seem to really want you to write code which can throw away a "per-frame" arena periodically so they're not paying to track allocations in the arena because they're all thrown away at the same time. But a lot of real world software just isn't that simple. This doesn't make such features worthless, it just means they're one of a thousand tools the experienced developer could want in their toolkit, not really deserving headline status.
- pton_xd 14d agoAAA games use allocators extensively, and they are more complex pieces of software with higher performance requirements than nearly anything else out there. So I'm not sure what toy problems you're talking about. Allocators have been in wide use long before the 2020s but I agree there does seem to be a resurgent interest lately. Although I would argue it's part of a more broad trend of focusing data driven design. Which makes sense because accessing main memory is one of the slowest things your program can do.
- kllrnohj 14d agoAnd those games do so in a language (C++) where allocators is not a headline feature, and is barely even supported at all in the standard library. The important part is a language where the standard library isn't special, and Rust has this property, too. So in domains where things like per-frame allocators are useful, you can still have them. That capability just isn't cluttering up the more common path where that isn't useful.
- lefra 14d agoI never used it in practice, so maybe the support isn't that good, but I was under the impression that it was possible to pass custom allocators basically everywhere in the STL. See for example the definition of a vector here: https://en.cppreference.com/cpp/container/vector https://en.cppreference.com/cpp/container/vector
- karmakurtisaani 14d agoOff topic, but I remember fondly the pre-LLM days when I used to love reading about programming languages. I never got a chance to professionally work with Rust, but made some cool hobby projects with it. Would have eventually tried out zig too. Now it all feels so pointless though. Like memorizing rules to do mental arithmetic. Sure, there is still use for language expertise, but not enough to get excited over new concepts and ideas.
- ratorx 14d agoI think (for now), it is still relevant. A language is an abstraction, and a good abstraction, like a good LLM harness, can be quite valuable. Let’s say I’m writing some concurrent code with an LLM. I’d probably feel much safer having it write Rust, rather than C. So even in a post-LLM world, languages will continue to evolve as long as abstractions can be improved.
- karmakurtisaani 14d agoBut do you still have enthusiasm for finding out about new language features or concepts? I'll do what it takes to get the job done, but the passion for it is totally gone.
- tonyhart7 14d agonothing stopping you to code manually
- karmakurtisaani 14d agoNothing stopping me from doing a lot of things. But is there any point to it?
- layer8 14d agoMeaningfulness comes from what you care about. I wonder why you were interested in programming-language concepts before but now (apparently) stopped caring about the code. The code still remains the language that communicates the actual program logic.
- ozgrakkurt 14d agoWould recommend learning how to use arena allocation. You would have patterns like: fn run_query(alloc) { arena = init_arena(alloc); defer arena.deinit(); }
- simonask 14d agoStep zero of using arena allocation is to build realistic benchmarks so you can measure if it's worth the trouble in the first place. Standard allocators are incredibly good these days, and even plugging in mimalloc or jemalloc will be much less work, and much less error prone.
- slopinthebag 14d agoi think the reason is more that arena's let you manage lifetimes in groups instead of pointer chasing. if you have to manually manage memory, it's eaiser to manage a small number of arena objects instead of a large number of individual objects. eg https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-allocator https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-a... that being said, it's even easier to not manage any lifetimes at all :) although i suppose some will say that you still manage lifetimes in rust, you just have full support from the compiler to make sure you do it right. that seems better to me than relying on simplification to ensure you don't make mistakes.
- boomlinde 14d agoI don't know about more error prone. Benchmarks completely aside, freeing a batch of stuff you've allocated in a single place makes it easier to manage memory. I think it should be preferred wherever it's an option for that reason most of all. The "killer app" is something like an arena allocator that lives for the duration of an HTTP request.
- simonask 14d agoI respectfully disagree. The technique has its place, and I use it once in a while, but whether it makes a positive difference for performance is highly sensitive to a number of factors. For example, bump style allocators allocate very quickly, but at the cost of higher memory usage and therefore sometimes worse cache locality. The only way to know is to actually measure.
- weinzierl 14d agoTwo additional points: 1. Tooling (as an extension to the mentioned IDE support point). Zig and Rust are both praised for their tooling and I think rightfully so. The C/C++ interop story and the cross-compiling story in Zig are great. From the standpoint of a working practitioner though I think Rust is way ahead. Not surprising given that Zig is much younger, but something to keep in mind. 2. Compile Time Stuff: Here Zig is praised and Rust not so much. I think this is undeserved. Rust has much higher aspirations for their compile time features, namely that outcome must be identical regardless when the code runs. This is a very useful property but makes the task much harder and fundamentally incomparable with Zig comptime.
- LoganDark 14d agoZig comptime feels easier and more effective in practice. I've had some fun const evaluating some stuff in Rust, but I needed to use a bunch of annoying imperative hacks because so much of the functional stuff wasn't supported in const context back then. It's probably a bit better these days. For one of my crates I needed to have a build script make a bunch of lookup tables as separate files for me to `include_bytes!` because at the time I couldn't generate a bunch of floating point conversions in const.
- vlovich123 14d agoThere’s a few comptime crates out there. Crabtime is iirc the most mature and popular
- LoganDark 14d agoI don't know if I would ever depend on something like that for a library crate. There's enough syn+proc_macro2 pollution in the ecosystem already.
- tialaramex 14d agoIt does seem like maybe a crate with convenience macros so you can get a `&'static [Foo; N/size(Foo)]` rather than `&'static [u8; N]` and maybe even a delicious compile time "Hey jerk, that's not a valid Foo, you screwed up" if appropriate from your pre-baked data files, would be nice regardless of having more constant eval.
- truth_seeker 14d agoDetailed in depth look at Zig Vs Rust (also ... Vs Go) https://gist.github.com/corporatepiyush/5382d79192be9737cf3bb8613ccea01e https://gist.github.com/corporatepiyush/5382d79192be9737cf3b...
- hn_submit 14d agoThere will never be a true successor to C since C is "high level assembly." The lack of pointer checking, unsafe casts and non-existent bounds checking aren't an oversight but by design! Assembly doesn't have them so neither does C! There's no reason to whine about it. The real problem is that people are using C for the wrong reasons. C is for the development of operating systems and low-level code, not applications. Zig is more modern but anything that does even one iota more of hand-holding or has anything that looks like a guardrail fails the test. If you want to write applications use Pascal, Java, C#, Swift or Go.
- monocasa 14d agoExcept Rust is actively being used in kernel space and low level embedded systems as well.
- hn_submit 14d agoIt's useful, but systems programming languages shouldn't be used to create applications in the first place. We're trying to solve a problem that shouldn't be solved. We're continuing and even confirming the usage of systems programming languages for application development.
- everforward 14d agoI don’t think this delineation is that clear, unless by “application” you mean the app tier of a 3 tier app. Postgres and Nginx make sense in system programming languages; they’re extremely performance sensitive and that granular level of control offers them features. Interpreters are sort of the same, they interact with the OS a ton, it makes sense to work in the same language as the OS. I do generally agree for the app tier of a web app. I wouldn’t build a CMS in Rust, but I also wouldn’t build a reverse proxy in Python.
- hn_submit 14d agoWriting an operating system kernel in C is valid usage since there's a great deal of thought going into it and it almost never changes. EVERYTHING ELSE is invalid usage no matter how performance critical people claim their application is. These are just excuses for people to use a grossly unsafe language to get that last 2% of performance whilst costing the world trillions in lost productivity and security breaches.
- Syzygies 14d agoFor various purposes I work on a language comparison project that includes C and candidate successors such as Go, Zig. One question is the language to use for an archival port of a 1980's computer algebra system written in 32-bit K&R C. While Zig is a great debugging compiler, it's not yet stable enough to be the best target language for archival purposes. https://github.com/Syzygies/Compare https://github.com/Syzygies/Compare So you're in a restaurant where you don't speak the language, you can't read the menu, but you see three price points for set meals featuring the house specialty. (Say, "Crossing the Bridge" noodles in Yunnan.) Which do you choose? My tour guide, the author Fuchsia Dunlop, later agreed with me this is obvious: The middle choice. So you're choosing between Go and C23 as candidate successors to K&R C. They both have "royal blood". One got the name. Knowing nothing more, which do you choose? The answer is equally obvious. The one that got the name also got the warts.
- pjmlp 14d agoDespite my usual rants, naturally C23. Minimal rewrite due to the breaking changes introduced in C23 versus K&R C, while the others are a complete rewrite. Even if the syntax is a bit of a kludge there are now ways to indicate bounds on function arguments.
- d0mine 14d agoMiddle may be wrong (it is a marketing trick to add 3rd outragesly expensive option, to make 2nd option look reasonable). The correct answer is “it depends” (even how long you should spend on choosing may depend on context too). For example, write in whatever language you know best, then translate to a more appropriate language using LLMs once the desired behavior can be checked automatically. It is a tactic that works in some cases.
- kelipso 13d agoIt can be used as a marketing trick, possibly because of the logic in GP post. Marketing people use this to trick people, which is different from it being a marketing trick in and of itself.
- flossly 14d ago
- csense 14d agoOne of the section headings says "Mutation vs. immutable monad is the core difference" but this is not true. The code in that section is clear in its purpose and broad outline: "Give me a function and data; if the data is bare apply the function to it; if the data is a container apply the function to each item inside it." You can absolutely do that with immutable data structures in Zig. You just have to pass an allocator to the function (i.e. instead of calling data.flat_map(f), you call data.flat_map(a, f) where a is your allocator). That the Zig version of the code does mutation is a matter of programmer choice, not something imposed by the language. (Also, what do monads have to do with it?)
- bunderbunder 14d agoFurther up he discusses that using a functional paradigm is possible, but concludes that it doesn’t feel like a practical choice because of how Zig does memory management: > But the language quickly forces you to diverge from the functional style, mostly because you’re now dealing with allocators directly, and a genuinely pure functional approach means constantly constructing new structures. That’s either expensive in memory or expensive in the manual bookkeeping needed to avoid it. So I don’t think he’s trying to say that it’s literally impossible. It felt more like the result of a good faith attempt to understand how Zig itself actually wants to be used, and to compare that to how he’s used to using Rust. I actually liked that he did it. So many other comparisons want to evaluate one language against the other language’s values. But I don’t want to know how well Zig can do Rust; I want to know how well Zig accomplishes its own goals, and what those goals are.
- kccqzy 14d agoMonads are where flat_map came from. A monadic programming style is where flat_map is used pervasively eschewing other APIs.
- tialaramex 14d agoSo, what you're not seeing is that even though the Rust doesn't announce mutation the implementation may be mutation anyway if that's probably faster/ cheaper. unsafe impl<I, U, F> InPlaceIterable for FlatMap<I, U, F> where I: InPlaceIterable, U: BoundedSize + IntoIterator, What you're seeing is the graceful goose on the water moving forward at pace. Beneath there is frantic action to make that happen. The Rust surface was more a maintainable immutable operations, but the implementation is a frantic whirling mutation like the Zig. In Zig you end up spending a lot of time writing How to do a thing, where in Rust you only wrote What the thing is and the machine did it. There are edge cases where Zig's explicitness wins for the best programmers, but there just aren't enough of those cases or those programmers for this to net out IMNSHO.
- plqbfbv 14d agoMaybe I'm not that deep into programming, but I don't understand the hype about Zig? I programmed in rust a bit and can't say I'm an expert, but in my view rust mostly-solved the memory management problem at compile time and without a GC, and it works very well. The biggest con and cost I've always seen repeated so far is that "it's slow to compile", and I get that, if you're past 250 crates the final --release link tends to become noticeable, but there were improvements to incremental compilation. On the other hand - looking at the syntax from this post - Zig feels a blend of javascript, python and golang syntax that still requires memory management. So a nicer-written C that inherits all the issues from C? From the post: no functional programming, data mutation, memory leak, double-free, memory corruption. Personally I'd rather trade a couple minutes of final link every time when this is the other option.
- slopinthebag 14d agoyeah to me zig exists as a counter-reaction to rust. which means avoiding both the good and bad things rust does. and rust does a lot of things right, so...
- IncreasePosts 14d agoRust is for devs who think "if only c++ had a few more features, it would be perfect". Zig is for devs who think "if only C had fewer features, it would be perfect"
- slopinthebag 14d agoironically rust has fewer features than c++ and zig has more than c
- IncreasePosts 14d agoGive it a chance! Rust hasn't even had its bar mitzvah yet and C++ is already buying a Porsche during its midlife crisis. Yes, on paper zig has more features than C, but what zig has is explicitness. C has a big murky space of implicitness. For example, there might be 5 different zig features which can be used at various times you might use a void* in C, buy the conceptual space of void* fully contains(and then some) the spaces of those zig features.
- gslepak 14d agoI'm honestly baffled why people are writing Zig or Rust and avoiding V. V (and now Bend) seems like the future to me.
- myko 14d agoI haven't heard of those, but I've used Zig and Rust for some projects What's the pitch?
- ModernMech 13d agoThe V pitch was a bunch of features that seemed implausible like automatic C++ translation and near-GC ergonomics with near-manual-memory behavior, without Rust-style explicit lifetime annotations or pervasive reference counting. so basically the pitch was the holy grail of systems, which caused drama as the project was met with extreme skepticism. That was 7 years ago and since then the project has not delivered the grail, instead settling to be more of a mashup between go and C. Bend is completely different it was just announced last week. It doesn’t have any users and has a weird ai integration so I done see how it’s relevant as a contender in the systems space at all.
- irwt 13d agoAlso the creator of Bend is... lets just say he doesn't stick to projects for long.
- altairprime 14d agoSuch bafflement is often a medium-strength signal of the Bystander Effect. If someone wrote and submitted to HN your own blog post comparing the Zig/Rust examples from this article to ones from V, I’d read it in its entirety knowing nothing whatsoever about V. Perhaps it will be written by you!
- a96 12d agoNever heard of them. V looks neat in some ways, but there's still no 1.0, installation tells you to compile the compiler form source and it still uses and depends on a C compiler behind it. And defaults to GC. That's a ton of reasons why various people would drop it on sight. Also, inertia, of course. Zig suffers from much of those, as does Nim. Rust OTOH appears well integrated and stable and I'm even seeing a lot of corporate use. I'd love to see V get to that level as well. But seems it's not even here in the present, let alone the future.
- AlienRobot 14d agoIn the example of Rust: items.iter().enumerate().filter(|(_, i)| cond(i)).map(|(idx, i)| Pointer::idx(i, path, idx)).collect() vs. Zig: while (i < cursors.len) { if (actual_index < arr.items.len) { cursors[i] = .{...}; i += 1; } else iteration.remove(i); } I think you have to be a special kind of person to call Rust "more readable." The thing about Rust is that if you can appreciate zero-cost abstractions on iterators then the language feels like the only right way to program. But many programmers either don't use this sort of programming at all, or don't care if it has a cost in languages like JS, Python, Java, etc. Personally I like Zig a lot because it feels like you're doing low-level programming but without having to program C which is... well, https://xkcd.com/918/ https://xkcd.com/918/
- sgarland 14d agoTHANK YOU. I feel exactly the same way. https://news.ycombinator.com/item?id=49769812 https://news.ycombinator.com/item?id=49769812
- metaltyphoon 13d agoYou realize you can write the Rust version in the same way the Zig one too right?
- AlienRobot 13d agoI don't understand what you mean. The examples come from the article.
- myko 14d ago> One caveat worth stating up front It would be nice if people would note that their posts are AI generated, and put that in the title here to make it easier to ignore
- Hugsbox 14d agoI'm not exactly sure what you mean, that seems like a pretty phrase to me, is it considered an LLMism now? Kinda feels like the same thing with the em-dashes; I can't use em anymore because people will then assume I'm an LLM, even though just a few years ago it was a perfectly normal thing to do. It's entirely possible I'm just getting worse and worse at picking out LLM writing these days too, who knows.
- comex 14d agoIt’s a very common tic of recent Claude models specifically. Don’t worry - for better or worse, the labs are trying to train away AI writing smells (for example, Anthropic talked about Fable 5.1 having more natural writing), so this particular tic will probably become outdated as an AI indicator relatively soon, as em dashes already have. And then people will forget about it.
- deleted 14d ago[deleted]
- jauco 14d agoGiven that the author mentions both using helix and zig encouraging larger files with more content I’d be curious to know how they navigate these files in helix. The thing that keeps me from using it is lack of code folding, which I notice I use a lot when navigating larger files to zoom out.
- elendilm 14d ago> It turns out I’d simply forgotten how straightforward it can be to rely on bare CLI tooling. Happy for you. CLI tooling counter intuitively makes for very less friction especially when you are moving very fast.
- theturtle 14d ago[dead]
- sgarland 14d agoFrom TFA, on combinators vs. loops: items.iter().enumerate().filter(|(_, i)| cond(i)).map(|(idx, i)| Pointer::idx(i, path, idx)).collect() while (i < cursors.len) { if (actual_index < arr.items.len) { cursors[i] = .{...}; i += 1; } else iteration.remove(i); } I’ve been slowly learning Rust, and this style is my main gripe against it, because I feel like I’m being gaslit. Its proponents praise its readability and ease of use, and just… no. It looks deranged. A simple loop is immediately obvious to anyone who’s programmed in any language. Even Python’s list comprehensions are loop-ish.
- himata4113 14d agoitems.filter(|(i)| cond(i)).map(Pointer::idx).collect() you can probably get away with this if you implement a Trait, not sure how but I know for a fact this is possible, idk why there's an enumerate there when you aren't even using it. items is already an iteratible so you can do direct .filter on it as well tl;dr if the code looks ugly you're probably not taking advantage of a language feature that allows it to look pretty.
- sgarland 14d agoThis is in fact more readable, thank you. I still don’t know that I find it more intuitive or readable than the simple loop, but it’s much less awful than before.
- himata4113 14d agoI am sure there's a way to filter directly on cond variable and collect isn't needed most of the time since iterators are way more useful in general (unless you want to print that data) items.filter(cond).map(Pointer::idx) I know this is possible, but you would have to consult some rust wizard for this.
- matja 14d ago.len doesn't work on a list (because it might mislead you about the efficiency of the operation if it did exist), so it's better to use iterators - so then you can change the underlying type without changing your code. But then, saying while "let Some(item) = iter.next()" everytime is tedious, so they give you .iter() - for any type that is efficiently iterable. Nothing stopping you using a manual loop that you need to update if you change the container type.
- 833dong 13d ago[flagged]
- computerfriend 13d ago> Zig, by comparison, offered little beyond syntax highlighting and basic autocompletion. Zig has a language server and "The majority of LSP features are supported" (https://github.com/zigtools/zls#features https://github.com/zigtools/zls#features).
- batisteo 13d agoThat's why they move to Helix
- lr1970 13d agoAnd Zig VScode extension is quite good.
- cztomsik 13d agoZig had a breaking change half year ago and since then ZLS only works for std and local code, not for any deps. Zig is nice language but dev experience is a real nightmare at the moment. I say that as maintainer of three non-trivial libraries, and I have one Zig project in production. That said, I've been re-evaluating my choices lately.
- brodo 13d ago0.17 will fix the build-system related ZLS problems.
- functional_dev 13d agoLearned today why there is no "zig metadata" command. A dependency can be marked lazy, so whether you even need it depends on the build flags you pass. So ZLS has to actually run your "build.zig" to see the modules That is why it breaks when Zig changes the build system. https://vectree.io/c/zigs-build-system-protocol-module-graphs-buildzigzon-and-cargo-metadata https://vectree.io/c/zigs-build-system-protocol-module-graph...
- throwaway888777 12d ago> That said, I've been re-evaluating my choices lately. I see you have a blog - it would be interesting if you wrote up the results of your thought process, whichever way you decide in the end. As a PL nerd, I really enjoy reading well-informed takes from people who have seriously used a language as to its strengths and weaknesses.
- Panzerschrek 13d ago> Rust: Drop runs automatically at scope end, so this specific bug simply doesn’t exist. That's why having no auto-destructors is a dead-end. This is the greatest mistake of such languages like Zig or Odin.
- dnautics 13d agoYou can statically analyze for leaks.
- Panzerschrek 13d agoBut with static analysis it's still possible to miss some leaks or to have false-positives. That's why an integrated language mechanism preventing such leaks is much better.
- dnautics 13d agoYes, so you pick "false positives" instead of "missing some leaks" and you build a way to mark code as "unsafe". This is not fucking rocket science > That's why an integrated language mechanism preventing such leaks is much better. No categorical difference, except one is opt-in. You can even design your static analyzer so it analyses the code of dependencies that haven't opted in.
- estebank 13d agoMaking things opt-in means that it will happen less often, making them opt-out that they will happen more often. In this case, on the one hand you have destructors that don't run when they should, and on the other you have destructors running at a more granular level than you'd want sometimes. I know which human failure mode I prefer.
- dnautics 13d agoIn practice as long as you stick to using zig std, an analyzer can get quite far
- MiroslavPokorny 13d agoIm sorry running all tests is just dumb and a time waster when you want to fix just one or a few tests out of many.
- bayindirh 13d agoYou can run any number of named tests, from what I understood?
- MiroslavPokorny 13d agoOf course you can, but theres a reason why people like IDES where they can point and click to select and run tests rather than typing names.
- bayindirh 13d agoDepends. I'm a huge fan of Eclipse (yes, that one) and use it heavily for my C++ and Python projects, yet I have no problems with hitting a couple of more keys to run some named tests when required (i.e. Go). When I'm in my flow state, I find reaching for a pointing device is taking longer than typing something in, BTW. Keyboard driven interfaces and terminals are underrated.
- MiroslavPokorny 12d agoYou just reiterated my point, people dont like typing long command lines with names when they could just use the smarts of an IDE.
- bayindirh 12d agoI don't think so. Selectively running tests is not in my top 100 reasons to use an IDE list, even. I like IDEs for all the code insight they provide. Running a named tests by typing its name is not a nuisance by any measurable distance (for me).
- aitoolcrux 13d ago[flagged]
- sharktheone 13d ago> The first thing that caught me off guard — and honestly, who would’ve expected this to be the memorable part — was IDE support, or the near-total lack of it. Yeah this was also surprising to me the first time I tried Zig. ZLS exists, but back when I last used it it was unstable and crashed frequently. I wrote a small toy JVM. In case anyone interested: https://github.com/Sharktheone/yeeeeem https://github.com/Sharktheone/yeeeeem
- torginus 13d agoPersonally while I'm somewhat pragmatic about Rust, I do have to admit it fills a niche that no other language does currently: that of a high-performance, zero runtime memory-safe language. By memory-safety I mean the basic 'no crashes and corruption' version, that's fulfilled by Java, Go etc., but not by C++ and Zig. I'm a C++ dev among other things, and I have enough experience to know, you really can't hand C++ to a novice dev (even one who uses smart pointers correctly), and expect an app with no memory related crashes/issues. For this reason only, I generally thing C/C++/Zig is a language for typical professional projects/applications (which are written usually in GC languages nowadays). I think it's a hard cutoff criteria. Most programmers/orgs simply cannot work with memory unsafe software. Most commerical C++ codebases leak. This is basically the most important and common 'niche' of SW dev, which for some reason has been somewhat neglected, and I don't really consider Rust a great fit here either, but it doesn't lack anything that would disqualify it. Swift would be another good choice, but it seems that language is very tied to the Apple ecosystem. The only (non-Apple) language that understood EXACTLY what these people wanted imo was Object Pascal/Delphi in the 90s to early 2000s but seem to have died out unfortunately.
- andsoitis 13d ago> Personally while I'm somewhat pragmatic about Rust, I do have to admit it fills a niche that no other language does currently: that of a high-performance, zero runtime memory-safe language. Ada/SPARK comes close: memory safety is very strong, formally provable. Has no GC. Excellent performance. Very mature.
- MBCook 13d ago
- janden 13d agoArticles like this make it clear that I have no idea what I'm doing. And I probably never will.
- waffletower 12d agoI found the statement "I found the resulting Zig code less readable than its Rust counterpart" absolutely hilarious, especially if you look at the code example comparison just above the statement.