Hacker News Reader

Comment by eob | Hacker News Reader

We use Swift on the server at Steamship. Our Swift project is a federated database for NLP data (query, training, inference, embeddings — the whole bit)

I assume folks are familiar with the downsides of Swift on Linux so I’ll focus on what we like about it:

- Fantastic type system

- Good language extensibility (we use Swift to build ourselves a framework to develop Steamship more easily)

- Good LLVM extensibility

- Mostly performant

- Compiled

All in all, we're very happy with the choice. My biggest gripe is slow build & test times in GitHub actions.

If Swift developers are out there and wanting to dig into more systems-style development, I'm happy to chat.

View on HN

> Mostly performant

I assume that means "efficient at runtime" - but by what metrics? CPU time? Memory usage? Power usage? Latency/responsiveness? Throughput?

What are you comparing it against?

> slow build & test times in GitHub actions

What is the cause of this? Is the generated code slow or just the compiler?

> I assume that means "efficient at runtime" - but by what metrics? CPU time? Memory usage? Power usage? Latency/responsiveness? Throughput?

Not OP, but coming from Python, I find it is liberating to say: I need to write a for-loop for things, and it is OK, not going to be the most efficient thing, but it won't slow me down 1000x and become the major bottleneck. That has been said, Julia probably do the same thing.

Assuming you have to do a lot of string processing (for NLP). Do you have any "shortcut" to do that in Swift? The API is thoughtful, but tedious to type, comparing to Python. It would be great if we have some semi-official "shortcut" libraries just for string processing (The recent RegEx literal is a welcome addition, but not enough).

That's a very gentle way to describe the agony of string processing in Swift :-).

We have written a few shortcut libraries ourselves, but we actually don't end up writing a great deal of string processing code in practice because most of our operations are expressed in a higher level query language that gets compiled down to lower-level operator implementations (which only get written once).

The vast majority of our code (maybe like a lot of systems?) ends up being more about the management of the broader data & processing environment that coordinates everything.

Reply on news.ycombinator.com