belmont_sup

Not to mention how heated my laptop gets when I try to compile a new vapor template. On an m1.

I recently really wanted to use Swift server side because of all the updates to Vapor.

Ran vapor new. Tried to build the project. Laptop spun for minutes and got really hot. Then I gave up and just went back to the usual.

What’s the newer tech?

This is wonderful! Love the technology choices. Very hn-in-the-flavor. Bookmarked and will try my daily reading on it.

I’m considering the use of swift and vapor for my new ideas too, over kotlin.

It has been worth the abstraction in my organization with many teams. Thinking 1000+ engineers, at minimum. It helps to abstract as necessary for new teammates that want to simply add a new endpoint yet follow all the legal, security, and data enforcement rules.

Better than no magic abstractions imo. In our large monorepo, LSP feedback can often be so slow that I can’t even rely on it to be productive. I just intuit and pattern match, and these magical abstractions do help. If I get stuck, then I’ll wade into the docs and code myself, and then ask the owning team if I need more help.

Probably a bad benchmark. I see that a recent blog post on the swift site discusses a migration of a large service from Java to swift using vapor.

What about a formatter? I recall having to figure out which library to install as binary just to do formatting. What do you do?

You make a convincing case.

As a Redditor said:

> The standard VC business model is to invest in stuff that FAANG will buy from them one day. The standard approach is to invest in stuff that's enough of a threat to FAANG that they'll buy it to kill it, but this seems more like they're gambling on an acqui-hire in the future.

To be clear, I myself prefer sound type systems.

But the reality is that teams have started with untyped Python, Ruby, and Javascript, have been productive, and now need to gradually add static types to remain productive.

> Every caller would need to check that the function...

The nice part here is where the gradual part comes in. As you are able to type more of your code, you're able to move where you add your runtime validation, and eventually you'll be able to move all validation to the edges of your system.

Responding to your gradual typing anti-pattern bit: Agree that dynamic language behaviors can be extreme but it’s also easy to get into crazy type land. Putting aside a discussion of type systems, teams can always add runtime checks like pydantic to ensure your types match reality.

Sorbet (Ruby typechecker) does this where it introduces a runtime checks on signatures.

Similarly in ts, we have zod.

Unless the writing changed after you post this, but the writer certainly explains how Rome won after Fabius’s new strategy of attrition and “cowardly” tactics.

Your experience and values match mine. Perhaps I’m not a minority in the hn community.

While I tinker and enjoy these languages themselves (Scala/F#), unless one doesn’t have the libraries and aren’t willing to write them, Cargo and rust-analyzer are just so good. That paired with the basic http-based work I do now, and the ability to use any IDE I want with minimal setup, I can pay the slight borrow checker tax for these ergonomics. Perhaps I’m a minority and just need to give Kotlin a chance.

I had to install the Kagi for Safari app on iOS. This lets me install the extension and switch it to on my phone.