Just want to add, I followed pretty much the same path with Windmill [1], which is also in the developer tool space, and also open-source. Built everything solo for 5 months. I thought it would be impossible to get into YC, it is not and I was fortunate enough to join YC on the latest batch, on my first try [2].
Getting into YC changed the course of the company, increased many orders of magnitude my ambition and made fundraising much easier. Most importantly, even though I worked in tech in the bay many moons ago, at the time I was very isolated in Paris and thought I understood the startup game but I did not really. Being part of a cohort like YC with like-minded amazing peers, truly felt like I was able to go up to speed on many subjects that would have been out of reach for a solo founder.
If you are a solo technical founder and considering applying to YC, reach out to me, I am more than happy to help.
No, Blake3 is a cryptographic hash algorithm, not for dictionaries or hash tables. It is intended for cryptographic signatures, file/data integrity, message authentication codes, etc.
For dictionaries/hash tables you'd typically use a very fast hash algorithm like xxHash, murmurHash, etc. Those are tuned for speed but can have collisions (typically they have very short outputs - 32 or 64 bits - so that they're easy to compare and compute with).
For cryptographic purposes (authenticity, integrity) you'd use a medium speed algorithm like SHA2/3, Blake2/3, etc. which are reasonably fast and essentially guarantee there won't be collisions (i.e. it's computationally hard to come up with collisions). These are meant to be computed quickly and potentially in parallel because you want to be able to verify data fast.
For password hashing you'd use a slow algorithm like bcrypt/scrypt or Argon2. These are designed specifically to be slow; some also use lots of memory specifically to slow down parallel attackers. You want password hashing to be relatively slow because you need to protect low-entropy data (a typical password only has a few dozen bits of security). By making the algorithm deliberately slow you would ensure that an attacker can't quickly guess the password, even if they have the hash.
These are the three major categories of hash; knowing which one to use in which application is pretty important. Don't mix them up!
I wrote the windows bits for libuv (node.js' async i/o library), so I have extensive experience with asynchronous I/O on Windows, and my experience doesn't back up parent's statement.
Yes, it's true that many APIs would theoretically allow kernel-level asynchronous I/O, but in practice the story is not so rosy.
* Asynchronous disk I/O is in practice often not actually asynchronous. Some of these cases are documented (https://support.microsoft.com/en-us/kb/156932), but asychronous I/O also actually blocks in cases that are not listed in that article (unless the disk cache is disabled). This is the reason that node.js always uses threads for file i/o.
* For sockets, the downside of the 'completion' model that windows is that the user must pre-allocate a buffer for every socket that it wants to receive data on. Open 10k sockets and allocate a 64k receive buffer for all of them - that adds up quickly. The unix epoll/kqueue/select model is much more memory-efficient.
* Many APIs may support asynchronous operation, but there are blatant omissions too. Try opening a file without blocking, or reading keyboard input.
* Windows has many different notification mechanisms, but none of them are both scalable and work for all types of events. You can use completion ports for files and sockets (the only scalable mechanism), but you need to use events for other stuff (waiting for a process to exit), and a completely different API to retrieve GUI events. That said, unix uses signals in some cases which are also near impossible to get right.
* Windows is overly modal. You can't use asynchronous operations on files that are open in synchronous mode or vice versa. That mode is fixed when the file/pipe/socket is created and can't be changed after the fact. So good luck if a parent process passes you a synchronous pipe for stdout - you must special case for all possible combinations.
* Not to mention that there aren't simple 'read' and 'write' operations that work on different types of I/O streams. Be ready to ReadFileEx(), Recv(), ReadConsoleInput() and whatnot.
IMO the Windows designers got the general idea to support asynchronous I/O right, but they completely messed up all the details.
Getting into YC changed the course of the company, increased many orders of magnitude my ambition and made fundraising much easier. Most importantly, even though I worked in tech in the bay many moons ago, at the time I was very isolated in Paris and thought I understood the startup game but I did not really. Being part of a cohort like YC with like-minded amazing peers, truly felt like I was able to go up to speed on many subjects that would have been out of reach for a solo founder.
If you are a solo technical founder and considering applying to YC, reach out to me, I am more than happy to help.
[1]: https://windmill.dev
[2]: https://news.ycombinator.com/item?id=31272793