Hacker News Reader

Comment by nicoburns | Hacker News Reader

> Oh, so all you need is somebody who can see into the future

Well yes, anticipating future developments is one of the main things a software developer does. And IMO one of the main differentiators between junior and senior developers. A library that has a history of regular maintenance is unlikely to get suddenly dropped. And a library that has a large user base will have its maintenance picked up by others if the original maintainer(s) do step down. If the library doesn't meet these criteria then you probably shouldn't be using it.}

I don't think you can realistically use Swift client-side. But Rust is an increasingly viable option (for browsers that support WASM). WASM compilation is built in to the official toolchain, and the js/ts-interop story is quite good too at this point (modulo some overhead when calling between JS and wasm).

View on HN

> A library that has a history of regular maintenance is unlikely to get suddenly dropped. And a library that has a large user base will have its maintenance picked up by others if the original maintainer(s) do step down. If the library doesn't meet these criteria then you probably shouldn't be using it.}

Projects die all the time or start being very lazy with the maintenance. Not that I expect anything more, there is literally no money in them.

The criteria I like to use is "Will I be able to fork it and fix it when it goes unmaintained"?

Sounds like the criteria you outline for using a library can be learnt in a second. Why is it then a differentiator between junior and senior?

I have been thinking about Rust, but it has too much stuff like ownership I rather don't want to think about on top of the already complicated things my code does.

A compiler from Swift (or a subset of Swift) to TypeScript would make it a viable option for me. Maybe I write it myself.

It's a differentiator between junior and senior because senior people need to make "the call" on using a technology, juniors don't.

There's a couple of other heuristics for whether or not something is worth using on a project (like complexity of learning, and context within a larger stack), but suffice to say it's about looking past a specific problem and on to subsequent problems down the line.

Juniors often make the call too. Seniors make the call on major things, but there are a lot of little things juniors get to decide, and some of them become bigger over time.

> I don't think you can realistically use Swift client-side.

I beg to differ. I've been using it client-side for years. I do not like the hybrid offerings.

Do you mean client-side as in an ios/mac app? If so then yes my bad, I meant client-side web (which I believe the OP is trying to do as other they presumably wouldn't be using JS/TS seeing as they don't seem to like it). Of course, client-side mobile apps are great in Swift. I just would't recommend compile-to-js. If you do have a good compile-to-js workflow for Swift I'd be interested in hearing about it.

Yeah, I write the whole app, and server interaction is usually done through a “faceless” API.

Rust seems like an excellent server language, and I look forward to seeing it get more mindshare. Swift smells a lot like Rust.

But I’ve used PHP for my backend work. I’m not really a backend engineer, and I am sure it could be done better; even with PHP.

One of the reasons for my choosing PHP, is because it is so widely known, and is a perfectly good language, as long as it is written well.

There was that study that was done recently, where they showed what I call “the fishtank graph.”

This was the graph that showed which server languages were in use.

PHP was this fairly steady line along the top, and every other language looked like gravel in a fishtank, along the bottom.

Reply on news.ycombinator.com