i2talics

Most compilers will be able to optimize the index version into this.

> If you don't like arenas then that will push you towards avoiding allocations

I mean push in the sense of a pit-of-success, not making me do things because the alternative is unpalatable.

> managing frees one-to-one with allocations is a nightmare

It really isn't a nightmare if your language has tools to help you. I'm never particularly concerned about frees in Rust outside of thinking about room to optimize.

> Need something to live across connections? Use the general purpose allocator for those particular things.

Well, this is a determination you have to make very carefully and if you screw it up (like in the situation I was trying to outline) you have a subtle bug.

> Personally I mostly lean on fixed-size buffers, but if I'm writing Zig it's just little toy programs where blowing up when the buffer runs out of room is fine.

What's also fine is using malloc, which will have perfectly reasonable performance for your toy programs.

This is reinforcing my belief that Zig programmers actually just have a sort of aesthetic attachment to the idea of managing their allocations themselves and this has very little to do with the actual practical concerns of writing software that works. I'm a lot more sympathetic to the other reply that talked about library code improving flexibility for those relying on the library, than this comment that only thinks about the case where everything goes perfectly and using a fixed size buffer for no reason.

Why does everyone love being able to control the allocator in Zig? I rarely want this low level control over the allocator, I would rather have an easy to use interface to malloc/free (such as RAII) or would prefer the language push me to avoiding allocations when unnecessary. C and Zig users are always talking about how arena allocators are easier to use than the alternative but I disagree because the alternative is extremely easy to use when the language makes it so.

Arenas have a lot of footguns like growing out of control if you don't have space in your logic to delete them (e.g. suppose every new HTTP connection required obtaining a new allocation from the primary arena -- now you have a memory leak). They also aren't necessarily faster than malloc: I remember hearing a case where mimalloc was faster than an arena for a one-shot program like a linker because reclaiming space improved cache locality. Plus it's difficult to implement things like growable vectors or hashmaps using an arena without wasting space.

I just don't see how "futz about with the allocator constantly" and "use an arena" is actually a good default.

OK, so everyone in the replies is saying "yeah duh", but a few years ago people used to defend the negative externalities of LLM's by pointing to medical applications and saying "but think of how useful they would be for doing a cancer diagnosis"

It's a double edged sword because without #[non_exhaustive], adding a variant becomes a major semver breaking change. It depends on your priorities. I think that there is probably a subtle difference between enums that are expected to gain variants in minor releases (a common example is error types) and enums that are expected to be closed (something like Option or SocketAddr).

Honestly what I tend to see is that most enums are not exposed publicly at all besides maybe error types and configuration options (where the user usually constructs but does not match on them). In both cases #[non_exhaustive] is valid. For all of the non-public enums you get to enjoy the compiler exhaustiveness enforcement.

This sounds a lot like a builder but the line can be blurry. For a Rust stdlib example, the `process::Command` type is considered a builder even though it is not named "CommandBuilder", and the final operation is spawning a subprocess, not returning some other data.

I think using refcounting can allow you to get lazy with your object graphs, throwing referencing to objects around everywhere and then losing the ability to conceptualize who owns what and who is responsible for who (so to speak). Sticking to a stricter ownership graph forces you to be more deliberate with how your types are designed and this can lead to better architecture in the long run.

Their style is pervasive in Rust, such as in the standard library, so I would personally apply a when-in-rome philosophy. FWIW something like `.text("hello")` I would expect to see in a builder-pattern but not in a setter for an object that's already built.

That being said I don't particularly understand your conception of a method. They are both methods. The getter ought to have a shorter name since it is probably called more frequently and because it inherently has less of an impact -- this goes along with the principle that names that demand attention should be larger and easier to notice.

The granularity of crates shouldn't really impact what kinds of abstractions you build. You can still have as many modules and types as you need, and as big of functions as you need, but its saying you should organize the modules into separate crates instead of one large crate. They even call out the trait coherence rules, saying that you can just make your library bigger instead of forcing a more awkward design in the pursuit of a smaller crate.

I think one benefit of small crates is that it gives you more granularity in linking and dependency graphs, which is especially relevant for rebuilds. At a previous job we had a monolithic "utilities" crate, and this caused problems when you tried to depend on it for the IP address utilities but this brought in the radio frequency utilities. When one of these submodules got an update the versioning would excessively propagate downstream to every consumer. If this was organized as small "net-utils" and "rf-utils" crates then maybe it would not have been as much of an issue.

Much of this is very standard across the Rust ecosystem but it's very helpful to have it all in one place.

I don't even disagree with your distaste for monads but it has nothing to do with the actual comment I made.

I've long suspected that one of the things that makes monads notoriously difficult to explain to people outside of the Haskell ecosystem is that very few other languages even have a kind system that you are allowed to manipulate in code (and in some, like C++, it's so esoteric that you basically never see it). First explaining that you can even abstract over "type->type" kinded things gets you a lot of the way towards monads without actually describing monads.

I don't get the impression that these are meant to influence optimization at all.

The tricky thing about formalization is that you usually have to reimplement the type checker into a proof assistant in order to do formal soundness proofs. It's not necessarily clear that this reimplementation is identical to the actual Rust compiler (in fact, you often have to massively simplify the type system to make the proofs tractable), so bugs in implementation can cause unsoundness without being related to fundamental flaws in the soundness of the type system.