Live data from Hacker News

Ask HN: What is the future of Swift on the server-side?

news.ycombinator.com

51–60 of 60 posts

Re: Ask HN: What is the future of Swift on the server-side?

#51

I think you're misinterpreting the direction of Rust. Rust 1.65 didn't add a new feature, it removed a limitation on an existing feature. That's the direction I want my languages to be going in.

My current problem with rust is the dependency hell. Hundreds of sub dependencies for every top level one. Yes some of them are super common like serde or rand, or oddly some crate that seems to be just to create directories on the filesystem?! A blessed subset of crates is what I was counting on to save the day, but when something like tonic brings in 100 or so fine grained one-off sub dependencies I don't think tha…

I'm not sure how substantially different that is than a single large dependency with dozens of people with commit rights.

Re: Ask HN: What is the future of Swift on the server-side?

#52
post #30

Google's Go language is well suited for back-end code. However, it's a very opinionated and quirky language. If its style suits you it's a great choice. If, after looking at it for a bit, it doesn't sit well then nope.

What did you find to be quirky?

Go error handling is a bit rough. It's not hard to write the errors but they can derail my mind when I'm reading Go code. They're like walking up stairs where every fourth or fifth step is slightly higher or lower than the rest. If I want to take my mind off of them -- nope! I'm forced by their unrelenting placement to think about them again. Lots of Gophers get used to them though so it's a very subjective thing.

Some other (well known) quirks are:

-- Forced code formatting for everything. If you don't like it you'll probably never like it. It's mostly a problem if you're switching languages often.

-- Lots of little things you'll stumble on that have to be internalized. Loop parameter scope, variable shadowing, randomization of map iteration, the way slices spring to life but maps don't, colon-equals with multiple variables, no unused variables, etc. There are lots of "Go Gotcha" lists around and I believe there's even a book about them. Every language has them but they're especially noticeable in Go because (1) the rest of the language is so easy to pick up that they tend to stick out and (2) they can't be fixed because Go has a backwards compatibility guarantee that no breaking language changed will be introduced.

Anyway, I really enjoy Go. None of this is enough (IMO) to prevent anyone from at least giving it a try and seeing how it suits them.

Re: Ask HN: What is the future of Swift on the server-side?

#53

Earlier quoted context omitted.

My current problem with rust is the dependency hell. Hundreds of sub dependencies for every top level one. Yes some of them are super common like serde or rand, or oddly some crate that seems to be just to create directories on the filesystem?! A blessed subset of crates is what I was counting on to save the day, but when something like tonic brings in 100 or so fine grained one-off sub dependencies I don't think tha…

I'm not sure how substantially different that is than a single large dependency with dozens of people with commit rights.

In large projects other developers usually perform code reviews. And even if not, there's a higher chance someone else will notice some sketchy code while working nearby.

Re: Ask HN: What is the future of Swift on the server-side?

#54
post #53

Earlier quoted context omitted.

I'm not sure how substantially different that is than a single large dependency with dozens of people with commit rights.

In large projects other developers usually perform code reviews. And even if not, there's a higher chance someone else will notice some sketchy code while working nearby.

Some do, and some don't. Are you confident the ones you rely on do for every single commit?

Re: Ask HN: What is the future of Swift on the server-side?

#55
post #27

Earlier quoted context omitted.

Of those languages, only Go could be argued to be “systems” and even then not if the GC is a deal breaker. OP wants a systems language.

> OP wants a systems language. OP is describing they want to write a backend, not a operating system. "Systems language" might have been a "kinda" specifier, rather than precise. Go, Kotlin, C# or even Java works just fine for backends. If I were OP, I'd use whatever I know best, or is the most similar to what I know best. Unless I want it to be a learning experience, they I'd chose the language that is the least sim…

> performant, statically-typed, systems programming language

And then OP lists only C++ and Rust. Both known well for having no garbage collector. I think my comment is still valid.

Re: Ask HN: What is the future of Swift on the server-side?

#56

I think you're misinterpreting the direction of Rust. Rust 1.65 didn't add a new feature, it removed a limitation on an existing feature. That's the direction I want my languages to be going in.

Swift is also more memory safe than rust, which I imagine is another big reason to use it.

Re: Ask HN: What is the future of Swift on the server-side?

#57
post #53

Earlier quoted context omitted.

I'm not sure how substantially different that is than a single large dependency with dozens of people with commit rights.

In large projects other developers usually perform code reviews. And even if not, there's a higher chance someone else will notice some sketchy code while working nearby.

https://www.infoq.com/news/2021/11/rudra-rust-safety/

Over 200 memory safety issues were found in public crates in rust.

If code reviews were all it took to ensure memory safety, then we wouldn’t need the borrow checker in the first place.

Re: Ask HN: What is the future of Swift on the server-side?

#58
post #30

Google's Go language is well suited for back-end code. However, it's a very opinionated and quirky language. If its style suits you it's a great choice. If, after looking at it for a bit, it doesn't sit well then nope.

What did you find to be quirky?

Not OP, but I find the Go compiler very frustrating. I cannot leave unused variables or unused imports here and there… which means I cannot have fun writing throwaway code while “hacking” on personal projects. Sometimes I just want to open my text editor and write code while getting quick feedback from the compiler, but Go literally takes away the joy of coding for the sake of coding.

Besides that, I like the language to some extent.

Re: Ask HN: What is the future of Swift on the server-side?

#59
We (steamship.com) use Swift on the server to power our Heroku-style AI apps platform.

It’s been mostly great. Only downside is the server-side swift community is smaller than others, so you don’t get the deep software library selection something like Python would have.

Post reply on HN