rattray

If you or others on this thread are interested in working on a Swift compiler for Windows, please reach out to me :) a good friend is hiring a team to make this happen.

Interesting. Asking as someone who's never programmed with Swift or Rust, but is familiar with the syntax/ideas of each, I'm curious why you say that?

interesting! what are you making with it?

Nice. I wish all the examples included user/revenue/impact numbers (like Instagram) rather than only investment/valuation information (like Notion, WhatsApp, Kylie Jenner, etc)

I'm having a hard time following -- what are some example queries you put in? Sounds interesting!

What was the task and why was it hard with express?

Wow. Can you easily change the tcp connection timeout?

Agreed.

I've been thinking of GPT as an incredibly well-read 8-year-old. Smart, but sometimes wildly silly and not yet developed in a sound understanding of the world (but getting there!)

Correct – and when creating the API Key, you'd want the API to give helpful hints about what other parts of the application use (which is trickier than it sounds).

Hey Tim, nice to see you here!

You might consider behavior more like Stripe's here (disclaimer, former member of the stripe API platform team).

As you're likely aware, Stripe defaults to the latest version for each user, and then stores that as the user's default API Version until they upgrade it at the account level.

This works pretty well, and overall I'd recommend it. It may be better to give each API Key its own default API version, since different applications may expect different versions, and API keys can be a simple way to differentiate applications.

Some of Stripe's client libraries also enforce sending a specific API version header to ensure the types are correct; my guess is that in practice, this is how most requests have their version dictated now, making the account-level setting a little anachronistic.

Everything gets trickiest when it comes to webhook bodies, since the way the payload is rendered may be different across versions, so you can have one app create an object on version A and then a different app consume the webhook under version B and see the created object with a different shape. I'm not familiar enough with GitHub's API to know how best to handle this sort of thing.

Anyway, good luck and happy to chat more.

In this case, I'm concerned that they're particularly naive to think that writing only parts of ESLint in Rust will be a win.

My impression -- no firsthand experience -- is that the ser/des costs associated with FFI between node and rust when dealing with large objects like ASTs can eliminate most wins, especially if you have to go back and forth multiple times.

Related: https://zaplib.com/docs/blog_post_mortem.html

I'm also under the impression that most of the gains from rewriting Node into Go or Rust come from getting access to multithreading, which I can't imagine working well in this context if the ESLint plugins themselves are still written in JS (which, IMO, they certainly should be). A single file will still need to run on a single thread.

(Of course, you can run different files on different cores with Workers or just subprocesses, but I assume ESLint does this already)

I have to say, I think they'd be crazy not to write the new version in TypeScript.

Choosing to use JS without TS at this point has become a dogmatic statement of purism that, while beautiful in a sense, is so unpragmatic as to appear a little foolish.

It's like insisting on using the pre-electronics version of a powerful, dangerous machine even though the new version gives you just as much control, greater precision, and much better safety, because of a romantic notion of purity in the way things should be done. Admirable and not at the same time.

Major projects like this are somewhat rare in the open, and often interesting. It sounds high-risk, but if done well could make a big positive difference in the world of js-related software development.

Loss aversion is strong in humans.

Nice, thank you! This does look promising.

https://www.arthurkoziel.com/replacing-docker-desktop-for-ma...

According to this article, file sharing between the container and the host is about 80% faster in Colima than Docker Desktop for Mac, but still much slower than native:

    # Docker Desktop for Mac
    IOPS: 1545
    Bandwidth: 6.3MB/s

    # Colima
    IOPS: 2786
    Bandwidth: 11.4MB/s

    # Native
    IOPS: 28.6k
    Bandwidth: 117MB/s

Colima doesn't have all the annoying popups, telemetry, and other commercial aspects that turn off many developers from Docker Desktop for Mac. It sounds like a drop-in replacement otherwise. Terrific!

I'll still try to keep as much development native as possible for now, but if it ever gets to be a real pain I'll give Colima a try before mixing docker entirely.

Can it be used with docker for Mac, or some competitor?

Thank you for building Linear the way you have! So snappy in so many ways.

I think it could be interesting to see Linear add personal/private TODO support of some kind… like everyone gets a TODO list that is mostly a view of your linear tickets with each as a bullet point in a document (similar to when you mention them in a Notion checklist doc) but where you can also add other items which are just text (and/or entries in a personal/private linear space)

Stainless | Founding Engineer | NYC or Remote UTC+1 to UTC-7 | Full-time

Stainless is building the platform for high-quality, easy-to-use APIs.

Our first product is SDKs as a service – you send us your OpenAPI spec, and we generate pacakges in all the major languages and publish them to npm/pypi/etc (think `npm install your-company`). These SDKs are world-class: you get an idiomatic wrapper with autocomplete, types, etc. (I built a version of this at Stripe for their SDKs, and am now building a better version for everyone.)

Next, we want to make it easy to build amazing REST APIs. REST is simple and ubiquitous, but right now it’s messy, chaotic, and hard to get right. We’re going to build great open-source standards and tooling that bring the benefits of GraphQL (types, field selection/expansion, standards) and gRPC (types, speed, versioning) to REST.

From there, we plan to build out a rich family of developer platform products – everything an API team would need to deliver a terrific DX to their partners and/or customers.

We’re about 8 months old, around 5 people, have strong revenue, and are selling to companies you interact with every day. We’re backed by Sequoia; founders of Next.js, Prisma, and Segment; and a bunch of (ex-)Stripe employees.

As a founding engineer, you’ll get autonomy to build great products, skilled peers, opportunity for tremendous impact, competitive salary, and a very competitive ownership stake.

We’re looking for exceptionally productive, thoughtful, tasteful, and kind people with a passion for making software development better for everyone. Want to build the future of API tooling? Say hi: alex at stainlessapi.com

The problem is rubber grommets??

Ah, very helpful/interesting – thank you! Seems neat.

gotcha, cool – thank you!

Ah, nice find. They seem to imply plugins can be written in JS, with an API that _may_ be similar to Webpack, but definitely not drop-in compatible:

> We're planning on making Turbopack very flexible and extensible, but we're not planning 1:1 compatibility with Webpack … most Webpack plugins won't work out of the box with Turbopack. However, we're working on porting several of the most popular Webpack plugins to Turbopack.

Right, they link to this docs page when referring to the memoization library: https://turbo.build/pack/docs/core-concepts

And the github link at the top of the page links here: https://github.com/vercel/turbo but, despite being called "turbo", that seems to actually be the repo for Turbopack (the webpack alternative) not "Turbo" the library.

Even digging a bit into the crates, I'm not sure where this supposed library lives: https://github.com/vercel/turbo/tree/main/crates

The Turbo memoization framework sounds interesting, but I don't see any code samples for what it looks like for Rust users, or how it compares to other Rust memoization/caching libraries…

Surprised not to see much mention of plugins and how they will work (unless I missed something?).

Plugins are the big differentiator between Webpack and existing "webpack but faster" tools, and presumably the reason most people still use webpack. What's the plan here?

Kotlin may have many advantages over Python as a language (subjective), but the Java ecosystem is not an attraction over the Python ecosystem to me (both have flaws, but the Java world has a lot of bloated stuff)

Kotlin remains a way better language IMO.

Java has adopted maybe 20% of the things that make Kotlin better, but due to backwards compatibility it'll never catch up.

Personally I think it'd almost never make sense to adopt Java over Kotlin for any greenfield JVM project, unless the devs you hire are truly so low-skill they can't pick it up.

This is something we hope to build relatively soon at Stainless, inspired by Stripe's in-house Ruby API DSL. I think what you're asking for is the right approach.

Fellow "wrote my own generator" person here (I built the codegen system Stripe uses to generate their API client libraries). Sounds like you've got a pretty neat system too, hadn't thought of some of these approaches.

We had a similar story – after looking at the OpenAPI Generator and other options, we ended up making our own in JS from the ground up, more or less (it used the internals of prettier to generate pretty code, especially example snippets for docs, across languages).

I'm now starting a company (https://stainlessapi.com, mentioned by OP elsewhere on this thread) to solve this problem more generally. If you ever get tired of maintaining this system (which may not happen, it does sound fun/interesting) or want broader language support, and are open to a commercial solution, drop me a line: alex at stainlessapi.com

(open invite of course – and also always happy to just chat codegen things, it's a neat little niche)