Google Cloud Platform and near-perfect documentation
-
@Kian said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
Actually, if there's no handler found, it is implementation-defined in C++ whether it unwinds or not before calling std::terminate().
Granted, in the specific case of program termination due to an uncaught exception, you can't portably rely on whether destructors were called. Normally you wouldn't care (your program is crashing because you didn't have code in place to handle the error, and you don't need it to remain in a consistent state because the next state of the program is "gone"), but you can force destructors to be called by having a catch all clause in main and rethrowing (or exiting cleanly with a message that you don't know what went wrong). So it's not specified in case you don't care, and you have a way to force consistent behavior if you do
pie_flavor said in Google Cloud Platform and near-perfect documentation:
Meanwhile, in Rust, it's called thread panic because it ends at the thread boundary; calling join on a thread will return a Result representing whether the thread panicked or not.
That's interesting. In c++ using std::async will return a std::future, which can hold the result of the threaded task or an exception. You can even hand the future to another thread, and let that thread deal with the maybe exception, without looking inside.
This just makes you wonder, why's they called them panics and not exceptions, aside from trying to discourage their use. And why they would want to discourage their use in the first place.
They called them panics instead of exceptions because they are not guaranteed to result in a stack unwinding and because the only thing you're really meant to pass to a panic is a string message. They want to discourage their use because stack unwinding is far more expensive than a conditional prediction fail.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
If it did, then it would definitely matter because that hits performance.
- Performance doesn't usually matter.
- The size or how it's used or something similar might make heap a better place for it.
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
Performance doesn't usually matter.
Archived for posterity.
@boomzilla said in Google Cloud Platform and near-perfect documentation:
The size or how it's used or something similar might make heap a better place for it.
Why do you think they made an entire language release around
ref struct
and similar constructs?
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
Performance doesn't usually matter.
Archived for posterity.
Good. Have you ever used a profiler on any code? Because your posts suggest not.
@boomzilla said in Google Cloud Platform and near-perfect documentation:
The size or how it's used or something similar might make heap a better place for it.
Why do you think they made an entire language release around
ref struct
and similar constructs?Why do you think that matters? Serious question, you're going to need to present an actual argument because
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
Performance doesn't usually matter.
Archived for posterity.
Good. Have you ever used a profiler on any code? Because your posts suggest not.
I don't know why they'd suggest that. Care to elaborate?
@boomzilla said in Google Cloud Platform and near-perfect documentation:
The size or how it's used or something similar might make heap a better place for it.
Why do you think they made an entire language release around
ref struct
and similar constructs?Why do you think that matters? Serious question, you're going to need to present an actual argument because
They made it specifically because they don't do any of that stack-to-heap optimization stuff. Seriously, can you give me one example where a struct would get allocated on the heap instead of the stack in C#?
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
Performance doesn't usually matter.
Archived for posterity.
Good. Have you ever used a profiler on any code? Because your posts suggest not.
I don't know why they'd suggest that. Care to elaborate?
Your "Archived for posterity" comment seems to indicate disagreement with my statement about performance, which suggests a lack of experience with empirical performance measurements.
@boomzilla said in Google Cloud Platform and near-perfect documentation:
The size or how it's used or something similar might make heap a better place for it.
Why do you think they made an entire language release around
ref struct
and similar constructs?Why do you think that matters? Serious question, you're going to need to present an actual argument because
They made it specifically because they don't do any of that stack-to-heap optimization stuff. Seriously, can you give me one example where a struct would get allocated on the heap instead of the stack in C#?
- I don't have enough familiarity with C# (or more importantly the CLR).
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
Performance doesn't usually matter.
Archived for posterity.
Good. Have you ever used a profiler on any code? Because your posts suggest not.
I don't know why they'd suggest that. Care to elaborate?
Your "Archived for posterity" comment seems to indicate disagreement with my statement about performance, which suggests a lack of experience with empirical performance measurements.
You declared, straight-up, that performance does not matter. Go launch six instances of Slack and figure out why you're wrong.
@boomzilla said in Google Cloud Platform and near-perfect documentation:
The size or how it's used or something similar might make heap a better place for it.
Why do you think they made an entire language release around
ref struct
and similar constructs?Why do you think that matters? Serious question, you're going to need to present an actual argument because
They made it specifically because they don't do any of that stack-to-heap optimization stuff. Seriously, can you give me one example where a struct would get allocated on the heap instead of the stack in C#?
- I don't have enough familiarity with C# (or more importantly the CLR).
IOW, you have no idea what you're talking about and never did.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
You declared, straight-up, that performance does not matter.
Stop putting words in my mouth because I said nothing of the sort. I'll leave it as an exercise for the non-reader to figure out why you're wrong.
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
IOW, you have no idea what you're talking about and never did.
I'll be honest, we were talking Go then Rust and then C# and I didn't keep the various languages straight. The principles behind my posts are sound even if those languages implement them differently.
-
@boomzilla You knew exactly what language we were talking about, because only in C# is the memory location of objects implementation-defined. Bullshit cop-out is bullshit.
-
@pie_flavor What? Why do you think you know what I'm thinking better than I do? If you already know what everyone is thinking why bother discussing anything in the first place if you're not going to believe what we say?
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor What? Why do you think you know what I'm thinking better than I do? If you already know what everyone is thinking why bother discussing anything in the first place if you're not going to believe what we say?
Good question - I've made my point clear about six times now and you still can't seem to figure out what I'm thinking.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor What? Why do you think you know what I'm thinking better than I do? If you already know what everyone is thinking why bother discussing anything in the first place if you're not going to believe what we say?
Good question - I've made my point clear about six times now and you still can't seem to figure out what I'm thinking.
Which point? That you don't understand when performance matters? Or how compilers work? Or some boring C# implementation detail minutiae?
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor What? Why do you think you know what I'm thinking better than I do? If you already know what everyone is thinking why bother discussing anything in the first place if you're not going to believe what we say?
Good question - I've made my point clear about six times now and you still can't seem to figure out what I'm thinking.
Which point?
The one about the significance of the heap vs stack. Seriously, if you guys don't know something that most people learn on day 5 of their intro to programming class, there's a problem here.
That you don't understand when performance matters?
Did you try the Slack experiment yet?
Or how compilers work?
Was this relevant?
Or some boring C# implementation detail minutiae?
That you brought up?
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
Did you try the Slack experiment yet?
It's irrelevant to my point. You still haven't comprehended what I wrote.
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
That you brought up?
You mean when I was still thinking back to that exchange between you and @ben_lubar about how go decides when to put something on the stack or the heap?
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
Did you try the Slack experiment yet?
It's irrelevant to my point. You still haven't comprehended what I wrote.
I did, actually. Did you?
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
That you brought up?
You mean when I was still thinking back to that exchange between you and @ben_lubar about how go decides when to put something on the stack or the heap?
No, I mean when you brought it up. I don't know what you were reminiscing about when you did.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
The one about the significance of the heap vs stack.
Why would you allocate on the stack when you can keep the data in registers instead?
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
Did you try the Slack experiment yet?
It's irrelevant to my point. You still haven't comprehended what I wrote.
I did, actually. Did you?
If you did then you wouldn't be telling me to try something that has bad performance as a way to show me that I'm wrong.
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
That you brought up?
You mean when I was still thinking back to that exchange between you and @ben_lubar about how go decides when to put something on the stack or the heap?
No, I mean when you brought it up. I don't know what you were reminiscing about when you did.
Yes, you do, because I told you.
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
Did you try the Slack experiment yet?
It's irrelevant to my point. You still haven't comprehended what I wrote.
I did, actually. Did you?
If you did then you wouldn't be telling me to try something that has bad performance as a way to show me that I'm wrong.
Wrong about performance not being important?
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
That you brought up?
You mean when I was still thinking back to that exchange between you and @ben_lubar about how go decides when to put something on the stack or the heap?
No, I mean when you brought it up. I don't know what you were reminiscing about when you did.
Yes, you do, because I told you.
When?
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
Did you try the Slack experiment yet?
It's irrelevant to my point. You still haven't comprehended what I wrote.
I did, actually. Did you?
If you did then you wouldn't be telling me to try something that has bad performance as a way to show me that I'm wrong.
Wrong about performance not being important?
I never said that.
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
That you brought up?
You mean when I was still thinking back to that exchange between you and @ben_lubar about how go decides when to put something on the stack or the heap?
No, I mean when you brought it up. I don't know what you were reminiscing about when you did.
Yes, you do, because I told you.
When?
Looking at the post, it currently says 20 minutes ago. It's even still in this quote tree.
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
Did you try the Slack experiment yet?
It's irrelevant to my point. You still haven't comprehended what I wrote.
I did, actually. Did you?
If you did then you wouldn't be telling me to try something that has bad performance as a way to show me that I'm wrong.
Wrong about performance not being important?
I never said that.
Looking at the post, it currently says 4 hours ago.
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
That you brought up?
You mean when I was still thinking back to that exchange between you and @ben_lubar about how go decides when to put something on the stack or the heap?
No, I mean when you brought it up. I don't know what you were reminiscing about when you did.
Yes, you do, because I told you.
When?
Looking at the post, it currently says 20 minutes ago. It's even still in this quote tree.
You didn't explicitly say that was what you meant, you asked if it was what I meant.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
Did you try the Slack experiment yet?
It's irrelevant to my point. You still haven't comprehended what I wrote.
I did, actually. Did you?
If you did then you wouldn't be telling me to try something that has bad performance as a way to show me that I'm wrong.
Wrong about performance not being important?
I never said that.
Looking at the post, it currently says 4 hours ago.
And yet you won't be able to honestly quote me saying that. Weird.
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
Performance doesn't usually matter.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
Performance doesn't usually matter.
Yep. Can you see the difference yet between that and the thing you keep claiming I said? "Performance doesn't matter."
-
@boomzilla All righty then. So it doesn't matter most of the time. Is that the percentage of the time when software is running on something you're not interacting with?
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla All righty then. So it doesn't matter most of the time. Is that the percentage of the time when software is running on something you're not interacting with?
Yes, that happens with a lot of software. Look, you're obsessed with the micro-optimization of stack vs heap. That's way way way down on the list of things that usually matter for performance anyways.
heesh, it's like you've never profiled software before. Hmm...that sounds familiar.
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
Look, you're obsessed with the micro-optimization of stack vs heap. That's way way way down on the list of things that usually matter for performance anyways.
At the language level, everything matters. If you want your language to be general purpose, it has to fit as many use cases within the paradigm as possible. In Rust, nothing is implicitly heap-allocated; you must explicitly box heap-allocated values. This means that it can stay high-performance in cases where it does matter, and has an option for low performance where it doesn't matter. The language decisions you are advocating for are the sort of language decisions that brought us JS.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
The language decisions you are advocating for are the sort of language decisions that brought us JS.
Oh daaaaamn. had to go there.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
At the language level, everything matters.
But some things matter far more than others.
Overall, what almost always matters is whether the performance of the system is sufficient for the results to a request to be received in a reasonable amount of time using a reasonable amount of resources. This in turn means that performance in the vicinity of system bottlenecks will matter hugely, and performance in other areas — the huge majority of the code of most applications — is significantly less important unless it is so egregiously wasteful that it becomes a bottleneck itself. You know your system is at least close to being architected correctly when the bottlenecks are in the places you expect (e.g., in bringing the code and the data together, or in actually applying the operations across the data).
When code is not part of dealing with a critical bottleneck, it is best to optimize for the performance of the people maintaining the code in the future.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla You knew exactly what language we were talking about, because only in C# is the memory location of objects implementation-defined. Bullshit cop-out is bullshit.
Actually, the language specification for C and C++ don't define things like stack and heap. The languages are intended to be portable even to architectures and OSes that don't support those.
C++ in particular sets requirements for the lifetime of objects, and certain types of lifetime requirements better fit certain memory allocation strategies where supported, but the use of a stack and heap memory structures are very much implementaron details.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
Look, you're obsessed with the micro-optimization of stack vs heap. That's way way way down on the list of things that usually matter for performance anyways.
At the language level, everything matters. If you want your language to be general purpose, it has to fit as many use cases within the paradigm as possible. In Rust, nothing is implicitly heap-allocated; you must explicitly box heap-allocated values. This means that it can stay high-performance in cases where it does matter, and has an option for low performance where it doesn't matter. The language decisions you are advocating for are the sort of language decisions that brought us JS.
There are a lot of reasons to like js over rust for certain applications. Most software that people write doesn't need that level of micro management, even though it's useful and maybe even necessary for certain applications.
You're fixated on your new toy and are having a bit of a Blub episode.
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
There are a lot of reasons to like js over rust for certain applications.
I declare that there is not one single application where JS would do better than Rust.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
There are a lot of reasons to like js over rust for certain applications.
I declare that there is not one single application where JS would do better than Rust.
No one gives a shit.
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
There are a lot of reasons to like js over rust for certain applications.
I declare that there is not one single application where JS would do better than Rust.
No one gives a shit.
And yet you're still responding to me.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
There are a lot of reasons to like js over rust for certain applications.
I declare that there is not one single application where JS would do better than Rust.
No one gives a shit.
And yet you're still responding to me.
Oh, I mean that no one cares that you have a ridiculous opinion about your favorite programming language. It's still fun to respond to you.
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
There are a lot of reasons to like js over rust for certain applications.
I declare that there is not one single application where JS would do better than Rust.
No one gives a shit.
And yet you're still responding to me.
Oh, I mean that no one cares that you have a ridiculous opinion about your favorite programming language. It's still fun to respond to you.
Well, can you give me one single instance where JS is better than Rust?
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
There are a lot of reasons to like js over rust for certain applications.
I declare that there is not one single application where JS would do better than Rust.
How do you define "do better"? Because I imagine that if you have a bunch of js developers already, almost anything you could want them to do would be better served by using js than introducing Rust.
-
@Kian I'm not talking about the developers. That's the employer's fault for hiring JS developers. I'm talking about ideal software solutions.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla said in Google Cloud Platform and near-perfect documentation:
There are a lot of reasons to like js over rust for certain applications.
I declare that there is not one single application where JS would do better than Rust.
No one gives a shit.
And yet you're still responding to me.
Oh, I mean that no one cares that you have a ridiculous opinion about your favorite programming language. It's still fun to respond to you.
Well, can you give me one single instance where JS is better than Rust?
All the times I don't want to micromanage object lifetimes. You're arguing to way overcomplicate things.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@Kian I'm not talking about the developers. That's the employer's fault for hiring JS developers. I'm talking about ideal software solutions.
What's the difference? No one wants to hand around a bunch of rust devs.
-
@boomzilla Easy.
box obj
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@Kian I'm not talking about the developers. That's the employer's fault for hiring JS developers. I'm talking about ideal software solutions.
Programming languages are created for developers. If we are talking about ideal software not written by developers, then pure binary wins and Rust is unnecessary from the start. Just write a single stream of binary that when executed provides the desired results.
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla Easy.
box obj
Oh, god, I looked up what that does. Now we have to dereference pointers all over the place? I thought you said this was easy!
-
@boomzilla said in Google Cloud Platform and near-perfect documentation:
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@boomzilla Easy.
box obj
Oh, god, I looked up what that does.
Just remember to take a tetanus shot and you should be fine.
-
@pie_flavor I have a small piece of JS in one of my projects. It does the following:
- From a value in the DOM, decide what comparison method to use.
- Also from the DOM, extract the "correct" answer.
- On button press, take user input (in an
<input>
element) and apply the comparison method between the user input and the "correct" answer.
3.5 Report the correctness to the user by changing the DOM, adding classes to things as needed. - Store a key-value pair (a key relating to the assignment and question and a boolean correctness value) in LocalStorage.
- When the user submits the assignment, send an ajax request with the % of questions correct, the (user-input) name and an assignment-fixed secret and report the success value by altering the DOM.
It does this entirely client side, and works on all browsers (including mobile). All in about 150 lines of (crappy, because I'm no expert) JS. And I did this while learning JS, HTML, and CSS from scratch.
How painful would this be to do in Rust, especially for a novice? Could it even be done client side (without having to pass compiled data around)?
-
@Benjamin-Hall said in Google Cloud Platform and near-perfect documentation:
(without having to pass compiled data around)
Yee-haw for arbitrary limitations!
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@Benjamin-Hall said in Google Cloud Platform and near-perfect documentation:
(without having to pass compiled data around)
Yee-haw for arbitrary limitations!
The main target browser is mobile safari, which has extremely stringent requirements on what binary executable data you can use. So not arbitrary at all.
Also--can Rust code even run directly in a browser? I can't find any evidence that it can except when compiled to WebAssembly...which does not exactly have very good support (especially by Apple products). So 99.9999999999999% of the real use of Javascript (supporting web pages in a browser) are completely out of scope for Rust.
-
Speaking of documentation. I'm using Apache POI to build Excel workbooks. I know the API is...involved, so I check which version I'm using (3.0.2) and download the docs from Apache. And yet...they don't fucking match what I'm actually seeing. For instance, I see this method in the API docs:
public int addMergedRegion(int rowFrom, short colFrom, int rowTo, short colTo)
But apparently the code only has the version where you pass a
Region
object (which you can create using those same parameters) instead of the row and column numbers. How did they even build the javadocs?
-
@Benjamin-Hall Yes, the correct answer was WebAssembly. Both Safari and Safari iOS have full WebAssembly support.
-
@boomzilla https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Sheet.html#addMergedRegion-org.apache.poi.ss.util.CellRangeAddress-
-
@pie_flavor said in Google Cloud Platform and near-perfect documentation:
@Benjamin-Hall Yes, the correct answer was WebAssembly. Both Safari and Safari iOS have full WebAssembly support.
So I'd need a compiler, learn a horribly-obfuscated language (yes, rust is full of colon cancer just like C++), learn a separate set of APIs (both webAssembly and the DOM), and for what benefit?
These were small scripts to get called locally. Chance of meaningful resource leakage: 0%. Chance of incorrect behavior: 0% for actual program errors, 100% for logic errors (which rust doesn't help with).
In addition, to call these WebAssembly functions, I'd still need to learn JS, because that's the interface. So you're talking about orders of magnitude more work, with absolutely no benefit. It's the cost of learning/making the JS thing + the cost of learning rust and making the packages there.
I see no benefit and lots of downside.