15 ms·

I am not yet ready to switch to Zig from Rust

72 points by avinassh 2y ago

cletus 2y ago
I have no issue with the author's points but I just don't see these two as solving the same problem. Zig, to me, is a better C (as the author notes). It seems like it's designed so you can combine easily with a C code base and incrementally migrate it. That's a great application. I'm not expert enough to speak on the merits of comptime (which the author talks about). But isn't comptime somewhat equivalent to constexpr and similar compile-time constructs? Rust, to me, fills a niche as a better C++. Macros are better templates. Compile-time ownership checking is better than a C++ runtime smart pointer. There is legacy in C++ that you can never escape eg someone just calling .get() on your smart pointer and doing God knows what with it. Rust treats memory safety as being of paramount importance and aims to do that with zero runtime cost. That's a great goal but it's also fundamentally different to Zig's goals.
- notfed 2y ago
  Well said. Though it'd be sorta neat IMO if we could use just one language here, and the memory unsafe aspect could somehow be toggled off or on, gaining all the pros or cons of Zig vs Rust as needed.
  - lolinder 2y ago
    Are you thinking of something different than Rust's `unsafe`?
  - cletus 2y ago
    What you're talking about here is disabling runtime assertions, which is a common practice in C/C++ (using #define macros). Runtime assertions are strictly inferior to Rust's compile-time assertions because Rust allows you to do a subset of what you can do in C/C++ but it verifies that the memory ownership is correct without a runtime cost, unsafe code notwithstanding). There simply is no way you could do that in C/C++ (and, by extension, Zig) because of the legacy support. I'm fine with having multiple languages. One language to rule them all just tends to mean something is mediocre at everything.
- knighthack 2y ago
  How is it a "better C" as compared to Go? Genuinely asking.
  - Bilal_io 2y ago
    Go is a garbage collected language
  - kstrauser 2y ago
    Go is garbage collected. That's a non-starter for a lot of C use cases.
  - adrusi 2y ago
    Go has a heavy runtime, including both a garbage collector and a userland scheduler. Those features both make it inappropriate for some applications where you would use c, and also make calling (and especially being called from) foreign code problematic. You effectively cant implement a library in go and then call it from another language, not without considerable ffi overhead at the very least.
  - ilrwbwrkhv 2y ago
    Go would be amazing if it didn't allow dumb mistakes such as: type Human struct { Name string MaybeHasCat *Cat } type Cat struct { Name string } func main() { h := Human{} h.MaybeHasCat.Name = "Taffy" } And boom. Null pointer exception because MaybeHasCat is null. The fact that go doesn't let you define an optional type is such a pain. A lot of newcomers while getting trained up fall for this bug. edit: updating to add the pointer i missed. also adding a playground link: https://go.dev/play/p/izcod8xF7ZQ https://go.dev/play/p/izcod8xF7ZQ
    - koeng 2y ago
      That’s not true. Here is a go playground of pretty much that exact code running just fine https://go.dev/play/p/v7OM9s_pRqY https://go.dev/play/p/v7OM9s_pRqY
      - 2y ago
- overgard 2y ago
  I'm not sure Rust is in the same space as C++, so I'm not sure I'd call it a better C++. I use C++ because I want performance without all the accounting operations that have to happen in C. I try to write my code in a safe way, but language safety just isn't a priority for me. I guess that's why I'm not using Rust. Fighting the borrow checker doesn't seem worth it to me to gain something that's just not that much of a priority. But I'm not writing an OS or a server. I'd think of Rust more like a better Ada or some language where safety is first priority
  - cletus 2y ago
    Story time: Chrome is a Frankenstein of C and C++ code (both directly and through called libraries, static or dynamic). Now C++ has `std::string` obviously. C of course has `const char *`. To facilitate interoperability C++ has various methods to implicitly or explicitly convert between the two. At one point it was found these every keypress on the OmniBar resulted in 25,000 string copies. So my point is that you can write C++ as carefully as you can but on any sufficiently complex code base you'll going to need a pointer to something and then you've really lost all control and safety so the safety in C++ is a bit of an illusion.
    - senkora 2y ago
      Well, that's horrifying. Presumably the value is being copied whenever it is converted from a const char * to a std::string? The right thing (TM) would probably be to refactor some of the std::string's into std::string_view's, for instance by adding overloads where it makes sense. I doubt you could avoid all the copies, but I think you could cut it down substantially if you collected metrics and focused on the most egregious cases. Of course, I do not envy the person who is tasked with doing that, and I could be wrong for any number of arcane technical reasons.
      - dralley 2y ago
        I can only imagine that using std::string_view in a massive, complex application would be horrifying. The borrow checker is one of the benefits of Rust in that case, simply because you can avoid copies while actually being able to trust that you're not opening the door to security & maintenance hell in the process.
- jandrewrogers 2y ago
  I see Rust as neither a C nor C++ replacement, it feels more like a much less limited version of Java. Zig, on the other hand, feels more like a highly evolved C. As a pretty hardcore systems programmer, there are three things that modern C++ has first-class support for that are difficult to live without: metaprogramming, handling cases where ownership is unknowable at compile-time, handling cases where lifetimes are unknowable at compile-time. Rust is still significantly more limited than C++ in what it can express effectively. There are very few features in C++ that are not critical and routinely used in some application domain. A low-key strength of C++ is that it is not overfitted to any particular assumptions about application domain. This adds complexity (aside from complexity introduced by legacy and age) but with the benefit that there is a subset of C++ that is highly specialized for the requirements of almost any application domain.
manchmalscott 2y ago
For me, I found Zig to be really un-ergonomic especially when trying to hack something together quickly. Do I know that printing to stdout could fail? Sure. Do I want to explicitly handle that potential failure every single time I want to print something to the screen? No.
- judofyr 2y ago
  Then add the following and handle it later: … catch @panic("todo") I do it all the time. Lots of @panic during development and then I come back later and handle the error cases separately.
whalesalad 2y ago
Is there actually a compelling reason to use Zig over Rust?
- oconnor663 2y ago
  I only played with Zig for a weekend, so others will need to chime in, but a few points: - Zig's comptime is extremely flexible, while Rust's generics are more constrained. It's not clear if Rust will ever get "specialization" for example, but Zig gets that sort of thing for free by making the whole language available at comptime. - Zig is very explicit about memory allocation, and the standard library doesn't include types like Rust's Vec or String that implicitly talk to a global allocator. If you're writing an application that must not allocate in the render loop / control cycle / etc, that can be a feature. - Zig doesn't have a borrow checker. If your application plans to use memory management strategies like "a bump allocator that frees everything at the end of a frame" or "a bump allocator that frees everything at the end of a query", it can be painful to express the lifetime restrictions of those allocations in Rust. Zig doesn't get in the way of those strategies, though that also means there's no such thing as "safe code" in the Rust sense.
  - trealira 2y ago
    > Zig doesn't have a borrow checker. If your application plans to use memory management strategies like "a bump allocator that frees everything at the end of a frame" or "a bump allocator that frees everything at the end of a query", it can be painful to express the lifetime restrictions of those allocations in Rust. Zig doesn't get in the way of those strategies, though that also means there's no such thing as "safe code" in the Rust sense. I don't use Rust often, so I'm admittedly not that knowledgeable on what's already possible, but does seem like something that could benefit Rust is if there were a way to express in some limited context that something like a doubly-linked list is safe because all its nodes are associated with / owned by the same allocator, and their lifetimes all end when the allocator dies. The rule could be that, within the context of an arena allocator, these arena pointers could point to any memory also allocated by the same arena allocator (including mutable aliasing pointers), but the things they point to could never be moved (or else other arena pointers might dangle) and they wouldn't ever be freed until the "allocator context" ends (or else you might get use-after-free mistakes), and it would have to be within the context of one thread (or else there might be data races). The idea being that all the memory in the arena is allocated at once. Then you could do things like e.g. join two doubly-linked lists that were allocated by the same arena allocator. Then multiple doubly-linked lists could be expressed in safe Rust, as long as they were backed by one arena allocator that deallocates all at once.
oldpersonintx 2y ago
zig is just a temporary resting place for HN language hipsters in four months you will be moving on to Swift6 then either Gleam or Roc, that should take us to 2025 oh look, Mojo hit 1.0, time to make the jump! at that point you will throw your hands up and try Perl
- meindnoch 2y ago
  >in four months you will be moving on to Swift6 How many keywords does the language have at the moment? I churned at @ResultBuilder.
- acomjean 2y ago
  You know, we have a fair amount of older scripts written in various languages. I don’t love Perl, but the fact the language failed to get to version 6 means that these old Perl scripts just keep working.
  - dolmen 2y ago
    Perl 6 exists. It is just called Raku nowadays. https://raku.org/ https://raku.org/
- nkozyra 2y ago
  Pft, I'm already all-in on Odin.
- floxy 2y ago
  I think we are going to circle back to "Modern" Fortran for a while to try out the parallelism features once generics get finalized in the next release. https://github.com/j3-fortran/generics/ https://github.com/j3-fortran/generics/
  - pklausler 2y ago
    When will those generics be available in a portable fashion with multiple compilers?
oconnor663 2y ago
> Perhaps I am still thinking in C too much. > I much would prefer the legacy preprocessor macros C... Holy cow you weren't kidding :)
deleted 2y ago
[deleted]
rychco 2y ago
My current feelings are that I really like Cargo, but don’t enjoy writing Rust. To be honest, if C++ had its own cargo I don’t think I’d ever reach for anything else.
- dijit 2y ago
  To be honest, because Cargo is good it makes me not want to leave it behind for something like Bazel. If Cargo existed, people would not have developed interesting build systems like Meson and Ninja- and especially not Bazel which really leans in to fixing C++'s build issues. In some cases, worse is better.
  - lesuorac 2y ago
    I don't think you can do dependent builds with cargo. Like build a sub-target using say wasm-pack to then embed the output into a binary. IIRC it gets upset because the cargo lock is already acquired or something.
- brink 2y ago
  How long have you been writing Rust?
- dj_gitmo 2y ago
  I have always wondered if it would be possible to write a language agnostic package manager. Lord knows we probably don't need more programming languages, but it would be much easier to get on of the ground if it could just plug itself into an existing package manager.
  - pdimitar 2y ago
    Same here, and I periodically research but remain disappointed; people usually just write a tool to address their current pet peeve and 1-2 years later the tool is of course abandoned. Using just[0] as a task runner has solved a lot of per-project-scripts problems for me but it still cannot do DAG analysis + parallel task running of tasks not blocked on each other (or allow you to opt into serial or parallel task running). So it remains firmly in just the "task runner" territory. I know many people would jump at the opportunity to say "just learn `make`!" but no thanks, I value my sanity. `make` is also inheriting a lot of bash-ism weirdness which makes it even worse. The mage[1] tool that uses `Magefile`-s might be it but it's a bit more verbose (as it's Golang) and I am not sure how well does it integrate with the shell. Maybe script[2] can be used to complement it. Sadly I don't have the time (and lately the inclination) to experiment but there are tools out there and I wish we finally started unifying things. [0] https://github.com/casey/just https://github.com/casey/just [1] https://magefile.org/magefiles/ https://magefile.org/magefiles/ [2] https://github.com/bitfield/script https://github.com/bitfield/script
dathinab 2y ago
This > You still end up chasing SIGSEGVs. and the memory leak part are interesting. The think is if you do very low level stuff with rust, like embedding programming are interacting a lot with C interfaces (or providing them) this is true without question. Similar if you rewrite some of the low level micro optimized parts of a async scheduler like tokio. As a PSA the rust type system and borrow checker even helps with unsafe code as it doesn't remove this checks, just gives you additional tools do to stuff which can undermine them, but (the PSA part) at the same time you have to make sure you uphold the rust safety constraints and memory model (which isn't fully specified yet) which can sometimes mean some things which are fine in C are not fine in rust even if you can do them with unsafe code! But for a lot of the daily work of a lot of rust project you don't really run into segfaults (if you don't do premature micro optimizations or write in a very non rusty stile of using a ton of unnecessary unsafe). Similar memory leakage is limited to stuff like circular Arc/Rc or global collections where you put stuff in but don't remove it. But due to shared long lived ownership (e.g. Rc) being very explicit it happens less often in my experience compared to GCed languages. Anyway that is if you stay in rust, especially safe rust. So I'm not surprised that someone who considers Zig as tooling doesn't have this experience as they are likely having a lot of tasks which involve aspects where rusts type system runs into limitations of how it can help you.
VyseofArcadia 2y ago
I like Zig a lot. It feels like C, it's easy to use C libraries in Zig, and it's more ergonomic and has fewer footguns. As soon as Zig's standard library stabilizes I'll be all over it.
devnull3 2y ago
Any idea how many years away Zig is from v1.0? As someone sold on Rust, I really want Zig to succeed.
- mtndew4brkfst 2y ago
  Is that sentiment for rising-tide reasons, or to help erode the C footprint in industry, something else?
cassepipe 2y ago
Why he is not ready : > comptime feels like a hack, I much would prefer the legacy preprocessor macros C if I can’t have generics. If comptime is a hack, the preprocessor is the king of hacks. > You still end up chasing SIGSEGV Don't the zig compiler in safe mode tell you about it ? Sure it's not as good as preventing a entire class of error but at least you probably get the line in your code where it happens. If you are used to C as you say you are, and if you think Zig's purpose is to work alongside/replace C as you say you think, well, that's not something to be held against zig adoption. > You end up leaking memory But he also says "Of course, Zig has really nice tooling here to catch them quickly, so perhaps not such a big issue." So nothing to see here. All the rest is how zig/its ecosystem/industry/community is not there yet which, of course, it's not 1.0 yet. From the zig website : "Zig is immature. Even with Zig 0.13.0, working on a non-trivial project using Zig will likely require participating in the development process." I don't blame the author but that's not really Hn worthy nor newsworthy
jokoon 2y ago
"I just learned mandarin, I am not yet ready to learn arabic"
bachmeier 2y ago
> I quickly discovered that I really like Zig because it feels like C! I honestly cannot imagine anyone feeling this way. Here's some code randomly pulled from the Zig website: const std = @import("std"); pub fn main() void { const msg = "hello this is dog"; var it = std.mem.tokenize(u8, msg, " "); while (it.next()) |item| { std.debug.print("{s}\n", .{item}); } } That's the kind of code you write with Zig. It's definitely not C. The author probably means something else, but to me the two are very different.
- dralley 2y ago
  "feels like C" and "looks like C" are not quite the same thing. That Zig feels like a modern C is a very common opinion.
  - bachmeier 2y ago
    IMO, only in the sense that many languages feel like a modern C. The differences between C and the Zig code are much more than just syntax.
- jandrewrogers 2y ago
  That's just syntax. Once you get past the syntax, the structure and flow of the language feels like a highly evolved C. Zig has a high degree of mechanical sympathy with C programmer brains.
  - bachmeier 2y ago
    The author wrote "it feels like C". You're saying "the language feels like a highly evolved C". Those are two very different things. I agree with your statement but "highly evolved" implies they're substantially different.
rambojohnson 2y ago
so don't.
seanhunter 2y ago
When I read articles like this I feel compelled to respond in the hope that someone can benefit. So take this however you like but it's a bit of advice from someone who has had a long, fruitful and (at times) happy career in software for nearly 30 years at this point and has programmed professionally at a very serious level in probably nearly 10 languages at this point. Don't worry about which language is the "best" according to the opinions and fashions of the day. Just pick something and go really really deep. If you are lucky enough to stick around in this industry you will inevitably over the course of your career end up programming in a plethora of languages anyway but especially to start with, you will gain a lot from learning how to become a real expert in one thing. Much more than you would gain by flitting from one new hotness to another. For me, I had messed around and done professional work in a bunch of languages but the real turning point came when I decided to really get good at perl[1]. I went through a period where I would go on comp.lang.perl.misc on usenet every day and answer every question I could. Read docs and source code, write little test programs, try things out until I knew and understood the answer. I wouldn't always post my answers because sometimes it took long enough to find the answer that someone else would beat me to the punch, but I got really good at perl in a short space of time. That got me my next two jobs during which time I consolidated that knowledge until I really really really knew perl well (and it's a big language and there is a lot to learn so this is a serious undertaking). The effort involved in doing this - sticking with one thing and learning it really well - has paid off enormously ever since. I have learned and used tons of other languages since then and it is really fast because I really knuckled down and took the time to get good at perl and that taught me a lot about how to learn languages in general. [1] A language I realise as I write this that I have not touched for about 20 years other than to use in shell oneliners when I'm trying to do something in regexes that's a bit too hard to do some other way.
pdimitar 2y ago
I would be interested if somebody also writes "Zig vs. V". I know the latter ate a lot of flak around here but I've been checking it a few times a year and it seems to legitimately make progress. But I won't be trying it myself, sadly my plate is quite full already. Maybe an organization doing something like "Yearly round-up of systems languages" would be hugely beneficial to the community, provided anybody is willing to pick up the torch.

72 points by avinassh 2y ago

I have no issue with the author's points but I just don't see these two as solving the same problem. Zig, to me, is a better C (as the author notes). It seems like it's designed so you can combine easily with a C code base and incrementally migrate it. That's a great application. I'm not expert enough to speak on the merits of comptime (which the author talks about). But isn't comptime somewhat equivalent to constexpr and similar compile-time constructs? Rust, to me, fills a niche as a better C++. Macros are better templates. Compile-time ownership checking is better than a C++ runtime smart pointer. There is legacy in C++ that you can never escape eg someone just calling .get() on your smart pointer and doing God knows what with it. Rust treats memory safety as being of paramount importance and aims to do that with zero runtime cost. That's a great goal but it's also fundamentally different to Zig's goals.

notfed 2y ago
Well said. Though it'd be sorta neat IMO if we could use just one language here, and the memory unsafe aspect could somehow be toggled off or on, gaining all the pros or cons of Zig vs Rust as needed.
- lolinder 2y ago
  Are you thinking of something different than Rust's `unsafe`?
- cletus 2y ago
  What you're talking about here is disabling runtime assertions, which is a common practice in C/C++ (using #define macros). Runtime assertions are strictly inferior to Rust's compile-time assertions because Rust allows you to do a subset of what you can do in C/C++ but it verifies that the memory ownership is correct without a runtime cost, unsafe code notwithstanding). There simply is no way you could do that in C/C++ (and, by extension, Zig) because of the legacy support. I'm fine with having multiple languages. One language to rule them all just tends to mean something is mediocre at everything.
knighthack 2y ago
How is it a "better C" as compared to Go? Genuinely asking.
- Bilal_io 2y ago
  Go is a garbage collected language
- kstrauser 2y ago
  Go is garbage collected. That's a non-starter for a lot of C use cases.
- adrusi 2y ago
  Go has a heavy runtime, including both a garbage collector and a userland scheduler. Those features both make it inappropriate for some applications where you would use c, and also make calling (and especially being called from) foreign code problematic. You effectively cant implement a library in go and then call it from another language, not without considerable ffi overhead at the very least.
- ilrwbwrkhv 2y ago
  Go would be amazing if it didn't allow dumb mistakes such as: type Human struct { Name string MaybeHasCat *Cat } type Cat struct { Name string } func main() { h := Human{} h.MaybeHasCat.Name = "Taffy" } And boom. Null pointer exception because MaybeHasCat is null. The fact that go doesn't let you define an optional type is such a pain. A lot of newcomers while getting trained up fall for this bug. edit: updating to add the pointer i missed. also adding a playground link: https://go.dev/play/p/izcod8xF7ZQ https://go.dev/play/p/izcod8xF7ZQ
  - koeng 2y ago
    That’s not true. Here is a go playground of pretty much that exact code running just fine https://go.dev/play/p/v7OM9s_pRqY https://go.dev/play/p/v7OM9s_pRqY
    - 2y ago
overgard 2y ago
I'm not sure Rust is in the same space as C++, so I'm not sure I'd call it a better C++. I use C++ because I want performance without all the accounting operations that have to happen in C. I try to write my code in a safe way, but language safety just isn't a priority for me. I guess that's why I'm not using Rust. Fighting the borrow checker doesn't seem worth it to me to gain something that's just not that much of a priority. But I'm not writing an OS or a server. I'd think of Rust more like a better Ada or some language where safety is first priority
- cletus 2y ago
  Story time: Chrome is a Frankenstein of C and C++ code (both directly and through called libraries, static or dynamic). Now C++ has `std::string` obviously. C of course has `const char *`. To facilitate interoperability C++ has various methods to implicitly or explicitly convert between the two. At one point it was found these every keypress on the OmniBar resulted in 25,000 string copies. So my point is that you can write C++ as carefully as you can but on any sufficiently complex code base you'll going to need a pointer to something and then you've really lost all control and safety so the safety in C++ is a bit of an illusion.
  - senkora 2y ago
    Well, that's horrifying. Presumably the value is being copied whenever it is converted from a const char * to a std::string? The right thing (TM) would probably be to refactor some of the std::string's into std::string_view's, for instance by adding overloads where it makes sense. I doubt you could avoid all the copies, but I think you could cut it down substantially if you collected metrics and focused on the most egregious cases. Of course, I do not envy the person who is tasked with doing that, and I could be wrong for any number of arcane technical reasons.
    - dralley 2y ago
      I can only imagine that using std::string_view in a massive, complex application would be horrifying. The borrow checker is one of the benefits of Rust in that case, simply because you can avoid copies while actually being able to trust that you're not opening the door to security & maintenance hell in the process.
jandrewrogers 2y ago
I see Rust as neither a C nor C++ replacement, it feels more like a much less limited version of Java. Zig, on the other hand, feels more like a highly evolved C. As a pretty hardcore systems programmer, there are three things that modern C++ has first-class support for that are difficult to live without: metaprogramming, handling cases where ownership is unknowable at compile-time, handling cases where lifetimes are unknowable at compile-time. Rust is still significantly more limited than C++ in what it can express effectively. There are very few features in C++ that are not critical and routinely used in some application domain. A low-key strength of C++ is that it is not overfitted to any particular assumptions about application domain. This adds complexity (aside from complexity introduced by legacy and age) but with the benefit that there is a subset of C++ that is highly specialized for the requirements of almost any application domain.

manchmalscott 2y ago

For me, I found Zig to be really un-ergonomic especially when trying to hack something together quickly. Do I know that printing to stdout could fail? Sure. Do I want to explicitly handle that potential failure every single time I want to print something to the screen? No.

judofyr 2y ago
Then add the following and handle it later: … catch @panic("todo") I do it all the time. Lots of @panic during development and then I come back later and handle the error cases separately.

whalesalad 2y ago

Is there actually a compelling reason to use Zig over Rust?

oconnor663 2y ago
I only played with Zig for a weekend, so others will need to chime in, but a few points: - Zig's comptime is extremely flexible, while Rust's generics are more constrained. It's not clear if Rust will ever get "specialization" for example, but Zig gets that sort of thing for free by making the whole language available at comptime. - Zig is very explicit about memory allocation, and the standard library doesn't include types like Rust's Vec or String that implicitly talk to a global allocator. If you're writing an application that must not allocate in the render loop / control cycle / etc, that can be a feature. - Zig doesn't have a borrow checker. If your application plans to use memory management strategies like "a bump allocator that frees everything at the end of a frame" or "a bump allocator that frees everything at the end of a query", it can be painful to express the lifetime restrictions of those allocations in Rust. Zig doesn't get in the way of those strategies, though that also means there's no such thing as "safe code" in the Rust sense.
- trealira 2y ago
  > Zig doesn't have a borrow checker. If your application plans to use memory management strategies like "a bump allocator that frees everything at the end of a frame" or "a bump allocator that frees everything at the end of a query", it can be painful to express the lifetime restrictions of those allocations in Rust. Zig doesn't get in the way of those strategies, though that also means there's no such thing as "safe code" in the Rust sense. I don't use Rust often, so I'm admittedly not that knowledgeable on what's already possible, but does seem like something that could benefit Rust is if there were a way to express in some limited context that something like a doubly-linked list is safe because all its nodes are associated with / owned by the same allocator, and their lifetimes all end when the allocator dies. The rule could be that, within the context of an arena allocator, these arena pointers could point to any memory also allocated by the same arena allocator (including mutable aliasing pointers), but the things they point to could never be moved (or else other arena pointers might dangle) and they wouldn't ever be freed until the "allocator context" ends (or else you might get use-after-free mistakes), and it would have to be within the context of one thread (or else there might be data races). The idea being that all the memory in the arena is allocated at once. Then you could do things like e.g. join two doubly-linked lists that were allocated by the same arena allocator. Then multiple doubly-linked lists could be expressed in safe Rust, as long as they were backed by one arena allocator that deallocates all at once.

oldpersonintx 2y ago

zig is just a temporary resting place for HN language hipsters in four months you will be moving on to Swift6 then either Gleam or Roc, that should take us to 2025 oh look, Mojo hit 1.0, time to make the jump! at that point you will throw your hands up and try Perl

meindnoch 2y ago
>in four months you will be moving on to Swift6 How many keywords does the language have at the moment? I churned at @ResultBuilder.
acomjean 2y ago
You know, we have a fair amount of older scripts written in various languages. I don’t love Perl, but the fact the language failed to get to version 6 means that these old Perl scripts just keep working.
- dolmen 2y ago
  Perl 6 exists. It is just called Raku nowadays. https://raku.org/ https://raku.org/
nkozyra 2y ago
Pft, I'm already all-in on Odin.
floxy 2y ago
I think we are going to circle back to "Modern" Fortran for a while to try out the parallelism features once generics get finalized in the next release. https://github.com/j3-fortran/generics/ https://github.com/j3-fortran/generics/
- pklausler 2y ago
  When will those generics be available in a portable fashion with multiple compilers?

oconnor663 2y ago

> Perhaps I am still thinking in C too much. > I much would prefer the legacy preprocessor macros C... Holy cow you weren't kidding :)

deleted 2y ago

[deleted]

rychco 2y ago

My current feelings are that I really like Cargo, but don’t enjoy writing Rust. To be honest, if C++ had its own cargo I don’t think I’d ever reach for anything else.

dijit 2y ago
To be honest, because Cargo is good it makes me not want to leave it behind for something like Bazel. If Cargo existed, people would not have developed interesting build systems like Meson and Ninja- and especially not Bazel which really leans in to fixing C++'s build issues. In some cases, worse is better.
- lesuorac 2y ago
  I don't think you can do dependent builds with cargo. Like build a sub-target using say wasm-pack to then embed the output into a binary. IIRC it gets upset because the cargo lock is already acquired or something.
brink 2y ago
How long have you been writing Rust?
dj_gitmo 2y ago
I have always wondered if it would be possible to write a language agnostic package manager. Lord knows we probably don't need more programming languages, but it would be much easier to get on of the ground if it could just plug itself into an existing package manager.
- pdimitar 2y ago
  Same here, and I periodically research but remain disappointed; people usually just write a tool to address their current pet peeve and 1-2 years later the tool is of course abandoned. Using just[0] as a task runner has solved a lot of per-project-scripts problems for me but it still cannot do DAG analysis + parallel task running of tasks not blocked on each other (or allow you to opt into serial or parallel task running). So it remains firmly in just the "task runner" territory. I know many people would jump at the opportunity to say "just learn `make`!" but no thanks, I value my sanity. `make` is also inheriting a lot of bash-ism weirdness which makes it even worse. The mage[1] tool that uses `Magefile`-s might be it but it's a bit more verbose (as it's Golang) and I am not sure how well does it integrate with the shell. Maybe script[2] can be used to complement it. Sadly I don't have the time (and lately the inclination) to experiment but there are tools out there and I wish we finally started unifying things. [0] https://github.com/casey/just https://github.com/casey/just [1] https://magefile.org/magefiles/ https://magefile.org/magefiles/ [2] https://github.com/bitfield/script https://github.com/bitfield/script

dathinab 2y ago

This > You still end up chasing SIGSEGVs. and the memory leak part are interesting. The think is if you do very low level stuff with rust, like embedding programming are interacting a lot with C interfaces (or providing them) this is true without question. Similar if you rewrite some of the low level micro optimized parts of a async scheduler like tokio. As a PSA the rust type system and borrow checker even helps with unsafe code as it doesn't remove this checks, just gives you additional tools do to stuff which can undermine them, but (the PSA part) at the same time you have to make sure you uphold the rust safety constraints and memory model (which isn't fully specified yet) which can sometimes mean some things which are fine in C are not fine in rust even if you can do them with unsafe code! But for a lot of the daily work of a lot of rust project you don't really run into segfaults (if you don't do premature micro optimizations or write in a very non rusty stile of using a ton of unnecessary unsafe). Similar memory leakage is limited to stuff like circular Arc/Rc or global collections where you put stuff in but don't remove it. But due to shared long lived ownership (e.g. Rc) being very explicit it happens less often in my experience compared to GCed languages. Anyway that is if you stay in rust, especially safe rust. So I'm not surprised that someone who considers Zig as tooling doesn't have this experience as they are likely having a lot of tasks which involve aspects where rusts type system runs into limitations of how it can help you.

VyseofArcadia 2y ago

I like Zig a lot. It feels like C, it's easy to use C libraries in Zig, and it's more ergonomic and has fewer footguns. As soon as Zig's standard library stabilizes I'll be all over it.

devnull3 2y ago

Any idea how many years away Zig is from v1.0? As someone sold on Rust, I really want Zig to succeed.

mtndew4brkfst 2y ago
Is that sentiment for rising-tide reasons, or to help erode the C footprint in industry, something else?

cassepipe 2y ago

Why he is not ready : > comptime feels like a hack, I much would prefer the legacy preprocessor macros C if I can’t have generics. If comptime is a hack, the preprocessor is the king of hacks. > You still end up chasing SIGSEGV Don't the zig compiler in safe mode tell you about it ? Sure it's not as good as preventing a entire class of error but at least you probably get the line in your code where it happens. If you are used to C as you say you are, and if you think Zig's purpose is to work alongside/replace C as you say you think, well, that's not something to be held against zig adoption. > You end up leaking memory But he also says "Of course, Zig has really nice tooling here to catch them quickly, so perhaps not such a big issue." So nothing to see here. All the rest is how zig/its ecosystem/industry/community is not there yet which, of course, it's not 1.0 yet. From the zig website : "Zig is immature. Even with Zig 0.13.0, working on a non-trivial project using Zig will likely require participating in the development process." I don't blame the author but that's not really Hn worthy nor newsworthy

jokoon 2y ago

"I just learned mandarin, I am not yet ready to learn arabic"

bachmeier 2y ago

> I quickly discovered that I really like Zig because it feels like C! I honestly cannot imagine anyone feeling this way. Here's some code randomly pulled from the Zig website: const std = @import("std"); pub fn main() void { const msg = "hello this is dog"; var it = std.mem.tokenize(u8, msg, " "); while (it.next()) |item| { std.debug.print("{s}\n", .{item}); } } That's the kind of code you write with Zig. It's definitely not C. The author probably means something else, but to me the two are very different.

dralley 2y ago
"feels like C" and "looks like C" are not quite the same thing. That Zig feels like a modern C is a very common opinion.
- bachmeier 2y ago
  IMO, only in the sense that many languages feel like a modern C. The differences between C and the Zig code are much more than just syntax.
jandrewrogers 2y ago
That's just syntax. Once you get past the syntax, the structure and flow of the language feels like a highly evolved C. Zig has a high degree of mechanical sympathy with C programmer brains.
- bachmeier 2y ago
  The author wrote "it feels like C". You're saying "the language feels like a highly evolved C". Those are two very different things. I agree with your statement but "highly evolved" implies they're substantially different.

rambojohnson 2y ago

so don't.

seanhunter 2y ago

When I read articles like this I feel compelled to respond in the hope that someone can benefit. So take this however you like but it's a bit of advice from someone who has had a long, fruitful and (at times) happy career in software for nearly 30 years at this point and has programmed professionally at a very serious level in probably nearly 10 languages at this point. Don't worry about which language is the "best" according to the opinions and fashions of the day. Just pick something and go really really deep. If you are lucky enough to stick around in this industry you will inevitably over the course of your career end up programming in a plethora of languages anyway but especially to start with, you will gain a lot from learning how to become a real expert in one thing. Much more than you would gain by flitting from one new hotness to another. For me, I had messed around and done professional work in a bunch of languages but the real turning point came when I decided to really get good at perl[1]. I went through a period where I would go on comp.lang.perl.misc on usenet every day and answer every question I could. Read docs and source code, write little test programs, try things out until I knew and understood the answer. I wouldn't always post my answers because sometimes it took long enough to find the answer that someone else would beat me to the punch, but I got really good at perl in a short space of time. That got me my next two jobs during which time I consolidated that knowledge until I really really really knew perl well (and it's a big language and there is a lot to learn so this is a serious undertaking). The effort involved in doing this - sticking with one thing and learning it really well - has paid off enormously ever since. I have learned and used tons of other languages since then and it is really fast because I really knuckled down and took the time to get good at perl and that taught me a lot about how to learn languages in general. [1] A language I realise as I write this that I have not touched for about 20 years other than to use in shell oneliners when I'm trying to do something in regexes that's a bit too hard to do some other way.

pdimitar 2y ago

I would be interested if somebody also writes "Zig vs. V". I know the latter ate a lot of flak around here but I've been checking it a few times a year and it seems to legitimately make progress. But I won't be trying it myself, sadly my plate is quite full already. Maybe an organization doing something like "Yearly round-up of systems languages" would be hugely beneficial to the community, provided anybody is willing to pick up the torch.