remexre

How would you recommend doing that sort of "subtyping"? _Generic and macros?

Once I check if an Option/optional/Maybe is none, I can extract the value and just pass around the value, so other functions I call know that the value cannot be null.

This does not work well for FILE in C, for instance.

Being out-of-tree means that kernel refactors break ZFS, and that it has a lot fewer hands and eyeballs available for the kinds of bugs that require internal design changes to fix (rather than paper over).

Will this include some form of SLIME support?

Okay, thanks!

Could you check what version of DWARF it covers?

They're hydraulically powered, not electrically; no outlet required, the same water intake that the jet uses is used for the mechanism as well.

It's when existing implementations' inflexibility prevent protocol evolution.

https://en.wikipedia.org/wiki/Protocol_ossification

Idiomatic design would be a big one; there are a lot of ways to design a program in a higher-level OO language that, if followed in C, will lead to a program with lots of bugs around error handling and resource cleanup.

This kind of ties into the argument made by some in the Rust community that "the ownership was there the whole time" -- in a language without automatic memory management, you really do need to be aware of the life-cycle of an object in memory. Rust's specific rules aren't fundamental, but "even when an error occurs, I know what cleans up this object / this state" is.

I think it's fair to say that having some sort of syntactically lightweight sum or union type facility makes this way nicer than anything Java ever had -- subclassing isn't really a solution, because you often want something like:

    type FooError = YoureHoldingItWrong | FileError
    type BarError = YoureHoldingItWrong | NetworkError
    fn foo() -> Result<int, FooError> { ... }
    fn bar() -> Result<int, BarError> { ... }
    fn baz() -> Result<String, BarError> { ... }

TypeScript's type system would hypothetically make this pretty nice if there were a common Result type with compiler support.

Rust needs a bit more boilerplate to declare FooError, but the ? syntax automatically calling into(), and into() being free to rearrange errors it bubbles up really help a lot too.

The big problem with Java's checked exceptions was that you need to list all the exceptions on every function, every time.

Nix(OS) is aware of namespaces, and can use them (in fact, the aforementioned gaming support relies on them), but versioning packages still works better than versioning the system in most cases.

Consider three packages, A, B, and C. B has two versions, A and C have one.

- A-1.0.0 depends on B-2.0.0 and C-1.0.0. - C-1.0.0 depends on B-1.0.0.

If A gets a path to a file in B-2.0.0 and wants to share it with C (for example, C might provide binaries it can run on files, or C might be a daemon), it needs C to be in a mount namespace with B-2.0.0. However, without Nix-store-like directory structure, mounting B-2.0.0's files will overwrite B-1.0.0's, so C may fail to start or misbehave.

> A local minimum is [...]

Unless you're in ML, in which case it's a minimum of the loss function, not the utility function...

Making the _compiler itself_ provide an API enables things like LSP, which don't want to generate machine code at all. A traditional single-pass compiler usually can't accommodate this without re-plumbing.

Many universities that use OCaml in upper-division courses also use it in lower-division; my university requires all CS majors to take a course that is taught in OCaml, and covers higher-order programming, "advanced" (Hindley-Milner) type systems, equational reasoning, etc., typically in their sophomore year.

The compilers class can then be taught in it without worrying about that problem much.

Isn't that way either JIT or boxed integers?

arity as in "number of generic arguments," I think they meant.

Imagine a calculator that computes definite integrals, but gives non-sensical results on non-smooth functions for whatever reason (i.e., not an error, but an incorrect but otherwise well-formed answer).

If there were a large number of people who didn't quite understand what it meant for a function to be continuous, let alone smooth, who were using such a calculator, I think you'd see similar issues to the ones that are identified with LLM usage: a large number of students wouldn't learn how to compute definite or indefinite integrals, and likely wouldn't have an intuitive understanding of smoothness or continuity either.

I think we don't see these problems with calculators because the "entry-level" ones don't have support for calculus-related functionality, and because people aren't taught how to arrange the problems that you need calculus to solve until after they've given some amount of calculus-related intuition. These conditions obviously aren't the case for LLMs.

It would be very normal for a compiler to do an increment (or merge it into a later instruction), but never do the decrement, and instead use the old copy of the value.

64KiB also happens to be the largest minimum page size you can configure reasonably common hardware to have (not that this is a common configuration).

I'm essentially comfortable with the government knowing what banks I've banked at, what homes I've lived in, and where and when I've been arrested. I'm much less comfortable with those being in a public database anyone can query.

Maybe the "allocate as little as possible, use sun.misc.Unsafe a lot, have lots of long-lived global arrays" style of Java programming some high-performance Java programs use would get close to being a good stand-in.

The first reasonable concern that springs to mind is that correlating a few fields that are individually non-identifying in a dataset can lead to deanonymizing people; in principle, the FOIA process gives the organization being requested time to think about what needs to be masked to protect privacy.

Do you have a "benchmark program" for performance and results for it? (e.g. I like to wall-clock measure a clean build of LLVM to approximate the performance on the compute-heavy workloads I run often.)

It'd be interesting to see a benchmark for what the total overhead is for Rust->WASM->Chicory AoT->native-image versus native Rust; I've been pleasantly surprised by the JVM in the past, so I'd hope it'd be a relatively small hit.

Though, the algorithm might plausibly evolve it if it were trained in a more hostile environment.

That's still based on optimism (i.e., needs to be adjusted for risk), though; if the technology will massively increase productivity, the ratio should correct once those benefits start to be realized.

It seems like "many market participants are mis-estimating risk" is exactly the sort of thing that this metric is intended to measure.

Shouldn't those things increase GDP as well?

I suspect gcc-rs will be in good working order for a few years before any kernel subsystems require a Rust compiler to build; if the legacy system can't run a recent GCC, why does it need a much-newer kernel? (e.g., how would it cope with the kernel requiring an additional GCC extension, bumping the minimum standard version of C, etc.)

I honestly suspect new architectures will be supported in LLVM before GCC nowadays; most companies are far more comfortable working with a non-GPL toolchain, and IMHO LLVM's internals are better-documented (though I've never added a new target).

Imports?

Aren't they calling C++ functions via LLVM? Their implementation language shouldn't affect their ability to _generate_ code that uses the C++ ABI.