I posted this because it's the most official source, but I learned of it from José's tweet here[0] and there's also a video about it[1] in the elixirforum discussion[2]
I haven't read the paper very far yet, but it sounds exciting in terms of ability to leverage GPUs for general purposes, curious for anyone's more expert opinion on how significant for elixir or in general this might be in terms of opening up more reusable/general code and library usage leveraging GPUs to developers who know little or nothing about GPU programming...
From the elixirforum discussion, this jumped out at me:
Q8: What are higher-order kernels in Hok?
A8: Higher-order kernels allow passing functions as arguments to GPU kernels, enabling dynamic configurations and flexible code reuse.
I didn’t read that part as saying “they’re not doing these things at all”, just that they’re not staying home them specifically to do them… they’re not “employed” as a “homemaker”, they are working from home. Unclear if you read it this way or are just commenting that you do more of those and you used to, several sibling comments seem to take, from your comment or the article, that this was a focus, and I don’t think it was?
As sibling comment by wsgeorge hinted, it is regional, but really it’s the reverse, terminology of “non profit” is regional to the US, basically everywhere else in the world I’ve heard of refers to non profit entities as “NGO”s… admittedly all businesses are “organizations” also but, since they tend not to call themselves that explicitly and other government entities do (e.g. World Health Organization), it seems reasonably clear as a distinction.
I hadn't heart about this but, to summarize, two people received capital punishment over this, one suspended death sentence, 3 life imprisonments, 2 15 year jail terms, and 13 others with lesser jail terms.
http://www.chinadaily.com.cn/china/2009-01/23/content_742298...
Came here to mention/contrast Vinge's metric time with with my (quick, approximate) understanding of this approach...
The problem with this approach is it attempts to "redefine" hours and minutes... part of what I liked in Vinge's/Deepness' approach was, it ignored all that and just talked about seconds in standard exponential scientific notation... it makes a lot more sense in space though, where there's no need/logic to connecting or synchronize to a specific solar cycle, so they just think/talk in kilo-seconds (about 40 mins) and mega-seconds (about 11.6 days)... or at least those are the two I recall them using enough that I got semi-used to thinking in them while reading the book... I had to convert, but I didn't have to redefine any existing unit or remember/remind myself which meaning of hour/minute they're using, because nothing changed.
The book Critical Mass by Daniel Suarez is my only source, but, the efficiency of rectenna is discussed there, and particularly, though the efficiency of the transmission is somewhat low, the efficiency of solar panels in space is MUCH higher than on earth, and they can operate 24/7, so the overall system efficiency is still substantially higher than the equivalent solar panels on earth... at least, assuming you can build the solar panels in space from mined material as they do in the book, I imagine if you needed to launch all the material from earth, it would probably be a fairly different story, assuming you included that in the calculations.
> the efficiency of solar panels in space is MUCH higher than on earth
Not really. The biggest difference between a panel on Earth and one in space is the space panel is illuminated 23 hours a day. So per panel you're getting 2-3x the illumination over the course of the day.
The drawback is even at the absolute cheapest pie in the sky Musk estimates of cost to orbit ($10/kg), a space solar panel is orders of magnitude more expensive than a ground panel. You could just deploy 3x the number of panels on Earth for 3x the price vs deploying in space at x\^3 the price.
Even with the near constant illumination of panels in space the losses from RF conversion, free space losses, atmospheric losses, and RF rectification eliminate a lot of your power gains. For those losses you also incur significant costs. So SBS is kind of a lose-lose problem. Every technology that would make SBS more practical could be applied on the ground for a tiny fraction of the cost.
>The biggest difference between a panel on Earth and one in space is the space panel is illuminated 23 hours a day
Small nitpick, but as a GEO satellite navigator I want to point out that the solar panels are in sunlight constantly except for "eclipse season" around the equinoxes. During eclipse season it can be in shadow for about an hour.
Only if ignoring all externalities. If the panels could be manufactured in space, or on the moon, via some ultrasmall in-situ-utilizer bootstrap gizmothingy, which would then use material from the moon, or asteroids, we'd save much mining and manufacturing here on earth. Which has its own costs. As we all should know, meanwhile?
Came here to say the same! Though it's a bit fun that when they upgrade the moon to use a nuclear reactor to power several mass drivers, they mention how the satellite can be repurposed to provide power to earth now... which makes sense. The book (and its part 1 book, Delta-V) overall point about the value and utility of asteroid and lunar mining to bootstrap whole economies around the Lagrange points and that sending that matter back down to earth makes very little sense was pretty compelling, and relatedly that building a colony on Mars probably makes very little sense vs building in space with artificial gravity and artificial radiation shielding, where you're not subject to a giant gravity well to go back to earth/elsewhere in solar system.
I admit for a long time this was my primary motivation to learn Rust, but, sadly, I haven't come across problems in years that were CPU bound/where I needed something like Rust... Rustler still looks like a great fit if needed, but, depending on the use case, if I were CPU bound and needed to write my own code/not just use a Rust library, I'd be as or more likely to look at using Zig and Zigler[0], for much faster learning curve, and from what I've read, easier tighter integration into elixir, including I think language server integration. Some discussion here[1] though I forget if I listened to this one or not.
I haven't come across problems in years that were CPU bound/where I needed something like Rust
This is where Rust falls short of C#: scaling to the issue at hand. C# can build you a beautiful app at a high-level but also lets you dick with pointers and assembly at a low level. Rust insists on defaulting to pass-by-move and an arcane trait system that hold it back from being usable in large projects.
If Rust had gone for a traditional OOP system, the "everything must be OOP/use inheritance everywhere" crew would have messed up the ecosystem pretty quickly. The traits concept is refreshing and traits + structs encourage composition over inheritance. I think it has been a huge plus for the language and the ecosystem.
I really like the trait system, but “refreshing” might not be the correct word given that it is pretty much what Haskell had for I don’t even know how many years.
I haven't read the paper very far yet, but it sounds exciting in terms of ability to leverage GPUs for general purposes, curious for anyone's more expert opinion on how significant for elixir or in general this might be in terms of opening up more reusable/general code and library usage leveraging GPUs to developers who know little or nothing about GPU programming...
From the elixirforum discussion, this jumped out at me: Q8: What are higher-order kernels in Hok? A8: Higher-order kernels allow passing functions as arguments to GPU kernels, enabling dynamic configurations and flexible code reuse.
[0]https://x.com/josevalim/status/1847372557743456382
[1]https://www.youtube.com/watch?v=oB8eeJ-GaTM
[2]https://elixirforum.com/t/two-new-elixir-related-papers-at-t...