Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
typosaurus12198136dI don't think js spawns threads. If that were true, people wouldn't complain about js being single threaded. Promises are way cooler than threads. Easy to get data out. Threads don't have that as you describe.
The uvlib that js uses that Ive investigated after your previous post does provide threading tho.
In C I would just supply a string with descriptions "%d%f" or smth and an array of voids to give dynamic arguments. Can't you just convert all arguments to bytes and combine it as one big var that thread will accept and unpack later? -
Demolishun35063136d@retoor I honestly don't want browsers to run multthreaded apps. Can you imagine the bullshit with that? Bogging whole fucking computer down because someone spawned a buncha resource heavy shit in the browser. Imagine Chrome resource sucking x10 or x100.
-
Lensflare17494136dasync/await is the most optimal way to do async (if it’s built into the language and is not some half assed 3rd party lib)!
-
Demolishun35063136d@Lensflare are there compilers that allow you to create modules for the compiler that can be loaded when compiling other code? Like some kind of extensible compiler system. Then you could extend the language perhaps.
Not sure if plausible at all. -
Demolishun35063136d@Lensflare looks like someone thought of this before:
https://read.seas.harvard.edu/~kohl...
https://stackoverflow.com/questions... -
Lensflare17494136d@Demolishun yes, Swift has that. It’s called plugins.
Not sure about other languages. -
Demolishun35063136d@Wisecrack now imagine each of those spinning up a bunch of threads. For now they are limited to one cpu.
-
kobenz868135dbtw, @jestdotty, maybe scheme continuations is what you're after. I'm not sure, but maybe Rusty's macro systems is enough to implement it
-
typosaurus12198135d@Demolishun Yes, JIT, compilation of script directly to machine code. I know how to build it in C now. It's funny. Did you know you can just get C function code by this?
size_t * size = (char *)main - (char *)your_function;
char machinecode[length]
memcpy(&machinecode, (char *)your_function, size)
I have no idea why to substract main from it. Maybe a different function would also work? Header size or smth?
There's also a very nice way to print it in 0x23 0x56 format if you're interested i'll look it up. I have it somewhere.
But that code, you can store it in memory (mmap) and also execute it from there.
fptr pony = (* () (*int,int))mmapped_thingy.
Now you have a JIT :) -
kobenz868133d@jestdotty hmmm 🤔 maybe it'd be expensive learning scheme just for that.
You could use fibers then!
They're already made available by the kernel and cost very little.
---
there's also a nice and tiny fibers implementation already done by Calvin Rose over at janet-lang.
https://github.com/janet-lang/...
Your C Is better than mine, I bet you could make that Rust in no time -
Wisecrack9481132d@retoor so what you're saying is every browser is carrying around a c compiler bundled with it?
-
AlgoRythm50254131dI agree. Promises are a really excellent backwards compatible solution.
However, they don’t have anything to do with performance whatsoever -
typosaurus12198130d@Wisecrack almost yes. There's a new language performance video from Lunduke on YT btw. C still kicks everyone's ass! Yes, also Rust, not by much
-
Wisecrack9481119d@retoor "yes also rust, not by much."
Like removing the guardrails from a nine hundred foot cliff face tourist attraction.
If you want to get really close to the edge, it is the only way to do it. -
kobenz868117d@Wisecrack honestly, if you reaaaaally wanna go bareback, look no further than Zig. I can't, it's too much for me
Related Rants
promises in JavaScript have really spoiled me
it's the most optimal way to do async without leaving much on the table
there's a promises library in rust and the guy who wrote it says it sucks because it spawns new thread every time you execute a bunch of promises
and I finally, through my fogged brain, managed to get the bright idea to write what I want to make in rust in JavaScript and holy hell it's sexy to work with promises. there's no performance left on the table. you do things as fast as possible
but if I take this JavaScript usability code I made and make it possible syntax-wise in rust I don't see how I would be able to do it without starting new operating system threads every time I execute any promises (or set)
I can take the overhead hit but this sounds retarded
and this isn't even touching upon how in rust everything needs to have a predetermined data type. so you can do lambdas and capture variables and send in variables into a thread that way, but to return the return object must be a consistent type (synchronizing the order data was sent in to the data sent out aside, haven't written that yet should be fine though)
which is fine if you are making a threadpool and it'll all be returning one data type
but this means you can't reuse a threadpool you made elsewhere in the program
the only thing that could fix async is to literally be compiler-enabled. it would have to work like generics and automatically make an enum of every type that can return, and only then could you re-use the threadpool
rant
threads