i2talics

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

Why are we both-sidesing this and blaming the poll aggregators when they are the ones that successfully rooted out the fake poll data?

I think a big problem is that, as a poll aggregator, the more you pick and choose which polls are allowed to be aggregated, the more risk there is that you are inserting bias into the result through selective exclusion. Erring on the side of broadly accepting poll data means less room for bias. But they do talk about the need to raise their standards due to the increasing ease of producing fake data in this podcast with FiftyPlusOne: https://www.youtube.com/watch?v=Neuot3aMkrY

> 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.

Terminological nitpick, but soundness is a property of an entire type system not of an individual program. A type system is sound if it only accepts valid programs. A program is valid if it never exhibits undefined behavior.

Rice's theorem implies that it's impossible to precisely distinguish valid and invalid programs just by looking at their source code. Thus Rust rejects some valid programs in order to be sound (e.g. "if false { None.unwrap_unchecked() }").

In the case of the bug report in OP, I don't think that there are many valid programs in practice that exploit this soundness issue, so fixing it just means rejecting more invalid programs.

In the Rust ecosystem, the "0" in a "0.x" semver means very little :) Lots of widely used and stable projects version themselves like this indefinitely.

I have been learning Bevy for fun lately, it's been a blast. They have been introducing breaking changes left and right but I think its in the service of addressing important things. It's probably too immature to stake a real commercial product on it at the moment, and I'm saying that as the kind of person who is attracted to a cool architecture rather than the pragmatics of shipping.

Lol, what a pathetic attempt to garner sympathy. I like how he is constantly harping about how they never predicted the crazy jump in capabilities and then tries to defend the "safety researchers" like this:

> First, the safety researcher perspective. These folks work tirelessly to evaluate model capabilities and the dangers they pose as they advance at an alarming pace. They understand fundamentally better than nearly anyone else how models are able to interpret their environment, reason, and solve problems. They study models as they try and deceive their graders, evade chain-of-thought monitoring, and do all sorts of crazy stuff. These researchers are continuously stress testing the models to determine why and how they behave the way they do, and are working vey hard to make tangible progress in aligning their interests with ours. Many of these researchers have formal backgrounds in these types of networks, with expertise that takes many years to develop. However, a lot of safety researchers, even ones that I respect enormously, have never been in a real incident, don’t understand security vulnerabilities, or really know how to break a system. That’s okay. That is not their background. But safety has direct overlap with security, and so it does pose a problem.

Wow. This just makes them appear incredibly incompetent.

IMO: The inability to prosecute OpenAI for these things is proof that the AI industry is already "too big to fail". Why didn't HuggingFace try to seek legal liability against OpenAI when it had explicit confirmation that they had been hacked? Because HF understands that it needs OAI and the rest of the AI industry to continue to exist and be in good legal standing, for the interest of HF's own self preservation. This is what it means for something to be too big to fail.

I have had the suspicion for a while now, that any attempted discussions about the merits of C's design that try to connect this to its success, are missing a massive part of the picture if they don't mention UNIX.

We don't make this mistake about JavaScript; nobody tries to argue that the confusing semantics of the "var" keyword or the "==" operator somehow were actually instrumental to its success. It's obvious that JavaScript won because it was what was on the web. Maybe C is not much different.

It would be hilarious if this was generated by a markov chain or something so it would infinitely scroll. Infinite Claude.

I'm a security noob, but side channel attacks seem to me like something that you fundamentally just can't address by writing better software in a high-level language. The entire point is that they dig underneath all of your abstractions. It doesn't seem particularly tenable to keep playing whack-a-mole in this way.

You are misled for two reasons.

First of all, Rust isn't subject to the same soundness issue as Java precisely because of the Rust's ownership semantics. You can't produce the ArrayStoreException issue because you can't mutably alias a Vec in the first place. To be more precise, &mut T is invariant, but Vec<T> is covariant (in T).

Second of all, Rust already does classify the co/contravariant status of all of type parameters. If you've ever tried to omit a type parameter from the fields of a struct and find that you're forced to insert a "PhantomData" value, this is because the entire purpose of PhantomData is to imply what variance classification the compiler should give the type parameter.

Meh, I don't really trust TIOBE. It's at best a very noisy signal. And languages can end up on there for unusual reasons.

Hah, I remember error_chain. One of my projects during an internship was upgrading a bunch of the old error handling libraries to the new things. I'm glad that corner of the ecosystem has stabilized now.

At that same job we hit a pretty nasty breaking change where mem::uninitialized() was deprecated and this turned out to cause a lot of critical async libraries to explode at runtime. But these sorts of things don't really happen anymore. The editions system is an excellent design and a big contributor to making the language and stdlib reliable.

I hope announcements like this show that Rust is not a fledgling little language that moves fast and breaks things anymore. It's a mature, serious competitor to well established languages like C++ and C#. This is particularly important when trying to compare the experience of using Rust to other languages in the "better C/C++" space like Zig and Odin -- these are much newer and have more rough edges than Rust.