Isn't Zig's repetitive ceremonial code around allocators+ allocation + defer *.deinit() a sign of a serious shortcoming like golang's error handling? If zig is so good at metaprogramming, why isn't there a metaprogramming solution to this repetitive code?
Memory allocations are always done explicitly (nothing is hidden or implicit). I've not written enough Zig yet to appreciate that, but I've hit plenty of those issues year-after-year with C++ to know their approach is sane and rational.
That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust. Rust recognizes allocations on a language basis, but does not provide the same level of control over allocations on a language basis as Zig does. For instance, there is no stable interface for custom allocators for alloc/std.
std may not yet provide a stable interface for custom allocators (the Allocator API appears to be available in unstable presently), but use of custom allocators is common in no-std rust environments like embedded. Reading through https://github.com/irbull/custom_allocators the Allocator API doesn't seem particularly complicated. I think it's fair to expect that it will stabilize in time.
> That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust.
Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required. But if your application might benefit from GC, it's certainly available in the language. I might say "GC is optionally available in Rust if desired" to be more accurate.
> I think it's fair to expect that it will stabilize in time.
The allocator work is facing a lot of obstacles, unfortunately. I prefer it to be unstable for as long as it needs, though.
> Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required.
This is exactly my point. Rust does not prevent GC by any means, but Rust also does not encourage GC by any means. The same goes for custom allocators, aside from the highly-unstable Allocator API.
> The allocator work is facing a lot of obstacles, unfortunately.
Got any links? Sounds like interesting reading. Seriously. Kind of thing I come here for. I'd really appreciate it. Or I can ask the AI for some.
> I prefer it to be unstable for as long as it needs, though.
Sure, same. Fully baking things is a process, and it's nice when things are fully baked. So I agree. I think Rust's async could be a bit more ergonomic, though it wasn't too difficult to wrap my head around, and sort of shockingly simple to implement a basic no-std async executor (~10 lines), so maybe I'm coming around. I was pleased to find out that it was simple enough that I could do it, and understand how it worked, as I try to do with all my microcontroller code, and wasn't dependent on a big async runtime like Tokio if I didn't need it's features (or bloat).
No, it isn't. Because that distinction is significant if you are using the language in an environment where those libraries are not available or suitable, such as the Linux project which uses a custom fork of Alloc which provides collections for different allocators.
So, that is not done at the language level but the library level. Unless the compiler is modified for Linux, but even if it is, that's entirely bespoke and unstable. This is not comparable to Zig's design. I'm aware that anything can be done if the right things are implemented; I'm talking about what Rust-the-language currently does for control over allocation. If the answer comes down to "we're doing something custom", then the language is soewhat or largely sidestepped. C-the-language certainly doesn't have panics or exceptions, even though longjmp or a custom runtime could be used.
For the time being, I consider alloc and std to be part of the language, and the compiler also has provisions for them if they are used. If the alternative is supposed to be only using core, then the language does not provide for control over allocations the way Zig does. Imposing allocations with no control and not providing allocations at all are both failure modes. With enough effort, anyone could do anything, but programming languages exist to control and enhance certain things under their purview. Rust does not have a comparable facility to control allocations like it controls ownership and borrowing. Just as C-with-tooling being safe isn't the same as C being safe, Rust-with-libraries providing control over allocations isn't the same as Rust providing control over allocations.
Or Microsoft could simply fund open source software since they provide a Linux subsystem to allow people to do proper work despite of them having to use windows
Netsurf isn't fun on many websites but it should be enough for rendering HTML content from RSS, no? Terminal emulators and lynx/elinks/links/w3c work, too. And terminal RSS readers. HTML rendering is also possible with KOreader which runs well on rM2, come to think about it.
Just in case someone reads this far and sees blubber's confident "No." Blubber is definitely wrong here. I used to do all of my programming in R. Throw the question into an LLM if you're wondering if R has a package like ___ in python.
I know people who used Visual Basic for all of their programming. I'd say No either way unless people explained to me without bursting out into laughter that they also have extensive experience with, e.g., Kotlin, Rust, C#, Java etc. and still prefer VB or R for non-trivial programs.
Of course R isn't a complied language and probably not the same category as C/Rust as systems language but is not in the same category as VB. R is a serious scientific programming language used in non-trivial programs for industrial applications. See Posit's customers. I suggest John Chambers ( https://en.wikipedia.org/wiki/John_Chambers_(statistician) ) book, he explain how he designed S language, R's grandfather so to speak, Software for Data Analysis ( https://link.springer.com/book/10.1007/978-0-387-75936-4 ).
This isn't about compilation vs interpretation. R is simply badly designed as a programming language. This doesn't change just because its inventor wrote a book.
blubber, I think there might be some misconceptions. Just for the record.
R is not actually competing with those languages. R's design purpose is different. it is a general purpose computational language for scientists. There are FFIs (Foreign Function Interfaces) for all those languages.
"The reason you can use this simpler syntax in R is because it’s non-standard-evaluation ..."
So it actually is about Python vs R.
That said, while this kind of non-standard evaluation is nice when working interactively on the command line, I don't think it's that relevant when writing code for more elaborated analyses. In that context, I'd actually see this as a disadvantage of R because you suddenly have to jump through loops to make trivial things work with that non-standard evaluation.
The increasing prevalence of non-standard evaluation in R packages was one of the major reasons I switched from R to python for my work. The amount of ceremony and constant API changes just to have something as an argument in a function drove me mad.
Yeah, this was so very very painful. I once ended up maintaining a library that basically used all the different NSE approaches, which was not very much fun at all.
reply