I did a visit to a farm[1] here in Spain and, according to them, the wagyu race is genetically predisposed to develop marbling due to an adaptation to combat extreme cold during the Japanese winters.
From their blog[2] and using Google translate:
It is believed that wagyu cows have that level of fat for a matter of survival. In Japan the winters are cold and the grasses are not especially rich in vitamin A. It is estimated that at some point in the evolution they achieved the ability to increase their own intramuscular fat production, which today is the characteristic of this race
I agree, wagyu beef is typically more expensive and richer in flavour than regular beef. The lightweight analogy doesn't really match that... Maybe there's another reason for the name
Lightweight in software is a weird adjective. I used to assume it meant light on resources but after seeing what passes for "lightweight" I've disabused myself of that notion. Instead, I've seen it mean any of the following:
Feature incomplete does describe VSCode well when compared to Visual Studio, but calling it lightweight is facetious. Visual Studio might be an absolute sow when it comes to eating your resources, but VSCode really doesn't improve in that area.
Not that familiar with Rust, but should the key generators perhaps take CryptoRng rather than Rng in their signatures, to prevent footgunning by users of the crate?
However, they seem to be using `XorShiftRng` in their tests, which is no cryptographically secure, so they can't use `CryptoRng` over `Rng` in their API without resorting to compile-time magic. I think they should just use `StdRng`, which is cryptographically secure and quite fast.
It's useful to have a seed able Rng when running tests in cryptographic use cases, as it allows you to reproducibly debug failures. I guess that's why they're using XorShiftRng. There are definitely cryptographically safe SeedableRngs; maybe they should use those?
I would imagine that they could solve this fairly easily by wrapping XorShiftRng in a newtype, and then implementing CryptoRng for that newtype. It's an awful thing to do in consumable code, but so long as it's done in the test module it should be perfectly fine.
This seems as good a place as any to ask: why is Rust so popular with cryptocurrency enthusiasts?
I currently do consulting for a well-known company in the cryptocurrency space, and since I have done, I've noticed that Rust's adoption in this industry is far, far higher than anywhere else. I regularly get inquiries to do work in Rust there, but basically nowhere else.
When you are writing software that you just _know_ is going to be used to store and manage money as its primary purpose, that means there are direct monetary benefits to people who can find exploits in your software: it isn't "maybe some government wants this" but "with an exploit I can directly steal a hundred million dollars and I would likely be unable to be caught". That makes you paranoid about getting the security correct.
So why rust then? Rust does not have a specification and it is currently still under heavy development, with many changes to the language expected to come out in the years to come. As many have put it before me, all of rust is technically undefined behavior. Change my mind -- I like the language, but I prefer those that have specifications and have multiple implementations so that the behavior is verified.
I can’t find the posts now, but MaidSafe switched over after their CEO gave Rust a try and was extremely impressed; this was back in 2014? You might want to dig into that, they explained their reasons at the time.
WebAssembly has also been on an upward trajectory in this space, and so there’s some synergy there too.
* A few early movers chose rust, and they likely share information and libraries, so it makes sense to just go in on it
Given that cryptocurrency is a fairly young space, having everyone leveraging the same tooling probably increases productivity. One day someone might say "We can get more productive if we leverage Language X, let's invest there", but until then everyone else is probably thinking "Oh, the libraries I need are in Rust, guess I'll use Rust".
one thing I find tricky about cryptocurrencies is that payment processors have snazzy interfaces for accepting crypto, but the similar interfaces don't seem to be available for open-source non-intermediary payment flows.
payment flows seem to be almost non-existent.
Its like "here just accept bitcoin" - when I really want to accept Monero - and there is almost no out of the box solution that rotates addresses for you, gives users a countdown and address solution, listens for transactions of the correct amount to that address to automatically update the payment site etc
There's no actual market for that. In theory, if people were using cryptocurrency to buy stuff and they believed in the "be your own bank" philosophy there would be a market, but none of that really exists.
Yeah, you'd think and thats the easy answer. The free open-source solutions slowly trickle out, but it just could be so much further along.
And yes, the abscense of merchants seriously trying to accept crypto, and the abscence of people seriously trying to spend it does it make a self-fulfilling prophecy.
but fixing these other problems of lack of free library will go a long way to fixing the speculator conundrum
45 comments
[ 3.4 ms ] story [ 90.4 ms ] threadThat logo is certainly lacking more marbling.
Also irrelevant I know.
From their blog[2] and using Google translate:
It is believed that wagyu cows have that level of fat for a matter of survival. In Japan the winters are cold and the grasses are not especially rich in vitamin A. It is estimated that at some point in the evolution they achieved the ability to increase their own intramuscular fat production, which today is the characteristic of this race
[1] https://www.fincasantarosalia.com
[2] https://www.fincasantarosalia.com/wagyu-o-kobe/#Tipos_de_wag...
2. “Wagyu is a lightweight”. i beg to differ.
The existing name is weird and not fitting at all though, that's for sure.
not-much-ceremony-to-use (e.g. https://github.com/emilk/loguru)
small amount of code but huge number of dependencies (e.g. micromodal https://github.com/ghosh/Micromodal/blob/master/yarn.lock )
But the common denominator appears to mean "feature incomplete".
>Visual Studio Code is a lightweight but powerful source code editor ...
https://code.visualstudio.com/docs
https://github.com/ArgusHQ/wagyu/blob/6b723d5c2c90ac87bcb44e...
The CLI does use StdRng which is a CryptoRng, so no real problems.
However, they seem to be using `XorShiftRng` in their tests, which is no cryptographically secure, so they can't use `CryptoRng` over `Rng` in their API without resorting to compile-time magic. I think they should just use `StdRng`, which is cryptographically secure and quite fast.
I currently do consulting for a well-known company in the cryptocurrency space, and since I have done, I've noticed that Rust's adoption in this industry is far, far higher than anywhere else. I regularly get inquiries to do work in Rust there, but basically nowhere else.
Do you have any links or an explanation that elaborates on this?
Even if this is technically true (and I'm not really convinced that it is) it is not practically meaningful.
WebAssembly has also been on an upward trajectory in this space, and so there’s some synergy there too.
* Rust meets basic constraints (performance, reliability)
* A few early movers chose rust, and they likely share information and libraries, so it makes sense to just go in on it
Given that cryptocurrency is a fairly young space, having everyone leveraging the same tooling probably increases productivity. One day someone might say "We can get more productive if we leverage Language X, let's invest there", but until then everyone else is probably thinking "Oh, the libraries I need are in Rust, guess I'll use Rust".
one thing I find tricky about cryptocurrencies is that payment processors have snazzy interfaces for accepting crypto, but the similar interfaces don't seem to be available for open-source non-intermediary payment flows.
payment flows seem to be almost non-existent.
Its like "here just accept bitcoin" - when I really want to accept Monero - and there is almost no out of the box solution that rotates addresses for you, gives users a countdown and address solution, listens for transactions of the correct amount to that address to automatically update the payment site etc
And yes, the abscense of merchants seriously trying to accept crypto, and the abscence of people seriously trying to spend it does it make a self-fulfilling prophecy.
but fixing these other problems of lack of free library will go a long way to fixing the speculator conundrum