ngrilly

15 ms·

211.
by ngrilly 3y ago
Neat. Thanks for sharing! Interestingly, may-minihttp is faring very well in the TechEmpower benchmark [1], for whatever those benchmarks are worth. The code is also surprisingly straightforward [2]. [1] https://www.techempower.c
212.
by ngrilly 3y ago
Go abandoned split stacks years ago due to the "hot split problem", and is now using contiguous stacks that are grown when necessary via stack copying. Go switches to the system stack when calling C code. There is some overhead (a
213.
by ngrilly 3y ago
You're writing that "code is written for humans " (very true) and that async/await is more readable, and when you receive feedback from other humans they find async/await slightly less readable than fibers/g
214.
by ngrilly 3y ago
Fair enough. The context is that years ago, my team was evaluating Go and Node.js as options for a server requiring concurrency, and back then Node.js didn't provide any stacktrace for async callbacks. I know it has been improved since
215.
by ngrilly 3y ago
> by default fibers should use "full" stacks, i.e. a reasonable amount of unpopulated memory pages (e.g. 2 MiB) with guard page Then wouldn't we loose the main benefit of fibers (small stacks leading to a low memory usage
216.
by ngrilly 3y ago
The main problem with fibers/goroutines and FFI is that one of the benefits of fibers is that each fiber starts with a very small stack (usually just a few kBs) unlike native threads usually starting with a much larger stack (usually e
217.
by ngrilly 3y ago
Hard agree. In my view, that's Rust #1 problem in terms of developer experience.
218.
by ngrilly 3y ago
You're right. But it was not the case years ago when my team evaluated Go and Node.js. I should have clarified.
219.
by ngrilly 3y ago
> It is important that [...] we have a high-power very systems-oriented programming language that will make that choice, because someone needs to. This is exactly why I'm looking into Zig more.
220.
by ngrilly 3y ago
> It's been trendy on HN to bash async/await, but you are missing the mist crucial point about software engineering: code is written for humans and is read much more than written. Readability can be in the eye of the beholder.
221.
by ngrilly 3y ago
When using SSD or eNVM, why would local IO be more unreliable/unpredictable than local RAM?
222.
by ngrilly 3y ago
Useful stacktraces is one of the reasons why I use Go instead of JS/TS on the server-side.
223.
by ngrilly 3y ago
I very much agree and I've seen that a lot in large companies. I really like how Bain explains it: "growth creates complexity; complexity kills growth". They talk about in The Founder's Mentality: https://medi
224.
by ngrilly 3y ago
Sounds like bad product management as much as bad engineering. I mean, the outcome — a bloated product — is bad for everyone: the users in the first place, the engineers building the product, but also the PM who can't conceivably be pr
225.
by ngrilly 3y ago
I agree on the CDN. Reading assets from files instead of a RAM cache won’t add “10-20ms”. This is measured in microseconds, not milliseconds. Most servers nowadays are using SSDs or eNVM. And as I wrote earlier, the files are likely already
226.
by ngrilly 3y ago
For anyone else wanting to read about it: https://varnish-cache.org/docs/trunk/phk/notes.html
227.
by ngrilly 3y ago
The difference of latency between serving a file cached in user-space RAM (what nano-web is doing) and serving a file from the kernel buffer cache (also in RAM) using sendfile should be totally negligible compared to the latency of your net
228.
by ngrilly 3y ago
Considering the latency between the user web browser and the server, does the “extremely low latency on account of caching all files in memory” really matter? The files should already be cached by the OS and using sendfile lets the OS copy
229.
by ngrilly 3y ago
Could you share an example of a fiber implementation not relying a fat runtime built in the language?
230.
Redesigning OLTP for a New Order of Magnitude(infoq.com)
2 points by ngrilly 3y ago|0 comments
231.
by ngrilly 3y ago
The title is a play on words: the author used “Helvetica” for “hell” :)
232.
by ngrilly 3y ago
I’m exactly like your wife :)
233.
by ngrilly 3y ago
In that list, Rust’s borrow checker only solves use-after-free and memory leaks. The other items in the list can be solved without it (null dereference, out of bounds read and write, etc.). See Zig for example.
234.
by ngrilly 3y ago
I like that the article explains why Rust is great for memory safety, but won't solve everything. It also shows how to write memory safe programs in new low-level languages like Zig, offering spatial memory safety, combined to arenas a
235.
by ngrilly 3y ago
The post says: > Joined by Dr. Richard Hipp, creator of SQLite, we are building a distributed, scalable, high concurrency cloud database on top of 100% open source SQLite. How exactly is Dr. Richard Hipp involved in this?
236.
by ngrilly 3y ago
You're moving the goalpost. That conversation started when you explained that you'd rather use something you know than let some corporation manage you biometric data. But it's simply not true that some corporation is managing
237.
by ngrilly 3y ago
I used to do that, but then I realized that a temporary or permanent loss of memory can happen after an accident or a trauma. I'm still on the fence about this (keep this only in my memory, or have a physical copy somewhere).
238.
by ngrilly 3y ago
The question was "do *you* still use TOTP when using passkeys". I answered "no" because *I* don't use TOPT with my passkeys, but I'm not saying it's not possible or that you shouldn't do it. Personall
239.
by ngrilly 3y ago
Agreed. But then what is the point you were trying to make when asking "You think that there's data on a networked device that is absolutely safe?"?
240.
by ngrilly 3y ago
Do you use keep your secrets in an offline database that is on a non-networked/air-gapped device?

More ›