I feel like the title is a bit misleading. I think it should be something like "Using Rust's Standard Library from the GPU". The stdlib code doesn't execute on the GPU, it is just a remote function call, executed on the CPU, and then the response is returned. Very neat, but not the same as executing on the GPU itself as the title implies.
> For example, std::time::Instant is implemented on the GPU using a device timer
The code is running on the gpu there. It looks like remote calls are only for "IO", the compiled stdlib is generally running on gpu. (Going just from the post, haven't looked at any details)
Which is a generally valid implementation of IO. For instance on the Nintendo Wii, the support processor ran its own little microkernel OS and exposed an IO API that looked like a remote filesystem (including plan 9 esque network sockets as filesystem devices).
Flip on the pedantic switch. We have std::fs, std::time, some of std::io, and std::net(!). While the `libc` calls go to the host, all the `std` code in-between runs on the GPU.
I think it fits quite well. Kind of like the rust standard lib runs on the cpu this does partially run on the gpu. The post does say they fall back on syscalls but for others there a native calls on the gpu itself such as Instant. The same way the standard lib uses syscalls on the cou instead of doing everything in process
Exactly what I was thinking. I mean how can you produce something, esp. in bulk, when the exact ingredients and quantities aren't known? Assuming it is made in a typical factory, the machines would have to be programmed and that would typically mean someone has to know. I wonder if they split the knowledge over several different groups so a group only knows a single piece? Hmm....
This is how they do it. There was a documentary about coca-cola and they explained that they completely separated the supply pipeline. Operators manipulate unlabelled sources coming from separate parts of the company.
It's a myth that Coca-Cola is a closely held secret, though. Any food flavoring specialist can reconstruct the flavor of Coke almost exactly.
A few years ago I (not a specialist!) made lots of batches of OpenCola, which is based partly on the original Pemberton recipe, and it comes so close that nobody could realistically tell the difference. If anything, it tastes better, because I imagine Coke doesn't use fresh, expensive essential oils (like neroli) for everything.
The tricky piece that nobody else can do is the caffeine (edit: de-cocainized coca leaf extract) derived from coca leaves. Only Coke has the license to do this, and from what I gather, a tiny, tiny bit of the flavour does come from that.
> If anything, it tastes better, because I imagine Coke doesn't use fresh, expensive essential oils (like neroli) for everything.
I've not participated in Cola tasting, but assuming fresher tastes better isn't really a safe assumption. Lots of ingredients taste better or are better suited for recipies when they're aged. I've got pet chickens and their eggs are great, but you have to let them sit for many days if you want to hard boil them, and I'd guess baking with them may be tricky for sensitive recipies.
Anyway, even if it does taste better for whatever that means, that's not meeting the goal of tasting consistently the same as Coke, in whichever form. If you can't tell me if it's supposed to taste like Coke from a can, glass bottle, plastic bottle, or fountain, then you've told me all I need to know about how close you've replicated it.
I think my point flew past you: If I can make a 99% clone of Coke in my kitchen, any professional flavoring pro will do it 100%. The supposed secret recipe isn't why Coke is still around, it's the brand.
And by fresh I do mean: The OpenCola is full of natural essential oils (orange, neroli, cinnamon, lime, lavender, lemon, nutmeg), and real natural flavor oils have a certain potent freshness you don't get in a mass-produced product.
I'm merely making the point that there's nothing magical about the recipe. Anyone wanting to truly replicate it for mass production can simply use commodity flavor compounds.
Coca leaves contain various alkaloids, but not caffeine. Coca Cola gets its caffeine from (traditionally) kola nuts, and (today, presumedly) the usual industrial sources.
You had better luck than I did, I tried my hand at making Open Cola, put around $300 into it (between the carbonization rig and essential oils primarily), and while I'd say it was "leaning towards coke", I would also definitely say that nobody would mistake it for coke.
I noticed it was incredibly important to get the recipe mixture exactly right, because even a slight measurement error resulted in weirdly wrong flavors.
I did my OpenCola experiment in the company office together with a colleague, and we ended up hooking it up to a beer tap, with a canister of CO2. I'm proud to say the whole office really got into it.
Ive heard from others that this is how defense software engineering goes.
You write code for a certain part/spec that could go on a number of things (missle, airplane, etc). You dont know if your code will be used in a missile or not.
I am a pretty serious "Rustacean", but I like to think "for the right reasons". A rewrite in Rust of the main project would make very little sense, unless there is some objective the project wants that can't be met with C (see below). This person presents a well thought out case on why it makes little sense to rewrite, especially in the final section. Rust is great for many things, but when you have something old that is already so well tested and accessible on all sorts of obscure platforms, it makes little sense to rewrite, and the likely result would be more bugs, not less, at least in the short term.
Limbo and Turso's other tools seem interesting, but the listed limitation of “no multi process database access” is pretty huge.
If you don’t need that, then great—Turso/Limbo might be for you! But there are a ton of use cases out there that rely on SQLite for simultaneous multiprocess access. And I’m not even talking about things that use it from forking servers or for coordination (though those are surprisingly common as well)—instead, lots of processes that use SQLite 99.9% of the time from one process still need it to be multiprocess-authoritative for e.g. data exports, “can I open two copies of an app far enough to get a ‘one is already running’ error?”-type use cases, extensions/plugins, maintenance scripts, etc. not having to worry about cross-process lock files thanks to SQLite is a significant benefit for those.
This seems like the way. Why would Rustaceans bother to "argue their case" before an unwilling board if they can just do the rewrite themselves? Maybe it will succeed, maybe not, but you don't need SQLLite's blessing to test the proposition.
My hunch is that those aren't very serious Rustaceans. Even the original language developers developed Rust to interoperate with C as much as possible, and they often used to discourage the rewrite evangelism. If you are a serious Rustacean, you'd probably be worried about the safety tradeoffs in rewriting in Rust. As your parent commenter points out, a mature C codebase is already tested so well that rewriting it in Rust is likely to introduce more bugs - non-memory-safety bugs that are nevertheless serious enough. That's why I and many other Rustaceans don't recommend it. In fact, some Rustaceans even advise others to not rewrite Fortran 90 code (in order to preserve the performance advantage) and instead recommend integrating it with Rust using FFI.
Oh, SQLite (as a database) is easy compared to a client-server database, or an "embedded" database that runs in a separate process.
The issue is more of the object-relational impedance mismatch that happens when using any SQL database: ORMs can be slow / bloated, and hand-written SQL is time consuming.
I shipped a product on SQLite, and SQLite certainly lived up to its promise. What would have been more helpful was if it could index structured objects instead of rows, and serialize / deserialize the whole object. People are doing this now by putting JSON into SQLite. (Our competitors did it when I looked into their SQLite database.)
I could see it being useful for pure Rust projects once its completed. I mean in Java / Kotlin land, I prefer to use H2 in some cases over SQLite since its native to the platform and H2 is kind of nice altogether. I could see myself only using this in Rust in place of SQLite if its easy to integrate and use on the fly.
The equivalent "platform native" database for Clojure is Datalevin [0], which has a Datomic-like Datalog query language with SQLite-style semantics. Recommended.
> by reading that the memory safe Rust language has and can cause undefined behaviour
Only unsafe blocks can cause undefined behavior. The memory safe portion of Rust that most program in cannot cause UB. If you use "forbid unsafe" then you can be assured your program is free from UB (assuming all the crates and stdlib you use are as well).
It still leaves me lingering in a space-time-continuum where I search for the safety of rational completeness, while inadvertently living on a Möbious strip.
Thank you to those who continue to develop Miri. It is a great tool for those of us that have crates that need to use unsafe. While nothing will give 100% confidence in the lack of UB, Miri is a great start.
> You've created a logical justification for a myopic, misanthropic world view.
Nobody said it wouldn't be nice, but that it does not confer "obligation". This is the key word. I would argue a world where people do things because they want to, and not because they feel they have to, would actually generally be a nicer world to live in.
> Many find reciprocation important in a relationship.
Yes, and those sorts of relationships aren't really built on much if a gift obligates the other to repay. Why even buy lunch then? It just becomes this back and forth obligation and it is wearing and actually erodes the relationship slightly, if anything. I would argue a true gift is one that does not obligate the other party to reciprocate. That does NOT mean it would not be a decent thing to do something nice (for the other person OR someone else), but just that it is not obligated. The person should not feel a weight to do so. Once this weight is lifted, it is actually very freeing, and it strengthens the relationship, if anything.
I don't buy someone lunch with an implicit expectation that they'll buy me lunch in the future. That's tacky and gross. I buy lunch because I wanted to buy them lunch, and if they decide to buy me lunch, I happily accept.
Means you're not in the "many" segment. Doesn't mean many others are not in the "many" segment. I, myself, find reciprocation important even if not for identical "gifts".
A better route for something like Go IMO is to move to a compacting collector, this would allow them to move to a bump allocator like Java for super fast allocations and would make deallocation effectively "free" by only moving live objects. They may need to make it generational so they aren't constantly moving long lived objects, but that is a memory vs cpu trade off (could be one more GC flag?). If I recall, the previous objection was because of CGo, which would require pinning (since C wouldn't tolerate moved pointers), but every Go dev I know hates CGo and generally avoids it, plus I see they added "runtime.Pinner" in 1.21 which should solve that I suspect (albeit it would suddenly be required I expect for pointers retained in C). Is anyone aware of what other challenges there are moving to a compacting collector/bump allocator?
> this would allow them to move to a bump allocator like Java for super fast allocations and would make deallocation effectively "free" by only moving live objects
Ah, you've been misled as well. Super fast allocations is a meme. Yes, the very act of allocating is fast, great. Just like tossing trash on the floor. Super fast. Now you have a pile of garbage on the floor that you need to clean up. How fast are you going to end up being after the clean up?
In a design space as tightly constrained as a GC you can't just make something fast. You have to trade off something else to get it. So now that you have sacrificed something to make the act of allocating fast, you've also encouraged programmers using your language to allocate willy-nilly—it's fast after all. Now the pile of garbage is rising at an alarming rate and your self-gimped GC has to deal with it all.
Making allocations fast is a positive feedback loop that degrades GC performance. You want allocations to be slow and to leverage the leeway from that tradeoff to get a faster GC. Moreover, this will provide backpressure to the entire package ecosystem to limit allocations, further improving performance.
Go exposes raw pointers to the programmer, and its current GC is entirely non-moving. Even excluding cgo, I think a moving one would probably break real programs that rely on pointer values.
Yes, there's a case to be made that exposing "real" pointers in a GC'd language was a substantial mistake, but I guess it simplified _some_ parts of FFI. The trade-off so far maybe is fine, but it is a shame that there are certain things that can't be done without introducing new substantial costs. Maybe the compiler could learn to do something suuuper clever like recognize when pointers are being used non-transparently and automatically pin those, seems fraught with potential error though, trivial example being stuff like &a[0] (that ones easier to catch, others might not be).
True, I forgot about unsafe package. They would probably have to make it a Go 2 thing and add indirection to raw pointers or a need to "pin" them. Since pinning would already exist for CGo I suspect that would make more sense and wouldn't have performance penalty.
It is also equally odd to me that people want to cling so hard to C, when something like Rust (and other modern languages for that matter), have so much nicer eco systems, memory safety aside. I mean C doesn't even have a builtin hashtable or vector, let alone pattern matching, traits and sum types. I get this is about AI and vibe coding, but we aren't at a point yet where zero human interaction is reasonable, so every code base should assume some level of hybrid human/AI involvement. Why people want so badly to start a new code base in C is beyond me (and yes, I've written a lot of C in my time, and I don't hate it, but it didn't age well in expressiveness).
> It is also equally odd to me that people want to cling so hard to C, when something like Rust (and other modern languages for that matter), have so much nicer eco systems, memory safety aside.
Simplicity? I learned Rust years ago (when it was still pre release), and when i now look at a lot of codebases, i can barely get a sense what is going on, with all the new stuff that got introduced. Its like looking at something familiar and different at the same time.
I do not feel the same when i see Go code, as so little has changed / got added to it. The biggest thing is probably generics and that is so rarely used.
For me, this is, what i think, appeals for C programmers. The fact that the language does not evolve and has been static.
If we compare this to C++, that has become a mess over time, and i know i am getting downvoted for this, Rust feels like its going way too much in the Rust++ route.
Like everybody and their dog wants something added, to make Rust do more things, but at the same moment, it feels like its repeating the C++ history. I have seen the same issue with other languages that started simple, and then becomes monsters of feature sets. D comes to mind.
So when you see the codebase between developers, the different styles because of the use of different feature sets, creates this disconnect and makes it harder for people to read other code. While with C, because of the language limits, your more often down a rather easier way to read the same code. If that makes sense?
reply