Hacker News Reader

Agreed on all points. I’ve been using Vapor for a small work project for a couple of years and overall it’s been a good experience.

I think a lot of the author’s problems started when he bailed on Vapor and went down into the depths of SwiftNIO. I’m not really sure this was necessary. I could be wrong, but it feels to me like Vapor should let you do pretty much everything that you would need for an ActivityPub server.

Writing request handlers in Vapor with async/await is delightful - it’s really not any harder than writing Flask code. But going down below that level is pain. Lots and lots of pain.

I've actually tried to write an ActivityPub server in Vapor! I must admit I didn't get very far on the outbound part using Vapor, as the inbound part took up most of my time. My impression was that ActivityPub is way too poorly specified for a good ecosystem to develop, which is probably why we see a monoculture of Mastodon for post-based ActivityPub, and similar semi-independent monocultures for things like Reddit replacements (Lemmy?).

You're right about the NIO part. I've had to dig into it a few times, but rarely found it productive in solving problems. Vapor is pretty flexible if you drop past it's first layer of abstractions, and as long as you pick one of futures/async and stick to it, it's fairly straightforward.

Have you looked at Kotlin? Very, very similar to Swift and interoperates very well with Java.

Briefly. There are Kotlin areas in the codebases I work on, particularly in Android code. It's not something I've needed to use yet, but I've heard good things and I'm interested to get into it once we start using it more.

Strongly second the GP. I ramped up over the past year and I compare it to C# or TypeScript as far as the type safety and async features go. That whole time I kept running into QoL features and sugar that were just a joy to use.

The best side benefit for our Java heavy org was that the migration risk is very low due to excellent JVM/Java integration.

I started using Kotlin in Java 8 before the "record" keyword existed to be able to use "data class" instances. This provided very nice semantics for defining immutable structures, and the resulting classes could be imported into the existing Java codebase.

As the project progressed we started adding more in Kotlin and it massively improved developer experience.

If you work in Java and like the syntax of Swift, then you should consider using Scala. Of course convincing coworkers and managers to use it can be a problem.

Scala isn't a language I can use here, we have too much Java tooling and are conservative on new languages. I see your point about Scala, there are niceties to it in my (brief) experience, however it's not so much the syntax as it is the way that software tends to be written in Swift given the language features – I didn't find the same in Scala, it tended to be more complex than I wanted.

> Scala isn't a language I can use here, we have too much Java tooling and are conservative on new languages.

Most Java tooling works with Scala out of the box or at most needs a plugin added, and interop when calling Java from Scala is very smooth. Even if it wouldn't be acceptable for production code you might consider trying it for migration scripts, admin tools, testing etc. (though personally I'd stay away from ScalaTest et al) - that's how I got my start with Scala many years ago.

I'm at Google and we have a very consistent set of tooling across a large engineering org. I can certainly "play" with Scala, but realistically my exploratory coding is Python notebooks or SQL – neither of which Scala is going to help with, and anything else is going to need so much work to integrate with our frameworks and systems that it's unlikely to happen.

> realistically my exploratory coding is Python notebooks or SQL – neither of which Scala is going to help with

FWIW Scala can actually be pretty useful in that space with Zeppelin - it's not quite as smooth as some of the Python-only notebooks out there, but sometimes being able to use your Java libraries in your notebooks makes up for a bit of clunkiness.

That's handy to know for the future. At the moment we have plenty of infrastructure built around Python notebooks, things like Colab, so not really feasible here I think.

How's the Scala community doing? I had the impression a couple years ago that they were losing momentum. But I also heard that Scala 3 fixed a lot of footguns that Scala developers hated, so maybe that gave them a second wind...

Scala has lost its hype status, and hype chasers will more likely use Go or Rust. Kotlin has encroached on the "better Java" category (and of course Java is now better). One of the great Scala success stories was Twitter, which has been eviscerated by an impulsive man-child, and their commitment to Scala is in doubt.

The community is a bit worried over these developments, and there has been some sniping over the disruption caused by Scala 3 (mainly to projects that relied on macros, even though macros were marked as an experimental feature).

IMO Scala is still the best language on the JVM, and last I checked there were plenty of jobs for experienced Scala devs. The foot guns weren't that severe, or at least I am used to them (in my opinion, Java coding has more foot guns due to nulls and mutable state everywhere, YMMV).

Scala 3 was more incremental, than radical, and was massively less disruptive than you see with other attempts to clean up a language (Python 3, Perl 6, anything involving PHP) due to good design, careful planning and backwards compatibility options.

> Each of these problems looks like the sort of thing that you solve quickly once and move on from.

Erm, including the apparent signal race and the illegal instruction?

> Erm, including the apparent signal race and the illegal instruction?

Yes. They're probably both caused by this person setting their CPU microarchitecture wrong.

> the developer tooling is much better at the lower end

Haha, what?

I find the performance tooling and package management situation in Swift via Xcode and Instruments is, in my experience, much better than a typical out-of-the-box Java setup with a popular IDE. IDE features may be better in something like Intellij (I'm not a fan personally), but the language tooling isn't better in my experience. The swift+llvm+lldb setup is nice, Swift Package Manager is really nice, much nicer than Maven/Gradle in my experience. So yeah, better at the low end.

Linux/Windows tooling is lacking, I'll give you that, but given where Swift started from I feel like they're already outside the norm for Swift development and debatably "low end" on complexity (although not deployment, I haven't had a problem with Linux deployment).

By "high end" I mean anything that is trying to do complex runtime analysis, and the sort of tuning that you can do on the JVM that is way outside my comfort zone.

You should probably list some concrete examples of how it is better. Otherwise it’s just an opinion with no insights.

Concretely, the whole Instruments suite is far beyond anything I've managed to get out of a JetBrains IDE. I realise they have some of this stuff, but in my experience it's far from easy to use, and it costs money, which Xcode/Instruments do not.

I thought the "low end" would mean the ability to skip the huge XCode and building your project with a popular text editor/ide (that's also where Linux/Windows wouldn't have to lack)

Ah, no, I mean more the lowest barrier to entry end, i.e. what early tutorials will focus on, what newcomers to the ecosystem are expected to be using.

"Install Xcode, click New Project" is a much lower barrier to entry than setting up the toolchain in other ways.

I had a similar chuckle/double-take; admittedly it's been a few years since I looked at XCode, but it didn't strike me as much more than a Notepad wrapper around a toolchain.

> Overall, I'm loving it for a personal project. Would I use it as the foundation of a new startup? Probably not.

I know of a medium-size startup that is (attempting) building an industrial/IoT software stack on just Swift. Last I heard things weren't going great...

What language you write in doesn’t seem like a great place to use your few innovation tokens for that kind of startup.

Adding to the recommendations for other languages you're already getting on this thread: have you tried Rust? It's type system and syntax are very similar to Swifts. You do have to deal with the borrow checker, but that typically isn't too challenging for backend web development work where logic tends to be pretty linear anyway, and in return you get a much more developed ecosystem.

Maybe I just haven't looked at the right codebases, but most of the Rust I've seen reminds me more of C++, being more dense, technical, and "noisy". The language most similar in syntax to Swift I've seen is Kotlin, but it's still more quirky and rigid than Swift is.

I write a lot of Swift and Rust, and personally I find them to be very similar languages, and most of my code ends up identical.

They have a lot of shared ideas and even shared developers.

Swift is effectively ref counted rust imho

I think this does a disservice to Rust, but I do agree with the thrust of your point. Rust appeals to my desire for perfect engineering, Swift appeals to that side enough, but with a healthy dose of pragmatic engineering. On a perfect to pragmatic scale, Swift is in a better place than Rust in my opinion.

That roughly matches my experience trying to use Swift outside Mac and iOS development. I really like the language but the tooling and library ecosystem just aren't there. Go or Rust are not as nice to write in different ways but much more easy to get work done with. On the Rust side the language is more fiddly than Rust but with the help of Copilot the gap is not that big.