bluepnume

True enough. Although personally I prefer to just use regular functions rather than big inheritance chains.

Probably if nothing else, impossible to have it perform well without static typing?

In most languages you could probably solve this problem with a class. But wrapping all your numbers in a class with runtime consequences, just for a bit of extra type safety, feels quite extreme.

It's hardly odd.

"Even" just means "divisible by 2"

"2 is the only prime that is divisible by 2" "3 is the only prime that is divisible by 3" "5 is the only prime that is divisible by 5"

...

"N is the only prime that is divisible by N"

He should have at least called it eejss-sort

Runtime validate at the database boundary? Isn't it better to just do runtime validation at the api boundary instead? Then any of the types that make it into the database should be mostly guaranteed by TS (and of course, whatever types are enforced by the database schema itself).

You find it weird that a type system doesn't do runtime validation? Is that common in many other languages?

Looks like the bug was in a monkey-patched `window.fetch`

https://github.com/PostHog/posthog-js/blob/759829c67fcb8720f...

The biggest lesson here is, if you're writing a popular library that monkey-patches global functions, it needs to be really well tested.

There's a difference between "I'll throw posthog calls in a try/catch just in case" and "With posthog I literally can't make fetch() calls with POST"

The funny thing is, it was pretty clear to me he meant that as a bit of a joke.

The question on our application is "are you a fit for the JD"

For the most part, the answer is "obviously yes, that's why I'm applying", but we do get some really insightful answers here where people talk about their weaknesses too and we learn something.

But even in the call he seemed to acknowledge that was a bit of a joke, and I legit don't mind jokey bravado for the most part.

Would absolutely love to know how other engineers on HN approach interviews and assessing technical competence. I didn't _think_ I had any mis-steps here but would love to know if anyone thinks there's something I could have fixed about this whole interviewing process.

Probably the guy was just having a bad week, but all the same. Really bemused (and more than a little confused)

At this point TS is a turing complete language.

Complaining that you have to tune it for performance is like complaining that your runtime code isn't automatically maximally performant without a little tuning.

OneText | https://onetext.com | Bay Area, CA | Engineering | US (In person or remote) | Full time

We're OneText (Y Combinator W23), and we've built a product anyone pay and make purchases with a single text message. We need you to help us keep up with massive demand and scale up to the next level!

We have two roles open:

- Lead TypeScript/Node Full Stack Engineer: https://gist.github.com/bluepnume/8f2376b0893bc6b85564e73593...

- Devops/DBA Engineer: https://gist.github.com/bluepnume/c1d5a8c9e825de82c6e56227cf...

Would love to hear from you and chat if you're interested in either (or both)!

Very cool! Will you also add support for secret based 2FA codes, similar to Authy / Google Authenticator? It would be incredible to have those autofill.

But this isn't an `any -> any` case. They passed in a default value, as a string, which is the correct type for a default value for this column. Even with very strong typing they wouldn't have got a type error here right?

OneText | https://onetext.com | Bay Area, CA | Lead UX Engineer | US (In person or remote) | Full time

Apply at: https://gist.github.com/bluepnume/33f2c4be93cc20215aafd55f80...

We're OneText (Y Combinator W23), and we're trying to let anyone pay and make purchases with a single text message.

We need someone with killer UX skills to own and redefine our user experiences, including our checkout flow and our merchant dashboard.

OneText | https://onetext.com | San Fransisco CA | Lead UX Engineer | US (In person or remote) | Full time

Apply at: https://gist.github.com/bluepnume/33f2c4be93cc20215aafd55f80...

We're OneText (Y Combinator W23), and we're trying to let anyone pay and make purchases with a single text message.

We need someone with killer UX skills to own and redefine our user experiences, including our checkout flow and our merchant dashboard.

This might be a silly question, but what would be the downside of a single threaded language similar to javascript, but where every function is just 'async capable' and can always be non-blocking, with no special syntax like async/await?

So every time you call foo(); you anticipate that it might resolve immediately, or it might take some time, but it won't block any other function (unless it actually does some cpu bound operation)

And any time foo(); does something asynchronous, all of its callers, and its callers callers, become implicitly asynchronous too.

Of course you would have to have some primitive for when you actually want to do several things concurrently within the scope of a single function rather than blocking that function, but that doesn't sound too bad and in JavaScript you effectively need to use Promise.all most of the time anyway.

I'm sure there's some major downside I'm missing -- but what is it?

Amazing! Does it have an api?

...then you'll need to use a slightly less convenient way to pay? Not sure what you're angling at here.

Actually "single use phone numbers" is a service we've considered building for consumers.

Mainly because the message thread is implicitly authenticated, so no additional web login required -- and we want to allow for conversational payments, where you can ask as many questions as you need before committing to pay.

Not necessarily. "I want to pay for parking" -> "Click this link" -> quick automatic web based geolocation and redirect back to the SMS thread -> done.

Assuming you've linked a card in the past, or you have a basic browser of any kind to link one, our thing does not require a smart phone. Just SMS.

Doesn't have to be hugely phishy if you have a saved contact card with a number you trust. That's often safer than some new app or web url that is imitating another.

Totally fair. It's entirely possible to have a fallback web url here though.

It pre-fills a text message which you can send to authenticate yourself. If you don't have a saved card, you're prompted to enter one via a web url.

You can also imagine a world where you have a single phone number saved. You text it "I'm at XYZ parking lot in ABC city, how do I pay?" and it gives you the easiest possible option.

Definitely standard no. 15, but there's room for something better to win out here right?

Sure -- phishing is a huge problem, but it's also an argument to never build anything ever, because QR codes, sites, apps, emails, etc. can all easily be cloned and used as a phishing attack vector.

We built a startup.

You scan a QR code, that sends a text message. If you have a saved card, you pay in the text thread by replying 'pay now', if not you get a link to save a new card.

No apps required. Hoping that with enough adoption, it will obviate the need for experiences as bad as this.

Eh. Just treat Bun as a testing ground for (very) experimental new features. It's no secret that the project moves very quickly, and anything that gains enough traction can be folded back into the spec.