bluepnume

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.

In that case what's the point of any type system at all? Any type can be cast to another. If you don't just arbitrarily cast whenever you like, unknown is extremely useful to remind you to type check or parse before you use a value.

Those sound like the same thing to me.

The alternative is just to leave the promise as rejected, and expect the developer to .catch when they're ready.

Isn't that exactly what the xkcd covers?

Also a great way to share cookies, avoid CORS, and probably a zillion other complexities that result from running on multiple subdomains.

Get into calls with some of the investors who want to talk to you, and ask them exactly what they would do in your position.

Some of them will bullshit you, others will give honest advice. Figuring out which is which is a skill that can't really be taught, you've just got to take meetings and practice.

We're two former leads formerly from the PayPal Checkout team (engineering & product), we just got pre-seed funding for our new startup which we launched earlier this year, and we're looking for an engineer to join us!

Our goal is simple: to make it possible to use your phone number to pay, anywhere and everywhere, with zero friction. We have a ton of cool ways to make that work, and a bunch of brands already using our platform.

Email: hello@onetext.com

Our stack:

- Front-end: JS/TS/React

- API: Node/TS/Postgres/Redis

- Services: Shopify/Twilio/PayPal/Stripe/Authorize.net

What we do: payments, vaulting, automated conversations, and merchant-facing dashboards. Plus a whole load of interesting things in-between.

Most important skill: be able to communicate well, and learn quickly. Doesn't matter if you haven't used every technology listed above, so long as you're a fast learner and happy to jump quickly into new things.

Experience level: any. So long as you can code, if we like you and you're a good fit, we'll find a role for you.

Expectations: it's a startup, and we just got accepted into YCombinator 2023. So it will be busy, there's no avoiding that. But we want to create a great engineering culture that fosters innovation, learning, and mentorship. We want to teach, and we want to learn from you too.

Location: we're both CA (bay area), open to remote anywhere in US, may be able to make non-US work with some kind of contracting role but priority given to US-based folk. Not sponsoring Visas.

Salary: completely dependent on experience and skill. Equity on the table.

Send us an email about yourself!

Quite often the best thing to do is:

1. Wait until TS complains about a possible null

2. If you have a good default value, use that instead

3. If not, throw a meaningful error

Either way, don't propagate the nulls further than they need to go.

> it’s important to remember that TypeScript does not provide any assurances about a variable’s runtime type, especially if the data is coming from an external source (like an API). In those cases, you often need to use type assertions or guards anyway to assert the returned type because TypeScript can’t infer the type of dynamically fetched data. So destructuring the data is more dangerous than defensive coding (like using the optional chaining operator or good-old if statements).

Optional chaining or null checks should not be used "defensively". They should just be used whenever TypeScript tells you to. Otherwise you just exacerbate the problem and end up with more unanticipated null values.

If you're dealing with an API with untrustworthy types or lots of null values, the solution is to:

a) Write mostly optional type definitions for that API, and/or

b) Use zod to verify the API data before you use it, to make sure it matches your expectations.

https://github.com/colinhacks/zod

Designed for browsers but... presumably can be run in Node? I'm thinking this would be perfect for tests, to avoid spinning up a standalone postgres server every time.

I was a long time Flow hold-out, switched to TypeScript a year ago and never looked back.

There are a few things I miss, and a few things that Flow did do better; TS is obviously not perfect. But it's a real joy to use.

As for people writing JS in 2022 without any kind of static typing: I fear for you.

Yes. Please. And soon.

Full disclosure: I'm a bitcoiner.

That said -- I feel that any arguments along the lines of "humanity should use less energy" are doomed to failure. More technology, a larger population, and third world nations developing into first world nations, and the world's energy usage is only going to go up. It's not a question of whether that's good or bad, it's just inevitable.

The number one goal of humanity should be to find or create clean sources of energy that give us orders of magnitude more supply than there is demand.

Then we can stop arguing about which uses of energy are legitimate and which aren't.

The language really does sound like "pay only if/when you get a job".

I built fetch-robot (https://github.com/krakenjs/fetch-robot) to avoid dealing with CORS preflight requests. And the associated maze of request and response headers you need to use to negotiate in the preflight.

Sure, but we can divert some of that energy to power wind turbines, which ought to cool things down a bit.

Simple: it's the job of a good line manager to embed and ingratiate themselves well enough with those doing the engineering work, that at any point they can give a reasonable estimate for how long a certain thing is going to take when asked middle or upper management. That is, WITHOUT adding extra process.

> I quoted the First Law of Mentat at her: ‘A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.’

This was my attempt to understand and implement the Y combinator a while back: https://gist.github.com/bluepnume/6973b6efb7d48edcbf19

Love this idea. Hope you don't mind if I pitch this to our team.

This is great. We're actually considering building a product like this at OneText.

1. You get a virtual card number to use for subscriptions

2. We detect recurring charges

3. We send you a text 24h before any refills

4. If you reply 'skip' we block the next charge, if you reply 'cancel' we cancel the card entirely

I love this model. I have a movie ticket subscription that does this too if I don't use the ticket.

Yeah, with Amazon, it's always a step during the checkout, with a very small opt-out button. And it often advertizes itself as being more about free shipping than setting up a prime subscription. Pretty easy to miss!

Totally fair. But my goal would be to make it so you don't have to guess. If your response can't be automatically handled, it should fall back to a human who can do exactly what you need.

Take a cart recovery: If I send you a link, I'm just blindly assuming you forgot and your only objective is to complete your purchase.

But if I ask you a question, there's an opportunity for you to tell me one of the myriad of things you actually want. You may want to complete your purchase, or schedule it for another day, or check the delivery time first, or change what you ordered -- or even just opt out of texts.

Honestly most brands so far are perfectly happy having a new number specifically for SMS.

Campaign registration and 10DLC stuff is annoying but not the end of the world. Honestly, we prefer doing real-time messaging based on user events rather than mass-campaigns, so it's less of a problem when you're spreading messages out that way.

We've actually found a mixture of automatic replies, backed up by a human, is the way to go.

1. Do it manually

2. Automate the common cases

3. Goto 1

The other trick is to build good tools to make it stupid-simple for an agent to do the complicated part, like setting up a subscription or a scheduled order.

Right. They're not mutually exclusive -- hence the "both, either, or neither"

If this compiles, <something> is an expression:

    let x = <something>;

If this compiles, <something> is a statement:

    <something>;

Both, either, or neither can be true.

"Shut up and calculate" is misattributed to Feynman.

Makes sense -- but if you're saying "the electron travels through both slits at the same time because it is a wave", then why can't we detect that wave simultaneously at both slits?

At that point of measurement/detection we HAVE to start talking about probabilities, not just waves, right?