3 ms·

> 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. A

> 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).

ChrisMarshallNY 5y ago
> 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.
- nicoburns 5y ago
  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.
  - ChrisMarshallNY 5y ago
    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.
auggierose 5y ago
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.
- CactusOnFire 5y ago
  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.
  - bluGill 5y ago
    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.
jokethrowaway 5y ago
> 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"?

ChrisMarshallNY 5y ago

> 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.

nicoburns 5y ago
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.
- ChrisMarshallNY 5y ago
  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.

auggierose 5y ago

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.

CactusOnFire 5y ago
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.
- bluGill 5y ago
  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.

jokethrowaway 5y ago

> 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"?