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…
Ask HN: What is the future of Swift on the server-side?
51–60 of 60 posts
Re: Ask HN: What is the future of Swift on the server-side?
#52Google'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?
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?
#53Earlier 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.
Re: Ask HN: What is the future of Swift on the server-side?
#54Earlier 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.
Re: Ask HN: What is the future of Swift on the server-side?
#55Earlier 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…
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?
#56I 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.
Re: Ask HN: What is the future of Swift on the server-side?
#57Earlier 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.
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?
#58Google'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?
Besides that, I like the language to some extent.
Re: Ask HN: What is the future of Swift on the server-side?
#59It’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.