We've been hearing this theory since Rust was a much smaller percentage of the total responses. With an order of magnitude more developers using the language, you'd expect this high "loved" rating to have slipped considerably, at least behind less commonly used languages, but it hasn't. So I no longer really buy this theory; I think it's centered in the idea that real improvements to programming languages aren't possible, and familiarity / enthusiasm trumps everything.
Nice goal post moving. So which imaginary language with affine types are you referring to? Being specialized doesn't automatically mean being industrial strength or usable.
I don't need to be a mind reader because I know which languages other than Rust support sound affine types. They broadly fall into three categories:
* Languages with comprehensive support for affine types, but that are otherwise too limited to be really useful for general purpose programming. Usually this is due to a lack of industry support.
* Languages with bolted on support for affine types where you can't get consistent performance benefits out of code written in that style and it's very difficult to write and compose code written in that style.
* Complex languages with advanced type systems that can emulate affine types, and are extremely powerful, but are borderline unusable for any purpose.
Like I said, whichever of those three language categories you're thinking of, my reasoning applies. No mind reading necessary! I understand though that you believe safe concurrency has been solved since Modula 3 because you can just lock every object while it's in use (why didn't anyone else think of that?), so maybe you don't really appreciate the vast gulf in usability between affine types in these kinds of languages and in Rust.
None of the other languages you're thinking of are particularly usable as industrial strength languages for general purpose programming, for reasons that go way beyond mindshare.
Reference counting is not faster than tracing GC for general purpose workloads, at least not without a lot of extensive tuning that includes stuff like using tracing and moving GC for the young generation (prior to the first collection), deferring reference count increment/decrements using write barriers, limiting reference count bits (and reclaiming stuck objects with some variant of full heap tracing), and so on. Many of these benefits cannot be effectively realized if you insist on prompt execution of finalizers, either. Languages like Rust and C++ gain their performance benefits not from using reference counting or immediate reclamation, but from avoiding creating garbage in the first place by stack allocating most stuff, creating large objects by-value and within vectors to reduce pointer chasing, using direct interior references into data structures in ways that it would be difficult to trace efficiently, and using data structures like arenas to emulate the benefits of generational GC in controlled contexts where a maximum lifetime can be statically determined.
My personal feeling is that it's very hard to directly compare manual memory management and GC from a performance perspective because so many of the techniques that make tracing fast involve moving pointers, which is very costly to combine with many of the techniques that make manual memory management fast which rely on values not moving in memory. I think any such solution that is efficient for both kinds of memory will probably require the programmer to have very tight control over when the garbage collector can execute, whether pointers can move at particular times, etc., and the complexity of maintaining that kind of control (and getting it right!) seems so high that I'm not sure it would ever be usable for general purpose programming.
Sure. As was obvious from the beginning for anyone who's tried to do lifetime analysis on mostly-unannotated C++, this is going to become another "bug reporting" tool that doesn't accomplish anything close to what Rust does. Most likely, all it will do is catch a few of the more obvious bugs so they pass various tutorial examples people use to show why you need borrow checking, leading C++ programmers will believe the problem is solved when it isn't.
It "offers" thread safety in the sense that it's theoretically possible to write a thread safe program in C++. It certainly makes it about as difficult as humanly possible to do so, however, especially when they include stuff like the consume ordering that isn't even well-defined.
The Android study had a control: they compared to memory safety vulnerabilities in other greenfield projects written in modern C++. There was no significant improvement for the greenfield projects, even though they also benefited from improvements to static analysis. The improvements were reserved for Android, which had a large share of its new sensitive code written in Rust.
That's not the main Binance organization. They have various silos (like Bifinity and Binance USA) that are registered and claim to be siloed from the other organization, but even a little bit of research makes it clear that they're not actually separate organizations. Binance US is under investigation for things like KYC/AML avoidance and money laundering...
> Bifinity, whose annual report said it has 147 employees, does not have a website or publicly provide any contact details. The company's chief executive, Saulius Galatiltis, did not respond to requests for comment. At its registered address at a business centre in Lithuania's capital Vilnius, Bifinity is not listed on the tenants' board.
This is not the first time a Binance organization has claimed to be filing from / regulated in a particular country or location, but when anyone actually tries to look into it there's nobody there or the registration was withdrawn.
All of this sounds, to put it bluntly, like a lot of hemming and hawing to get around the fact that your favorite charity organization just spent $15 million on a castle.
From a marketing perspective, I can assure you that effective altruism does itself absolutely no favors by blatantly betraying its supposed core principles.
Jikes is the one I'm most familiar with and people working on its runtime absolutely suffered from UB and memory corruption issues... obviously not throughout the whole standard library but that's not the case for other JVMs either. In fact the Jikes people found it nicer to work in Rust than in Java on components like the garbage collector, because it was a better fit for working safely with this kind of code and they didn't have to write in a restricted subset of the language to avoid triggering the GC.
This is a misunderstanding of what's useful about aliasing information. A lot of C code can't be autovectorized because it can't tell that accesses to two arrays don't alias, for example. Similarly it often can't reorder / eliminate redundant updates to arrays because it can't tell they're not aliased. These aren't related to bounds checking specifically but they are things that can improve performance in Rust over C (theoretically, anyway; in practice LLVM is still very much tuned for C so it doesn't take advantage of a lot of this stuff yet, but it likely will in the future).
At least two of which use an unsafe dialect of Java for significant parts of the runtime, which I'm pretty sure you know well (maybe not Graal, but if not it's because it's bootstrapping on top of existing unsafe code).
Unsafe accesses do not act that way, they compile to exactly the same code as array accesses in C.
The tests aren't bunk. There are a variety of reasons why the assertions generated by array index checks can be useful for LLVM, and there is also a fair amount of noise in any end to end test like this. The main point is that it clearly isn't a primary bottleneck (which should be pretty obvious in a test that takes 30 ms and performs under 2000 bounds checks).
The project could, yes. It wouldn't necessarily change the legality of using it in non-GPL projects, though. If people were only using it in license-compatible projects and it was license-compatible with GPL, I doubt anyone would have any complaints (even though in theory it could also be picking up stuff from other incompatible licenses).
I know people who refuse to use async_trait for documentation reasons alone. The macro-based solutions aren't always pleasant to use and often come with a lot of weird tradeoffs. And yeah, I agree that most users don't need to write theme explicitly--I'm arguing that users are currently significantly impacted by the lack of them, even if they are never in a position where they'd consider writing them themselves, because it prevents library authors from writing precise APIs. For example, you might not be wanting to write GATs like the Hyper authors, but anyone using Hyper for anything nontrivial (and that's surprisingly common, IME) is certainly negatively impacted by the massive complexity caused by needing to work around their absence.
It's needed for a lot of features people desperately want. Async functions in traits, closures that return futures where you need to run the future in a loop, and array indexing that doesn't necessarily return a reference, are three examples of things that essentially need GATs in order to be implemented without allocating. You may not feel like you missed it but not having that leads to a ton of ugly workarounds in Rust code. Also, in a lot of cases where people would otherwise use GATs, people instead work around them by making traits generic and have super complicated towers of generic types, you've probably seen interfaces like this when using hyper for instance. GATs would simplify most of those interfaces.
This does not really answer anything. As far as we can tell (modulo the precision of our instruments), it's likely there are many, many stars like our sun and planets like Earth, even if they are not in the majority. It also seems like life sprang up almost immediately after the Earth cooled enough for it to be feasible.
It's not really a hit piece and I think he does a good job of arguing that high performance chips are not all that simple anyway anymore regardless of ISA.
Interesting, didn't realize that. This explains some of the weirder present queue requirements, I guess (it doesn't really act like a regular queue). So maybe you really can power down the GPU. I still doubt it would be lower power overall, since IME my M1 GPU takes very little power when I'm not using it intensively, but it's at least possible.