41–50 of 59 posts
Pet peeve: tech articles/blogs which do not prominently display when the article was written. This is the single most important fact I search for before reading time sensitive tech info. I can't tell when this was written, am I missing something?
Earlier quoted context omitted.
Same with Php, using really old versions of it. This is a waste of time article, nothing is learned from it appart the bias of the author.
Ummmm when you care about I/O performance and your building anything of substance (something more than what nginx can do on it's own) why would you choose PHP? The security, fragility and un-maintainability alone are enough reasons to avoid it.
I was reading the article until a giant fullscreen ad popped up and I had to close the tab. Sorry, no thanks.
Earlier quoted context omitted.
No, it's not the only thing that matters. Java's compiled too and was included here, but Go still beat it out. It's likely that C or Rust or C++ would be much faster than Java or Go since they have large runtime overheads; it turns out having a runtime and how heavy it is matter too, not just if it's compiled. There are also cases where non-compiled languages can beat out compiled ones. For example, lua with LuaJIT i…
Java is compile to bytecode which is then interpreted by a virtual machine, it's not compiled to native code, that's why you cannot distribute Java programs as executable like go.
I was reading the article until a giant fullscreen ad popped up and I had to close the tab. Sorry, no thanks.
Earlier quoted context omitted.
https://nikhilm.github.io/uvbook/filesystem.html > The libuv filesystem operations are different from socket operations. Socket operations use the non-blocking operations provided by the operating system. Filesystem operations use blocking functions internally, but invoke these functions in a thread pool and notify watchers registered with the event loop when application interaction is required.
I'm not familiar with libuv but is there a dedicated "watcher" thread in a thread pool that the kernel wakes up when when the disk driver has completed that I/O that it was sleeping on? If so is there a dedicated "watcher" thread for each non-blocking I/O request handled by libuv?
When the operation is finished, then they become runnable again so the kernel scheduler runs them--that is, it runs the code that comes after the I/O operation.
This code (from libuv) notifies the requester that the operation is complete.
Earlier quoted context omitted.
No, it's not the only thing that matters. Java's compiled too and was included here, but Go still beat it out. It's likely that C or Rust or C++ would be much faster than Java or Go since they have large runtime overheads; it turns out having a runtime and how heavy it is matter too, not just if it's compiled. There are also cases where non-compiled languages can beat out compiled ones. For example, lua with LuaJIT i…
Java is compile to bytecode which is then interpreted by a virtual machine, it's not compiled to native code, that's why you cannot distribute Java programs as executable like go.
Java has a specification and has lots of implementations.
The majority of commercial implementations of Java have native code compilers, and Oracle is in the process of improving the AOT compiler introduced in Java 9.
Earlier quoted context omitted.
No, it's not the only thing that matters. Java's compiled too and was included here, but Go still beat it out. It's likely that C or Rust or C++ would be much faster than Java or Go since they have large runtime overheads; it turns out having a runtime and how heavy it is matter too, not just if it's compiled. There are also cases where non-compiled languages can beat out compiled ones. For example, lua with LuaJIT i…
Java is compile to bytecode which is then interpreted by a virtual machine, it's not compiled to native code, that's why you cannot distribute Java programs as executable like go.