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.

It’s been done a few times now. In looking for more SwiftUI docs, I’ve used a GPT from OpenAI’s gpt store where someone’s uploaded a bunch of their docs.

Coming from normal dev work myself, I’m drawn to dotnet nowadays. If you ever make the chance, it’s real easy to get started and do what Python does in aspnet, scripting, whatever.

This is so neat.

Consider what works. Then pick what’s most fun and move on from there. If you can complete your work with any of the languages, all are the sensible in a vacuum.

Are you trying to grow a team? Still arguable to choose whatever you are best at because you can grow that team.

I’ve recently had to learn some nix to build an IHP app (Haskell framework). Most hosting providers require a dockerfile and/or image. I couldn’t get nix to build an image on time within the hosting providers’ CI. So I gave up.

For any other project, I can spend half an hour max to get a decent deployable build. The trade offs is Nix doesn’t seem to work for me.

.net and jvm are still very modern. Use kotlin for with spring or ktor. Or use c# or f# with aspnet. They come with everything included.

The time to finish your project would be quicker with all-in-one solutions.

Ditch the nextjs part and just return html. Add alpinejs and htmx and you won’t need to waste time creating a typical json api.

Wish I had the capacity of time and energy to create this dream language of mine too.

Roc lang seems to be building up to what I desire. But we shall see. At the end of the day, picking one of the mainstream runtimes ids the safest bet. F# if we want to enjoy some fun but stay pragmatic.

Ocaml fan here but don’t expect crazy productiveness as you’d find yourself in Go unless you know fp and aren’t doing a lot of web dev.

I have to agree so much. Been following for years, and started new experiments this week. It all worked so well.

dune init …

opam install some tools like lsp

restart vscode

dune build --watch and I’m good to go.

Edit: adding some counterpoints and issues to level the field (but are being worked on)

1. dune/opam - wish they were one thing. I can still install packages with dune, and a package lock file exists for deterministic-enough builds.

2. dune files and s-expressions are still weird to write. I wish we can move away, or at best, have a tool that helps you remember and where configs. best I have now is chatgpt instead of having to crawl dune docs

3. eio, lwt, async - 3 async runtimes, hoping that one day it’ll be easy to use an async lib with an lwt-based project via eio. The division will likely never be consolidated

Aren’t all those the same but interpreted differently? You have your programming concepts in each and every corner at every level, whether at language, framework, application, or infra.

Isn’t life with aspnet easy enough because it actually can do multithreaded work right? So not really a problem for dotnet folks.

Unless you really want the one-click experience. We use aws sdk, spin up sqs, add some env vars to aspnet, connect the client, enqueue and dequeue all from the same app without a 3rd party (short of the queue infra).

This is great news. I strolled around https://github.com/vitessio/vitess/issues/12967.

Are there any public discussions of more trade-offs vitess has to make to enable fks?

Look at all the fascinating runtimes that have evolved. Erlang, Haskell, Go, Rust, and include any other. You don’t consider any of these evolution? Back then, programmers were still using threads for everything. Now we have “green threads”. One example of a pretty great evolution. Albeit it does feel like software evolves slower than hardware.

He still has a point. Go code and similar languages hide the concurrency. You write synchronous looking code most of the time, but underneath, libraries and runtimes ensure you’re running concurrently.

I’m reading on a tablet. Counter opinion, I like their website. I’m neither a designer nor a user of sketch.