fooyc

12 ms·

91.
by fooyc 10y ago
Confluent relies on it for their non-Java clients (Python, Go, .Net at least).
92.
by fooyc 10y ago
Here is a link to Truffle, because it's not easily googleable: https://github.com/graalvm/truffle Interesting project. Maintained by Oracle, though.
93.
by fooyc 10y ago
> arrays (pretty much the only datatype in PHP...) linked-hash-map-arrays, they are :)
94.
by fooyc 10y ago
If at the same time we could move some responsibility from the client to the server, it would be awesome. Kafka gives so much responsibility to the client that most implementations are incomplete and don't cope well with state changes
95.
by fooyc 10y ago
That's the point. Calling a blocking system call is cheaper that artificially blocking on a non-blocking operation.
96.
by fooyc 10y ago
You are side-stepping the question by explaining how scheduling works. You can not say that there is NO overhead. Using async code in a synchronous fashion is not going to be as fast as using plain sync code. Look at the wait() function: h
97.
by fooyc 10y ago
> If you accept that using the async call in an asynchronous nature doesn't have overhead Obviously that's not the case. There is a lot of overhead.
98.
Let’s build a standard library (std) free of C code / dependencies for Linux(users.rust-lang.org)
2 points by fooyc 10y ago|0 comments
99.
by fooyc 10y ago
I can see a LOT of overhead here. Am I wrong ? Have you ever ran a benchmark of a wait(async_read()) compared to just sync_read() ?
100.
by fooyc 10y ago
Isn't this adding a lot of overhead compared to calling a synchronous implementation of the same code ?
101.
by fooyc 10y ago
Can you explain how you run an async function synchronously, and how it has no overhead compared to calling a synchronous implementation of the same function ?
102.
by fooyc 10y ago
Can you explain how you can make a blocking call to an async function without overhead ?
103.
by fooyc 10y ago
Using threads to make sync code async defeats the advantages of doing async code in the first place. You are writing async code to avoid threads. If you bring threads in your async code, you get the worse of both worlds: Convoluted code, an
104.
by fooyc 10y ago
You are right, I misread it. I agree that there is no visible difference in the code, and that's exactly what I like. What's different, however, is how Go routines have much less overhead than OS threads.
105.
by fooyc 10y ago
Can you explain why ?
106.
by fooyc 10y ago
In a thread, every single function call is not a separate thread. In async, every single function must be async (or be super fast and i/o-free).
107.
by fooyc 10y ago
async/await is a huge improvement over callbacks, but you still have to make sure that everything in your code is async, else you block everything. Also, it doesn't magically works with all functions, the functions have to support
108.
by fooyc 10y ago
They don't want to add abstractions to the language (e.g. Green threads). So, they are doomed to add abstractions to the libs instead, and one way to do cheap concurrency without the help of the language is to use async I/O. And b
109.
by fooyc 10y ago
About the cost of skipping the libc: Do you mean a human/development cost ? Other than that, what would rust lose for not using the libc for system calls ?
110.
by fooyc 10y ago
My point is exactly that this is what they got right
111.
by fooyc 10y ago
IIRC, a read() in Go is just a plain synchronous read() under the hood. They just let an other coroutines execute during the syscall.
112.
by fooyc 10y ago
Can you "match" on the result to destructure it as well ? Without blocking the event loop ?
113.
by fooyc 10y ago
About the cost of calling an async function synchronously: You had a call to read(). Now you have a thread, an event loop, a pooling mechanism, and a synchronization with the thread. That's much more system calls and cpu cycles, for an
114.
by fooyc 10y ago
You had a call to read(). Now you have a thread, an event loop, a pooling mechanism, and a synchronization with the thread. That's much more system calls and cpu cycles.
115.
by fooyc 10y ago
I'm doing a lot of concurrent code and Go behaves very well with tens of thousands of concurrent coroutines and network sockets. I couldn't tell the same thing about Nodejs, for instance, which is why I tried Go in the first place
116.
by fooyc 10y ago
> If the async version is easy to use Having a sync interface would make it easy to use in sync code, yes. I feel that we are far from zero cost abstractions now, though. > switch stacks Is it because the stacks in green threads is sm
117.
by fooyc 10y ago
> all of them can run from a thread pool with zero problems Until you exhaust the thread pool, in which case everything relying on the thread pool will be much longer than usual to complete. Nodejs does this for name resolving, and it&#x
118.
by fooyc 10y ago
> the Rust community in general is interested in not having this split How will you avoid having two variants of each and every lib ? E.g. redis-rs, sync, and redis-tokio, async ? > you can't interoperate with C code at zero cost
119.
by fooyc 10y ago
It IS different. In async code every single line of code must be async (or be very fast and i/o free), else you block everything. In Go, you can decide that a call frame and all its descendants will live their own life in a separate th
120.
by fooyc 10y ago
If you think I suggest to abstract sync code (like some old version of rust was seamingly doing), you are missing my point. There is just no need for async I/O. Just bring "zero-cost" multi tasking / coroutines to your l

More ›