I don't quite follow the algorithm here, but I'm not sure the `gensym` Rust implementation works as expected. `RefCell::clone` does not return a copy of the reference; it returns a new `RefCell` with the current `RefCell`'s value, resulting in duplicate IDs. However, a `RefCell` isn't even necessary here, since a `Cell` would do just fine - and you'd pass around a reference to that `Cell` instead of cloning it.
It does feel like the code was ported as-is to Rust, and only adjusted slightly to compile; there are going to be pain points as a result of this process. I suspect this is the source of some of the author's complaints, especially given:
> Although it provides us with a greater sense of how the code is executing, it brings very little value to the algorithm itself.
Rust is, in general, for people who find value in having that information; it is okay to not want to have to worry about ownership, borrowing, safety, etc., but it seems a bit odd to complain about this when that's what Rust is for? If you want to focus on just the algorithm, and not how it's executing, then OCaml is definitely a valid choice.
However, the point about GADTs - can Rust's recently-stabilized GATs not work in the same way? Though I will admit that Rust's GATs don't seem nearly as powerful as OCaml's GADTs in this regard.
> it seems a bit odd to complain about this when that's what Rust is for
that's the point of the article - rust gives you a lot of low-level control, but if you don't actually need that control then you're paying the cost in ergonomics for nothing.
Exactly. I did get the impression that the author is more familiar with OCaml than Rust. However I don't think they were claiming Rust's greater low-level control makes it inferior to OCaml in general. They're just saying it makes it less suitable for writing compilers, since (in the author's opinion) this level of low-level control isn't necessary for that task.
Something tangentially related, but something I'm unaware of - if I do run into an ICE on nightly, what is the current process for reporting that? I've run into one or two before (and I've generally assumed it was me doing something dumb with the environment, and I couldn't replicate it), but I wouldn't mind trying to report them in the future.
I've used diesel async for personal projects, and while it does work seamlessly with diesel at times, there are some rough edges - I ran into an odd issue where the order of imports from the base diesel package and diesel async mattered, and it would compile with one above the other, but not the other way around.
Now, I'm not a lawyer, so this isn't legal advice, but...
A derivative work is not fair use. If you end up with a significant portion of another person's program in yours, (such that a substantial portion of your program is in some way related to their program), that will likely be a derivative work - but the definition of a derivative work depends on your jurisdiction and use-case. If you're unlawfully using the source material to produce a derivative work, you cannot copyright that derivative work under 17 U.S.C. § 103(a), and under the same section, you can only copyright your modifications, not the original.
It would be hard to argue fair use in this case; fair use only really applies for parodies/criticism, reporting, and scholarly works - and generally that's an affirmative defense, rather than an express or implied right you have.
Honestly, Copilot is difficult because Copilot can't be the author of the code; the person who used Copilot is the "author" of the code, and I think they'd be the ones liable for copyright infringement if copyrighted content ends up in their code.
To argue someone performed copyright infringement, all you need is to prove (1) a valid copyright exists; (2) that the person had access to the work; (3) the person had the opportunity to steal the work; and (4) that protected elements of the work had been copied (afaik generally under a "substantially similar" standard). Copilot offers an easy way to check both (2) and (3) - a copyright holder could argue that people had access to their code through Copilot, and that Copilot offered an opportunity to steal the work.
BlurHash kind of does, but also doesn't, as I believe the canvas image API respects the colorspace of the loaded image; you can see this by generating a blurhash from a (non-sRGB) image and comparing it between the browser and server implementations.
The research article is located here: <https://www.pnas.org/doi/full/10.1073/pnas.2101084119>; if you're interested in what "likely" means in this context, it may be beneficial to read through the article. My understanding is that the "likely" comes from it being an estimate using models, as the research article states.
> Substituting our empirically derived domestic emissions for those modeled in the RFS RIA would raise ethanol’s projected life cycle GHG emissions for 2022 to 115.7 g CO2e MJ−1—a value 24% above baseline gasoline (93.1 g CO2e MJ−1). The RIA estimate, however, includes improvements in feedstock and ethanol production efficiency that were projected to occur by 2022, such that the GHG intensity of ethanol produced at earlier time periods and over the life of the RFS to date is likely much higher [...].
My understanding is that they took the model used in the RFS RIA (when the RFS was first introduced), and plugged in what they've seen over the past few years to that model. Take that with what you will.
> And we're to assume that, without the production of fuel ethanol, the same land wouldn't be tilled and used for other crops?
With the increase in demand for corn for fuel usage, more fields are needed to plant the corn. Because the corn is for fuel, not food, food wouldn't have been planted in place of the corn had there not been fuel demand.
> With the increase in demand for corn for fuel usage, more fields are needed to plant the corn. Because the corn is for fuel, not food, food wouldn't have been planted in place of the corn had there not been fuel demand.
Spent corn used in ethanol production becomes livestock feed. Good quality feed, actually. Even with a surplus of spent corn, it can be dried and kept around until needed. Point being that it actually is food, just by proxy. More fields may be needed to scale for demand, but it wouldn't be linear. For all we know, the scale of corn production has a modest relationship with ethanol or is correlative and weakly causative.
> We know that moving `Arc<Db>` will not change the location of the `Db` object, but there is no way to communicate this information to rustc.
There is! `std::pin`[0] does just this (and `Arc<T>` even implements `Unpin`, so the overall struct can be `Unpin` if everything else is `Unpin`). The page even includes a self-referential struct example, though it does use `unsafe`.
I created my own web framework (<https://docs.rs/under/latest/under/>) to address some of my own perceived issues with a lot of current rust web frameworks - typing issues being one of them. Personally, I don't like the idea of endpoints requiring `#[handler]` or other "magic" derives, or guards - I wanted something with an endpoint that takes a request, and returns a result with a response. I'm still working on it, though.
Are you sure this is the same code that triggers the vulnerability? Is the double `update` in the post itself unimportant (i.e., first updating with a 1-byte string, then the 4,294,967,295-byte string)? As I don't think this does that.
Let's try! Gimme a sec. And: to be clear: I make no representation that this code proves anything, and people should of course take a hard look at the SHA3 amd64 assembly code. I'm just having a message board discussion.
One sec and I'll get you an answer to your thing about the extra write.
It does feel like the code was ported as-is to Rust, and only adjusted slightly to compile; there are going to be pain points as a result of this process. I suspect this is the source of some of the author's complaints, especially given:
> Although it provides us with a greater sense of how the code is executing, it brings very little value to the algorithm itself.
Rust is, in general, for people who find value in having that information; it is okay to not want to have to worry about ownership, borrowing, safety, etc., but it seems a bit odd to complain about this when that's what Rust is for? If you want to focus on just the algorithm, and not how it's executing, then OCaml is definitely a valid choice.
However, the point about GADTs - can Rust's recently-stabilized GATs not work in the same way? Though I will admit that Rust's GATs don't seem nearly as powerful as OCaml's GADTs in this regard.