Hamid

What a great moment to be a technical founder seeking an idea. Godspeed 🫡

i hate how well asking myself "if i had 10x the agency i have what would i do" works

@zenorocha Ability to receive emails

What should Resend build/improve/fix in 2025?

I'd love to use @resend for a project I'm building but they don't support receiving emails (any ETAs for this feature). Currently considering @SendGrid, but it's not as developer friend as resend, any other suggestions?

@charlescormier0 @ycombinator the difficult thing is getting good enough traction before actually sending the application

@hmdai_ @ycombinator intriguing idea. what's your experience been applying so far?

if you are applying to @ycombinator, this might increase your chances. Wanna try it? comment on this post and I will send you the link.

I'm still not quite sure which decisions I made in life led to me doing something I never thought I'd do: starring in a commercial

@posthog @makwarth , curious to know your thoughts on this

The real Holy Grail

@lemire I would appreciated if you would write a little about how Bun handles this scenario?

The fast JavaScript runtime Bun is much faster than Node.js 22 at decoding Base64 inputs. By much faster, I mean *several times* faster. But they both rely on the same underlying library (simdutf) for the actual decoding. So what gives? The problem is that Node.js needs to interact with v8, the underlying JavaScript engine (from Google)... and doing so is not trivial. Before we can start decoding the string, we need to grab the string... so, in this instance, we call String::Value... In turns, this allocates an array inside Node.js and asks v8 to copy the content to it... In an ideal world, we would avoid the trouble entirely and just ask v8 to give us direct access to how it stores the string... and we try to do that if we can... but let me come back to it... How bad can this be, right? Just a copy. Well. Let us do some profiling... So you see, the base64 decoding itself is about about 1/5 of the running time, but the copy takes half of it. What is up with this CopyChars function? Well, it is mostly just a wrapper around the standard high level C++ function std::copy_n as far as I can tell. (see v8/src/utils/memcopy.h) But we are copying for an 8-bit input to a 16-bit output... why is that? Base64 is pure ASCII... and v8 can store ASCII using 8-bit per character. We get there before both IsExternalOneByte() and IsOneByte() are false (see node/src/node_buffer.cc)... We have fast paths for these cases. If IsExternalOneByte() is true, we just get the bytes and everything is great. Unfortunately, it does not always work. So we have a v8 string that is really pure ASCII, but, seemingly, we can't tell that it is the case from Node.js, and so we have to convert it to UTF-16 needlessly, using a function that is maybe not very well optimized... and then we do the base64 decoding of an ASCII string from the UTF-16 input. It is not great. To be fair, this is just one string, created as 'Buffer.alloc(size, "latin1").toString("base64")', basically the base64 encoded version of the string "latin1latin1latin1...". In actual applications, we might have better luck. Yet. Yet. I am telling this complicated story for a reason. The story illustrates why our software is slower than it should be. We have layers of abstractions to fight against. Sometimes you win, sometimes you lose. These layers are there for a reason, but they are not free. To make matters worse... these abstraction layers often thicken over time... and the friction goes up. To be clear, I do not claim that the Node.js code is optimal. In fact, I know it can be better. But it is not trivial to make it go fast. I sometimes hear people say... "well, it is C++ and C++ is hard". No. The C++ part is easy relatively speaking. The difficulty is at a higher level. It is not a matter of syntax. It is a matter of architecture.

@deutventures @ycombinator Hi @deutventures , thanks for trying it out. Let me have a look and get back to you.

@hmdai_ @ycombinator Hi! i tried to use it, but am getting an empty page. Can you look into this?

@ycombinator's demo day is a brilliant display of how startups can show great progress in such a short time. I wanted to see this progress on a daily basis, so I created Y Scraper, a tool to watch the evolution of YC batch W24 companies from the changes in their websites: curved-locust-c486.hiku.app Made with @hiku_dev

For sometime I wanted to write about the annoying things about the internet and what I'm doing to fix them. So here's the first draft: hmd.ai/blog/i-hate-wh…

One in three B2B startups pivots at least once before finding their winning idea. And about one in five B2C startups. @Amplitude started as a hands-free texting app called Sonalight @Loom started as an expert marketplace called Openvid @Pinterest started as an online retail catalog app called Tote @Headspace started as a meditation event business @HuggingFace started as an AI tamagotchi In today's newsletter, I dig into the data to share: 1. Why pivot 2. How long to wait to pivot 3. The two signs it’s time to pivot 4. The two types of pivots 5. To pivot or to stay the course Link to post in comment below.

It's been exactly 6 years since the first commit to @deno_land! Now there are over 11k commits, 92k stars, and 7k closed issues 😮 github.com/denoland/deno/…

It's hard to predict what AI will do to the world, but that's all the more reason to learn to program. AI may churn up any industry, but the programmers have the best chance of surfing on this wave instead of having it crash on their heads.

Why JavaScript?

@t_blom Can you (or anyone else) share a few examples of these tedious processes. I'm in the discovery process myself and I'm curious to hear others

I’m trying to figure out why so many startups are focusing on sales automation at the moment. At big companies, there are thousands of tedious, manual processes that are performed over-and-over by huge teams of people paid close to minimum wage. But most young programmers never encounter these processes - they’re hidden away in the metaphorical “back office”. You do find rare cases where they took a summer job at a big company - sometimes resulting in fascinating HN posts entitled “how I automated my 9-5”. But that’s the exception. When most founders are looking for things to automate, they look at the external surface of these large companies - and sales is the first external interface they hit. It’s not a bad idea, it’s just a common one. I’d encourage aspiring founders to scratch beneath the surface a little.

@harjtaggar The idea that Tesla could be A/B testing self-driving with an over the air update is kind of terrifying though

Tesla Full Self-Driving drove me to and from work this morning (Palo Alto -> SF). It worked amazingly well and still blows my mind it was an over the air software update. What a time to be alive.

I'm already a fan 😂

@PratapRanade @ycombinator @sama @paulg @gralston @collision @garrytan @mwseibel @PratapRanade would you say something like kimono could still be interesting to build with AI features? (there are probably a few of thin wrappers already, but not sure if it could become a business )

With @ycombinator demo day coming up this weekend, I wanted to reflect on what I learned from YC W14, 10 years on + another company in: 1. The 7 minute espresso rule. Our first meeting with @sama lasted just 7 minutes. The batch hadn’t even officially started yet and my cofounder @ryanrrowe and I drove down from Mountain View to the tiny SF YC outpost to meet him. Sam was making an espresso when we walked in. He opened with – “have you launched”? We said no, too many bugs. Our product @kimonolabs made it easy to just point and click to build a web scraper. Our promise was to get you an API in 60 seconds, without code. But it only worked on a handful of sites at the time. Sam pushed us to launched in 2 weeks. We debated. The espresso finished brewing, he picked it up, looked at us and said, “well, you better get going then and fix those bugs”. We left, launched in 2 weeks and learned one of the most important lessons that day - speed matters. Ship something you’re embarrassed by. 2. There are no experts. Ryan and I were not prepared for the rapid influx of user on launch day. It got tons of traffic on day 1 and we didn’t sleep in the next 48 hours bc servers and database kept crashing. We realized we weren’t the experts and needed to hire one. We went over to @mwseibel for advice who smiled and told us that in the early days at SocialCam (Twitch) experts thought the streaming video problem was impossible. The answer wasn’t hiring an expert, but hiring someone young, capable and naïve enough to give it an earnest try. So we opted to just figure it out ourselves. 3. Messages in Pizza Boxes. Startups win through incredible customer service, then through product, not the other way around. Seibel told us how SocialCam’s streaming infrastructure went down while a key teammate was unreachable off-grid in a Tahoe cabin for the weekend. Normal people would have waited until Monday. Not Michael. He called a local pizza delivery place and asked the delivery person to send a large pizza with an urgent message in the box to the cabin. Their infrastructure was back up in hours. 4. The Twinkle can matter more than the TAM. Ambition matters just as much as practicality. Before demo day, we were struggling with the end of our pitch. We knew the value of our product, and had a fanatical and fast-growing user base, but the market size we calculated either seemed so ridiculously big that it was not plausible, or so narrow that it was equally silly. @paulg and @gralston sat with us and showed that us that if we can really pull it off at scale, it would be bigger than Google. PG suggested not talking about market size, but just making sure people could see the twinkle in our eyes when we talked about what you might be able to do with a structured copy of the internet that’s larger than Google’s. 5. You’re always at the Origin. Our demo day was successful beyond our wildest beliefs. Afterwards, Geoff drew a chart for us on a whiteboard. It was a hockey stick. He asked us where we thought we were. It was a rhetorical question. He said we were at the origin. Sam doubled down. When he invested in Kimono, he gave us a Zimbabwean Trillion dollar note (the result of extreme hyperinflation in Zimbabwe), as a cautionary reminder that the fundraising and valuation mean nothing. We have channeled this into our culture @TheArenaAI with our ritual around neon shoelaces and a pair of neon track spikes hanging on the wall to remind us that we’re at the Olympic starting line, but we don’t have any medals yet. 6. High bandwidth discussions with users don’t happen over email. The “Collison installation” is part of YC lore. @collision told us that talking to users live was essential because email and chat conversations were just not enough. We did 100s of Skype conversations with Kimono users + one power user Alex Chung, who I met this way, has become a close friend and even attended my wedding in India last year!

Thanks to organisers of @copenhagenjs for inviting me to talk about Offline GPT Store (offlinegpt.store), a free and private (offline) ChatGPT alternative based on open source models. #gptstore