Everyone should experience the x220 keyboard. It's probably the best laptop keyboard I've experienced.
The x230 onward is also extremely good.
The trick for me is key travel. I bought a new Thinkpad that had 1.3mm of travel and instantly hated it. 1.5mm feels so so much better (not to mention 1.8mm). No new thinkpads have above 1.3mm I believe (in the pursuit of thinness).
I posted something along the lines of "games are too easy to make" on reddit and got expectedly lambasted. My fault, don't tell people with new found ability that the only reason they have it is because it's 100 times easier than it used to be.
A long time ago, I got interested in computers to make games but immediately veered into other kinds of software. No worries - I always planned that once I was "done" in the application/startup space, I'd head back and make those games.
Sadly - I waited too long. Like music, books, or photography - the supply-side is so inundated with content that the market is more about marketing than creation or merit. Mind you, never did I expect or even care if I made money. That was never the goal. But now I realize just to get some people to play my game would be a huge undertaking requiring tons of luck - just to rise above the noise. That was the deal breaker - I don't care about making money - but I do care about eventual players, at least if something will take months or years* to create. I wanted to make games, not do marketing.
The bright side is there's no shortage of fun games to play. I'll stay on the player side of the equation!
*Wouldn't be surprised if something like ChatGPT allows games to be made in days in the semi-near future. If so, I just might make games anyway - still not for money, and now not for players - but just to finally let those ideas out of my head.
Oh yes - Our system ended up being good for several hundred or several thousand (don't recall) transactions per second.
Bob called me after Zuck's announcement that the system hit a peak of (wait for it), 5 transactions per second. And that for only a very short time. The system was mostly only loaded with a transaction every few seconds (or maybe even minutes)
The Ruby version would have been fine. Heck, we probably could have just printed the transactions to some screen and have someone write them down at that speed.
People loved Bob, it was truly just a magic he had.
In 2010, Zuck gave a lot of money to NJ schools. For reasons completely unknown to me, Bob, who was at Square at the time, was given the task of writing the code to accept the donations that would be given from the public alongside Zuck's gift. For reasons also completely unknown to me, Bob called me and asked me to help write the code. We had something like 3 days. I was working at my own startup at the time but was excited to go work on this one-off with Bob.
We had worked together at Google and spent a lot of time in the Java community thereafter. We were both Java geeks at the time, but I was confused why he couldn't find anyone at Square.
In any case - I went to Square each day for 3(?) days. I remember that we didn't need to process the transactions (thank goodness), but we just needed to validate and log them which made the problem much much easier. Bob insisted we write each transaction to 3 different machines for redundancy. He also insisted we used fsync which ensured the disk writes actually happened and didn't just get left in an output buffer. He was absolutely right, but I remember being saddened how much slower it made our system.
We finished the system with time to spare. Unbeknownst to me (and maybe Bob I guess) another team at Square also implemented the system in Ruby in competition with us. I recall them being rather "anti-Java" at the time.
In any case, we then benchmarked both systems and unsurprisingly, the Java version was many times faster than the Ruby version (in transactions stored per second). Of course, apart from fsync, this was also not just Java code - it was CrazyBob's Java code which wasted nothing. I really had a blast working on that project with him.
I now realize I really don't know so many finer points of why many of these decisions were made. If any early Square folks were there for this, I'd be interested in what you remember.
Last year I upgraded to a Thinkpad Carbon. Almost immediately, I couldn't stand the keyboard. This sent me down a rabbit-hole of what was wrong with the keyboard (as it looked almost identical to my previous Thinkpad).
The answer is that Thinkpad has slowly evolved their keyboards to be slimmer. Reducing the travel on the keys with each step.
Some of the new ones are down to 1.3mm of travel. I realize this is a personal preference, but I noticeably make more errors under anything less than 1.8mm of travel.
Hence, I got rid of the Carbon and bought a Thinkpad T14 Gen 2 which is pretty much the latest model with 1.8mm. The Gen 3 was available, but they trimmed it down to 1.5mm.
I realize this is a pretty picky hill to die on, but I can't express how significant it is for the reliable use of keyboard for me. I'll be buying T14 Gen 2's until I die it seems from here on out. Everything else about the laptop is just fine. Runs any linux I throw at it, 4k screen if desired, all the upgrade-ability I might want.
(If you get lucky, you can even find one with a proper Ethernet port. Some come without because apparently during the chip-shortage, they removed that feature)
A Ph.D. really is about the journey. I'd be surprised if anyone ever thought it represented more money. It's unlikely to matter for that.
The time I spent getting a Ph.D. was one of the best times of my life. Not just the work, but the environment, the other people in the same situation, and the personal growth. I pursued it because 1) I really did love learning about Computers, and 2) I just loved the University environment. Every time I "graduated" I just signed up again for the next degree.
I never thought much about "using it" after I got it. I think it got me a higher starting title at a company or two and impressed a few (probably easily impressed) people along the way. I think the most measurable* impact however was listing it on my dating profile.
Again - it was a journey worth taking without much thought of the destination.
>I don’t think many of these people will have trouble finding a job. After all - they most likely grinded the fuck out of leetcode and system design to get in. That type of persona to do hundreds of problems doesn’t easily waver in the face of minor adversity.
Not sure you meant it, but this is an inadvertent attestation for "leetcode". As in, it's not about the leetcode, it's about the type of person that masters the leetcode.
In the context of "History doesn't repeat, but it rhymes", this is just what happened when Java appeared. Everyone noting it was written in Java (as, believe it or not, it was the cool new language).
It might have actually been worse, because there was a strong penchant for naming products starting with a "J" to indicate the fact (i.e. JNotepad, JDatabase, etc).
It might actually be a good marketing technique to get other Rust aficionados to try your product. But otherwise, there isn't any real value now that "write once, run anywhere" doesn't just belong to Java anymore.
Indeed. Shutoff Garbage collection completely and it can work. (And make sure your Java code creates no garbage - which is a new type of programming in and of itself)
To be fair, Mailinator https://www.mailinator.com has been around since it's inception in 2003. It offers other services now, but the "disposable email" part is still there as it was from the start.
I think we're in agreement. Ignoring under the hood - Loom's programming paradigm (from the viewpoint of control flow) is the Threading programming paradigm. (Virtual)Thread-per-connection programming is easier and far more intuitive than asynchronous (i.e. callback-esque) programming.
I still attest though - The 5M connections in this example is still a red herring.
Can we get to 6M? Can we get to 10M? Is that a question for Loom or Java's asynchronous IO system? No - it's a question for the operating system.
Loom and Java NIO can handle probably a billion connections as programmed. Java Threads cannot - although that too is a broken statement. "Linux Threads cannot" is the real statement. You can't have that many for resource reasons. Java Threads are just a thin abstraction on top of that.
Linux out of the box can't do 5M connections (last I checked). It takes Linux tuning artistry to get it there.
Don't get me wrong - I think Loom is cool. It's attempted to do the same thing as Async/Await tried - just better. But it is most definitely not the only way to achieve 5MM connections with Java or anything else. Possibly however, it's the most friendly and intuitive way to do it.
*We typically vilify Java Threads for the Ram they consume. Something like 1M per thread or something (tunable). Loom must still use "some" ram per connection although surely far far less (and of course Linux must use some amount of kernel ram per connection too).
Loom sets out to give you a sane programming paradigm similar to what threads do (i.e. as opposed to programming asynchronous I/O in Java with some type of callback) without the overhead of Operating System threads.
That's a very cool and a noble pursuit. But the title of this article might as well have been "5M persistent connections with Linux" because that's where the magic 5M connections happen.
I could also attempt 5M connections at the Java level using Netty and asynchronous IO - no threads or Loom. Again, it'd take more Linux configuration than anything else. If that configuration did happen though now you can also do it in C# async/await, javascript, I'm sure Erlang and anything else that does Asynchronous I/O whether it's masked by something like Loom/Async/Await or not.
The biggest thing they're bringing to the table is the (supposed and impending) funding. The idea itself is nearly worthless until executed.
Good Tech Founders ARE the hardest founding team members to find.
If you accept notably less, you're always a lesser member of the team. The best founding team keeps equity and salary equal. That's the least chance for friction and resentment.