Not that I have a monopoly on information or anything, but I live in Singapore and this comment is possibly the first time I have ever heard this guy's name.
chair of the National Infection Prevention and Control Committee through the Ministry of Health, Singapore (2013 -),)
To the rest of the world, he is the face of Singapore's Covid response. Based on what I've read he was influential (behind the scenes perhaps?) in Singapore's response...and the reason why your government didn't require masks till after your flare up.
His advice seems to have been taken very seriously in other countries (not requiring masks, not closing schools).
I've always assumed that you use "an" whenever a noun starts with a vowel sound, which "Nvidia" does ("n" being pronounced as "en"), thus making "an Nvidia" the grammatically correct one.
This is actually a deeper issue about the confusion between the language itself (english phonology requires what you're describing) and the written form. No english speaker in the world, unexposed to the written form of "Nvidia" would ever say "A Nvidia."
That entirely depends on how you pronounce "nvidia" in your head. I can imagine someone who has never heard the name spoken out loud think of it as "ni-vidia" (I have done worse) and "a Nividia" is easier than "an Nividia"
The moment they start doing this, other countries will restart their mines and the Chinese leverage (and profits) will evaporate. Rare earth minerals aren't that rare.
Found the estimate in the report the Pentagon gave to Congress on this issue in 2013. Your proposed action would take the US, alone, 15 years (https://imgur.com/olWM3Xi).
I believe there's a few Australian mining companies with plans ready to go if China ever does this. The prices will go up, a lot, but the spice will flow.
From what I understand, it's not the mines that are the problem. In fact, China imports most of its rare earth materials. What they control is the refinement of these materials turning them from a raw form to something useable. I believe the US is finally starting to do something about this imbalance, but I'm unsure if its scale is great enough to have an effect. A refinement plant just came online in Colorado (or is it Texas?) in the last few months. I believe there might be more in the pipeline including Mountain Pass (in addition to the mine itself) in California. From what I understand, traditionally refinement is an extremely dirty process and as a result extremely costly to run especially with all the environmental restrictions and potential fines.
edit: latrare brings up another very important point. The patents surrounding the processes to refine RE materials. Take a look at who owns most of them...
I recall that China owns most of the latest patents on rare earth refinements. This should be obvious considering they are the most active in its refinement process.
Now, the irony is that if American companies want to start rare earth refining, then they must pay China for the use of those refinement patents.
Oh the irony.
Unless some American senator want to invalidate all of China’s patents on grounds of National Security. Oh the hypocrisy.
China has been maintaining a majority share of production for at least a decade at this point. I would wager that while that your proposed response is short as a phrase, actually getting production to match the currently relied-upon volume without China would take years, and I don't think stockpiles would last that long.
The US accounts for a small part of the global REM consumption. Even with their majority share, unless China is willing to burn the rest of the world, the US would be able to make do. And that's not even getting into transhipping which was used to circumvent previous REM export bans.
I saw it explained like this. Rare minerals are everywhere but they're spread out, and China's advantage is they will destroy a lot of environment to extract them while other countries are regulating protections for the environment. If that is true it would be very difficult for other countries to fill the demand?
I thought lots of existing mines had ore containing them, but can't make a profit extracting them, so they don't. How quickly such extraction/refining steps could be added, I don't know. (Am far from an expert though!)
> You can ignore the error case on a result / the None case on an option as easily as you ignore the `err` today.
The point of a result type is that you _cannot_ ignore the None case. Any method that would provide you with the value will also check that the error is not present.
In comparison, you can happily ignore `err` in Golang and continue with an invalid `value`.
I see what you're saying, and while I think you're right, I think a lot more of the value is in being able to use `Map()` /`FlatMap()` to be able to avoid thinking about error checking at all, as I laid out in the second part of this comment https://news.ycombinator.com/item?id=23549396 . The convention of returning `(value, err)` goes a long way towards enforcing the checking of errors; I have golangci-lint's `errcheck` linter enabled and basically cannot accidentally ignore the `err` values. In any case, Option/Result types are extremely useful and I'm happy that with generics the language will be able to include them!
For an ergonomic implementation of Result and Option you need to be able to represent tagged unions/enums/sum types, and having pattern matching makes dealing with them much more natural. These features are not planned for Go (yet?), right?
> In comparison, you can happily ignore `err` in Golang and continue with an invalid `value`.
I'm struggling to envision a Result type that requires you to be more explicit than `foo, _ := fallible()`. Seems like `fallible().Ok()` and similar are strictly less explicit.
To do anything with a Result/Optional, you have to explicitly get the value inside the box at some point. But the container abstraction also gives you a nice composition abstractions instead of the uncomposable top-level `val, err := do()` destructure.
Though perhaps not quite as compelling without real sum types. I'd have to play with Go's generic-typing sandbox more to form a stronger opinion.
The linked LWN article[1] mentions context-sensitive keywords, ie. a way to treat certain words as language keywords only in specific contexts. For example, a new match statement that wouldn't require reserving the `match` word as a language keyword, which would require a breaking change and break all existing code that uses `match` as a variable name.
One good example (for those who do not want to read the full article) is the async keyword. Introducing it as keyword broke a few libraries which were already using them as kwarg in some functions (e.g. pytorch).
I wonder if Python will go back and address other shortcoming which I assume are tied to the parser, such as the inability to use quotes inside the interpolated segments.
> Would the Go runtime lock you to that specific thread and block it or sleep that goroutine and move it to another thread when its no longer sleeping?
By default, the Go runtime does not guarantee any affinity between Go-level threads (goroutines) and OS threads. There's a way to forcibly pin a goroutine to a specific thread[1], but it limits your concurrency.
The Go approach does indeed cause problems wrt. OS-thread-affine state. It's a tradeoff. For RPC-oriented network services, the Go niche, OS thread state is very rare.
This code block doesn't actually work the way the Kotlin one does. Async functions are mere pull-based state machines, so both `one` and `two` will compute serially, without concurrency.
What you need is:
use futures::join;
let result = executor::block_on({
let one = async { do_something_useful_one() };
let two = async { do_something_useful_two() };
let (one, two) = join!(one, two);
one + two
});
I feel like this might be a common stumbling block and hope there will be a Clippy check for this or something.
Ah, thank you. I wasn't aware that the Kotlin syntax automatically raced `one` and `two`. I'm not sure how I feel about that, but I haven't thought deeply about it. My gut is kinda "meh".
In the spirit of getting it right, your code is missing an `await` and `join` is back to a function in alpha18. Here's the currently working (this time tested!) code:
#![feature(async_await)]
use futures::{executor, future}; // 0.3.0-alpha.18
fn main() {
let result = executor::block_on(async {
let one = async { do_something_useful_one() };
let two = async { do_something_useful_two() };
let (one, two) = future::join(one, two).await;
one + two
});
println!("{}", result);
}
fn do_something_useful_one() -> i32 { 1 }
fn do_something_useful_two() -> i32 { 2 }
It doesn't automatically race. The "async" block in Kotlin is an equivalent to "spawn" in Rust, and launches everything in it as a child task. However compared to Rusts spawn Kotlin makes use of structured concurrency - which means parent tasks wait for child tasks and if you cancel a parent task the child task will get notified. So it's meaning is definitely closer to the join() based solution you documented.
The sequential but still async version in Kotlin is simply
val result = runBlocking {
doSomethingUsefulOne() + doSomethingUsefulTwo()
}
Both Lawrence Wong and Gan Kim Yong are Singaporeans.
https://en.wikipedia.org/wiki/COVID-19_pandemic_in_Singapore