8 ms·

I strongly disagree. Nothing is worse than developers being forced to work in a language they are not used to - not just because it's inefficient, but because t

by Timon3 3y ago

I strongly disagree. Nothing is worse than developers being forced to work in a language they are not used to - not just because it's inefficient, but because they won't write it in an idiomatic way. If all you have are TS developers, writing a CLI in TS is not just fine, it's the right decision. Forcing Rust upon them is not going to make anyone involved more happy.

rowanseymour 3y ago
I just don't get this way of thinking and can't imagine calling myself an "X developer". The human brain is more than capable of being proficient in more than one language. It's also boring only using one language every day. If all you have are TS developers, then IMHO, you don't have very good developers.
- messe 3y ago
  Obligatory 'I am not a "JavaScript Developer"' by Andrew Kelley[1][2]. [1]: https://andrewkelley.me/post/not-a-js-developer.html https://andrewkelley.me/post/not-a-js-developer.html [2]: The creator of Zig[3] [3]: https://ziglang.org/ https://ziglang.org/
  - jujube3 3y ago
    You can build a hundred bridges and they still don't call you a bridge builder... lol
- Scarblac 3y ago
  Then imagine he said "all-round developers who in their current job spend 95%+ of their programming time writing Typescript", if that's less offensive.
  - dbsmith83 3y ago
    His point remains. If someone is so uncomfortable in all other languages that they have to pick a bad tool for the job, then they are probably not a good developer. Obviously, we can't always pick or even know the absolute 'best' tool, but good grief there are a lot of better choices than typescript for cli tools.
    - Hermitian909 3y ago
      Even if they know better suited languages, do they know the same better suited languages? I'm in a TS shop, 95% of our code is TS. I would assume that almost everyone we've hired knows at least one compiled language but that language might be C++, Go, or Java. The only way to write a CLI tool that anyone at the company can edit is to write it in TS and so, indeed, >90% of the CLI tools we write are in TS. Works fine.
      - randomdata 3y ago
        > The only way to write a CLI tool that anyone at the company can edit is to write it in TS The only way? If you know C++, Java, or Go, even Typescript for that matter, they are all almost exactly the same. There is a little nuance with respect to setting up a project idiomatically, but once that groundwork is laid anyone can come along as they're simply going to copy the structure and style of what is already there anyway.
        Hermitian909 3y ago
        > There is a little nuance with respect to setting up a project idiomatically, but once that groundwork is laid anyone can come along as they're simply going to copy the structure and style of what is already there anyway. You might think so! Having seen this tried in multiple 100+ engineering orgs, I think empirical evidence is against you. CLI tools can get surprisingly complicated (or use a surprisingly complicated set of language features). Many engineers will simply give up if a solution is not obvious in the first 5 minutes. The end result is you have a lot of team A asking team B for a minor feature or fix to team B's CLI tool, or worse, team A just writes a hacky workaround to the broken-ness in the CLI tool. Most people just don't care enough to put in the kind of effort for anything but the easy path.
- sorahn 3y ago
  I think that’s not really relevant. Not every company can afford to have the best developers that can do everything. And not every developer wants to struggle through a new language for (unknown time) writing a tool (or anything) that could be done in an hour in a language they’re familiar with instead. A lot of common screwdrivers can turn Philips head screws enough to get the job done.
- jitl 3y ago
  Most developers I work with seem to prefer to stick to a single language. I don’t have this preference or consider myself a “typescript only developer”, however since I primarily contribute to a Typescript codebase day to day I end up the most practiced at Typescript. TS code flows out my fingers much faster than other languages I know like Go or Ruby. I am fine reading Rust or Ocaml but need a lot of reference material to write new features. Sure I could ask my devs to write our CLI tools in Rust, and some of them would habituate to both languages but there’s no denying it’s a higher mental burden to split training time between two languages, or three languages.
- andrewaylett 3y ago
  On the other hand, it's quite plausible that TS is one of only a small number of languages that you know that all your co-workers will be proficient in. And in general I expect that the actual work I'm doing will be more interesting than the programming language I get to use. I really enjoy learning new things, and digging into new programming languages just for the sake of it, but when I need to actually ship something I don't want my programming language to be the exciting part of what I'm doing.
  - randomdata 3y ago
    > it's quite plausible that TS is one of only a small number of languages that you know that all your co-workers will be proficient in. If by TS you mean Javascript with ": any" tacked onto the end of each variable, then perhaps. Actual TS proficiency is rare, in my experience. But if proficiency is a concern, you're not going to slap any random web developer on a command line tool project. It is an entirely different skillset. Amongst the developers proficient in command line tools, I expect the common language they are familiar with is typically not TS.
    - Capricorn2481 3y ago
      > If by TS you mean Javascript with ": any" tacked onto the end of each variable, then perhaps. Actual TS proficiency is rare, in my experience. This isn't even a lack of proficiency, this is just hiring bad people. Who doesn't know how to annotate a type? That hardly takes Typescript "proficiency," you can learn it in 5 minutes.
      - randomdata 3y ago
        > This isn't even a lack of proficiency, this is just hiring bad people. If there was some specific reason to hire Typescript developers, maybe. But across an organization, many developers won't be working on Typescript projects and there would be no reason to hire based on Typescript ability for those projects. It may be one of the few language all developers have some familiarity with, as proposed earlier, but that doesn't mean it is the language all developers focus on. And when hiring developers with a background in building command line tooling, it is likely that Typescript has never been a language that has garnered their attention. > Who doesn't know how to annotate a type? That hardly takes Typescript "proficiency," you can learn it in 5 minutes. Typescript is its own language – one that is even turing complete. While you likely can learn it in 5 minutes, same goes for any language, including the aforementioned Go, Rust, and Zig. Proficiency takes quite a lot longer, though.
- h1fra 3y ago
  Yet most people speak 1-2 languages (1.8 average in Europe). Maybe most people are not good human based on your definition.
  - regular_trash 3y ago
    Transitioning from any derivative of a given ur-language to another should be fairly trivial. I don't think anyone expects table stakes for devs to be proficiency in Java as well as APL
  - rowanseymour 3y ago
    Well most people aren't good linguists certainly.
- nobleach 3y ago
  While I totally agree, and I come from a time where one couldn't be a full stack JavaScript developer. (Also a time when folks DID make their living doing bread and butter style Delphi/PowerBuilder/FoxPro/VB apps). I get that some folks spend ALL day in a certain language/stack and it's easy for everything to begin to look like a problem they could solve using that language/stack. I do agree that is boring, but it also pays the bills!
- solatic 3y ago
  What is this magical world you live in where a company can put up job listings for "Polyglot Software Engineers" and consistently, successfully get them through the hiring pipeline and staff up teams? Where I live, (a) there's much more junior and mid-level talent with 0-2 years of experience than anyone else, (b) talent is far more likely to have TS/JS experience. If you hire for JS talent, you ship. If you try to hire anybody else, you struggle to hire, struggle to collaborate ("I don't know X, so I'd prefer to open a ticket than to struggle and open a PR to that other team's repository"), and therefore ultimately struggle to ship. Startups should run on the JS ecosystem by default and only write code in other ecosystems if there's a very good reason to do so (business competitive advantage, JS ecosystem options are severely lacking...).
  - rowanseymour 3y ago
    Obviously you gotta work with what you got and it might be the best business decision to hire some junior devs with no experience outside of JS/TS and build your CLI tool in that. But that's never going to be the best tool for CLI development, and someone with no experience outside of JS/TS (or any single language) is never going to be the best engineer.
    - solatic 3y ago
      > best business decision The best business decision is the only relevant decision in the real-world, unless you're building the software as a hobby and you're willing to essentially self-fund the development without regard to anything else outside your own enjoyment. If it's not your hobby, then you don't get to build perfect software, you get to build software that people are willing to fund (either through investment or purchase). People are only willing to fund software that ships. Professional development is an endless struggle to manage the sources of imperfection in the codebase; shipping perfect software is a pipedream. Shipping necessarily requires getting comfortable with shipping something imperfect and improving through iteration by shipping some more. So the first thing that you need to optimize for is shipping, and that is a function of who you can hire, what skillsets they have, and organizational design (including making cross-team collaboration easier by choosing standards, including language standards) that promotes shipping. Should you be so fortunate that you have many, many people purchasing your software, or your investors (or CFO/VP Finance by proxy) are convinced that you need to leave the JS ecosystem to attain or preserve competitive advantage, then fine, build your CLI in a language that offers more technical advantage to building CLI tools. But that's not the default.
- irrational 3y ago
  Proficient? Yes. But I have better things to do with my time. I enjoy spending time with my family, woodworking, baking, gardening, home remodeling, painting, studying ancient Afro-asiatic languages, reading, hiking, etc. The only way I’m going to learn a new language is if my work requires it and makes time for me to learn it. Well, we have far too much work to do to carve out time to learn new languages, so they just keep us using what we already know. That’s fine with me. I receive a hefty six figure income to pay for my life outside of work.
- zsyllepsis 3y ago
  > If all you have are TS developers, the. IMHO, you don’t have very good developers. Does it change anything to reframe this as having a common denominator across all developers? As in, rather than “All of my developers know only TS” to “TS is the common language all of my developers know”. Particularly in small companies I think it makes more sense to focus on a restricted set of tools and technologies. It makes interviewing easier, ensures mobility of hires to different areas of the code, and produces an easier onboarding experience for new team members. > It is also boring using only one programming language every day Interest and passion come from more aspects of a project than the language it was written in. Some projects are interesting because of they incorporate cutting edge research, some because they have highly visible impact on users, and others because the solution involves a careful balance of design constraints. Choice of (or diversity between) language doesn’t have to be the distinguishing factor that makes a project interesting.
- deleted 3y ago
  [deleted]
- solarkraft 3y ago
  I'm not an X developer, but I have experience with certain tools. Building on that experience is usually more efficient than starting over at 0.
giraffe_lady 3y ago
I think that person made a mistake in specifically mentioning rust and zig, because those are relatively uncommonly known languages among working webdevs. But I think you're making a mistake in assuming they mean someone should force a specific language on them. In practice nearly every working TS dev knows something else, python, ruby, elixir, yeah maybe go. They should choose one of those other languages for the tool. A specific one doesn't need to be forced on them, just the decision that it should not be TS.
- Timon3 3y ago
  If you're saying "just use something else", you'll have to actually compare TS to the languages you're proposing. If for example someone were to suggest Python for a backend, I'd argue that TS is many, many times better than Python. Can you explain why TS is so very much the wrong tool in your eyes?
  - giraffe_lady 3y ago
    Just on a quick skim it seems like there are enough other people willing to take the other side of your "JS is good actually" position so I'm gonna pass today.
bluefishinit 3y ago
> If all you have are TS developers, writing a CLI in TS is not just fine, it's the right decision. Companies should be properly staffed to support the platforms they're distributing on. If you're building a CLI tool, you should have devs familiar with doing that use an appropriate language. You should not repurpose front-end web developers to build the CLI tool in a web front-end language just because that's all they know. That's pushing your business, training and hiring problems down to the user. Not to say web front-end devs can't make great CLIs (or servers)! It's just that they should train up on an appropriate stack if they're going to do so.
- Timon3 3y ago
  If everyone thought as you do, many companies simply wouldn't release a CLI tool, because hiring experienced developers just so you can use the "appropriate" language for a domain isn't realistic for most companies. I know it sounds nice, and I'd like the world to work differently too, but the reality is that resources are constrained enough that many developers have to be all-rounders, and you don't do that by learning the "right" language for every problem.
  - randomdata 3y ago
    > many companies simply wouldn't release a CLI tool That's his point, though. Command line tools require a different skillset. If a team has only worked on browser applications, they won't have the skills for command line tools and will need to learn them. Taking time to learn contradicts the grandparent comment, which suggests that people should stay in their lane and that there is nothing worse than forcing developers to work on things they are not already familiar with. If one is going to hold that developers shouldn't be forced to learn on the job, even if by way of fellow teammates trying new approaches that others will need to maintain, you simply can't have them working on CLI tools and bringing on new teams that will operate independently is the only way to see movement into new areas.
    - Timon3 3y ago
      > Taking time to learn contradicts the grandparent comment, which suggests that people should stay in their lane and that there is nothing worse than forcing developers to work on things they are not already familiar with. My comment said no such thing. There is a difference between "types of applications you build in a language" and "language" (the first 7 words in the earlier one). It is much easier to learn how to write a different kind of application in a language you know, because you already know the language. You have to learn less. I'm not sure why you're putting things as if I've made some absolutist statement. All I'm saying is: You only have the resources you have, and the efficient way to use them (especially in the long term) is not to leave architecture and implementation to a team that knows neither the language nor the environment.
happytoexplain 3y ago
>Nothing is worse than developers being forced to work in a language they are not used to I think there are much, much worse things than this. Most of the time, I would count among those things the humongous downsides of JS, but it depends on your situation, obviously. There are plenty of cases where you should use JS/TS. But if I only knew TS and had an opportunity to write a CLI in Rust, I'd jump at the opportunity. It's not always the case, but lots of things are appropriate to use as an excuse to learn something new.
- Timon3 3y ago
  > Most of the time, I would count among those things the humongous downsides of JS, but it depends on your situation, obviously. Could you explain these "humongous downsides of JS"?
soggybutter 3y ago
This line of thinking is precisely why node and TypeScript are so pervasive. It has nothing to do with them being the right tool for the right job and everything to do with perceived lower barrier to entry and resistance to learning better tools. I would never try and use a hammer to saw a board in half, and yet that's exactly what people try and do with node/TS
- Timon3 3y ago
  I'm not saying that you should use TS & Node for everything, not sure how you got that wrong. I'm saying: use the tools your developers know. If you have Java developers, use Java. If you have Rust developers, use Rust. If you have Typescript developers, use Typescript. Don't give a metaphorical person without arms a saw to split a board in half, even if it's supposedly the right tool.
  - soggybutter 3y ago
    I didn't really think you were saying they should be used for everything, but I do think discouraging branching out into better suited tools perpetuates using the lowest common denominator. If devs are never pushed out of their comfort zones, it's really hard for them to grow arms in order to use the saw. I do acknowledge I have a lot of bias, though, because I work at a TS shop where the primary reason we continue to use it is because we always have. The longer I have to put up with it, the more I feel like this is a broken foundation to stand on
    - Timon3 3y ago
      You shouldn't let developers branch out by trying to write their first real application in a completely new language as a productive thing for your company or your customers. They should learn by implementing real projects that will not be important or improved and maintained long-term.
- crdrost 3y ago
  I mean, they're also just kind of fun. Suppose you are building a CLI tool just for yourself, Deno is way more fun than Bash, say. Especially if your usecase starts to get into like tree traversals and stuff.
renegade-otter 3y ago
A large part of the bullshit that this industry has had to endure was exactly because a lot of front-end developers writing Javascript declared "we are all backend engineers now" and started using Node, thinking that UI development somehow translates to backend concepts. These are totally different areas of craft, like e-commerce vs game development.
- Timon3 3y ago
  But also many, many wonderful things came about because backend development became more approachable. You're right that inexperienced developers working in an environment they don't know produces a lot of horrible stuff, but that doesn't invalidate the good! And I wouldn't strictly differentiate between these areas. My game development experience helps me to write better backends and frontends alike. They are separate insofar that you have to learn each environment to be able to write idiomatic code, but it's not like you can't re-use parts of your knowledge across all of them.
  - renegade-otter 3y ago
    I think the worst aspect of it is that the cohort of engineers was not taught to appreciate the complexity (of distributed systems in particular). This is something the industry is just trying to burry itself out of. It was a bad combination of "green" JS engineers writing servers and a new batch of fresh FAANG veterans mentoring them into writing extremely complex and expensive systems. There is a large dollar value attached to this fiasco.
    - Timon3 3y ago
      > I think the worst aspect of it is that the cohort of engineers was not taught to appreciate the complexity (of distributed systems in particular). This is something the industry is just trying to burry itself out of. It sounds like you have a bone to pick - because when was this ever not the case? Most developers of any generation don't really know about the complexity of distributed systems. Some developers do, even in "the cohort of engineers" who you say wasn't taught this. People using inexperienced (in the topic) developers for complex systems is not something new either. People use who they have.
Cthulhu_ 3y ago
I mean while I think hiring and availability is an important reason to pick a language, and so it makes sense to have e.g. Node / JS / TS as a back-end language. But it's not ideal. Another one would be to pick Java or C#, but the stereotype of a developer like that is that they will overcomplicate and make a heavy, enterprisey back-end; Node backends feel lighter, so I can again understand why they would rather have a Node / JS type developer, they're more pragmatic. Ideally you'd get a "polyglot" developer, or a developer who has embraced that language is just an implementation detail, someone who can see beyond a language and its ecosystem and stereotypes. But the hiring pool for those is small, and convincing them to work for your company is really difficult if it doesn't do anything exciting, new, or cannot pay a lot.
- Timon3 3y ago
  > Ideally you'd get a "polyglot" developer, or a developer who has embraced that language is just an implementation detail, someone who can see beyond a language and its ecosystem and stereotypes. But the hiring pool for those is small, and convincing them to work for your company is really difficult if it doesn't do anything exciting, new, or cannot pay a lot. That's kind of the approach I'm proposing. Don't care about the language, use the one your developers know best, because the language itself is just an implementation detail, while the proficiency will help you in any language. You're not going to get a large group of great polyglot developers, so you have to reverse the process and choose the language your developers know best.
snarfy 3y ago
What about the users? This whole thread is entirely developer centric. Odds are you are going to have 1000x more time users than developers. A native solution and not some node interpreted monstrosity is the right choice. We all loathe electron apps because they perform like shit. What's worse, inconvenience a handful of developers to learn a native language, or make thousands of users run node apps? The carbon footprint alone is worth it.
- Timon3 3y ago
  I disagree. If the program is fast enough for its purpose, and my developers can write better code (as in, code with better architecture allowing for flexible development while being easy to read) and develop features faster, it doesn't matter which language is "right", it matters which one will get the thing developed in an acceptable amount of time. Users would rather have bad software than no software, as you can see with Electron apps that perform like shit. I'm not saying that performance, memory consumption etc. are completely insignificant. I myself prefer to use faster tools that use less memory. But if all you have is a bunch of Typescript devs, and you want them to develop a CLI, you're not going to get a better result by telling them to do it in Rust. To get a better result you'd have to tell them to learn Rust and work in it for half a year. And yes, that would be better for users in the long run, but that doesn't mean it's realistic in all cases.
Gibbon1 3y ago
Writing a CLI in rust is just dumb. Really really really dumb. Just write it in C# and take the afternoon off.

by Timon3 3y ago

rowanseymour 3y ago

I just don't get this way of thinking and can't imagine calling myself an "X developer". The human brain is more than capable of being proficient in more than one language. It's also boring only using one language every day. If all you have are TS developers, then IMHO, you don't have very good developers.

messe 3y ago
Obligatory 'I am not a "JavaScript Developer"' by Andrew Kelley[1][2]. [1]: https://andrewkelley.me/post/not-a-js-developer.html https://andrewkelley.me/post/not-a-js-developer.html [2]: The creator of Zig[3] [3]: https://ziglang.org/ https://ziglang.org/
- jujube3 3y ago
  You can build a hundred bridges and they still don't call you a bridge builder... lol
Scarblac 3y ago
Then imagine he said "all-round developers who in their current job spend 95%+ of their programming time writing Typescript", if that's less offensive.
- dbsmith83 3y ago
  His point remains. If someone is so uncomfortable in all other languages that they have to pick a bad tool for the job, then they are probably not a good developer. Obviously, we can't always pick or even know the absolute 'best' tool, but good grief there are a lot of better choices than typescript for cli tools.
  - Hermitian909 3y ago
    Even if they know better suited languages, do they know the same better suited languages? I'm in a TS shop, 95% of our code is TS. I would assume that almost everyone we've hired knows at least one compiled language but that language might be C++, Go, or Java. The only way to write a CLI tool that anyone at the company can edit is to write it in TS and so, indeed, >90% of the CLI tools we write are in TS. Works fine.
    - randomdata 3y ago
      > The only way to write a CLI tool that anyone at the company can edit is to write it in TS The only way? If you know C++, Java, or Go, even Typescript for that matter, they are all almost exactly the same. There is a little nuance with respect to setting up a project idiomatically, but once that groundwork is laid anyone can come along as they're simply going to copy the structure and style of what is already there anyway.
      - Hermitian909 3y ago
        > There is a little nuance with respect to setting up a project idiomatically, but once that groundwork is laid anyone can come along as they're simply going to copy the structure and style of what is already there anyway. You might think so! Having seen this tried in multiple 100+ engineering orgs, I think empirical evidence is against you. CLI tools can get surprisingly complicated (or use a surprisingly complicated set of language features). Many engineers will simply give up if a solution is not obvious in the first 5 minutes. The end result is you have a lot of team A asking team B for a minor feature or fix to team B's CLI tool, or worse, team A just writes a hacky workaround to the broken-ness in the CLI tool. Most people just don't care enough to put in the kind of effort for anything but the easy path.
sorahn 3y ago
I think that’s not really relevant. Not every company can afford to have the best developers that can do everything. And not every developer wants to struggle through a new language for (unknown time) writing a tool (or anything) that could be done in an hour in a language they’re familiar with instead. A lot of common screwdrivers can turn Philips head screws enough to get the job done.
jitl 3y ago
Most developers I work with seem to prefer to stick to a single language. I don’t have this preference or consider myself a “typescript only developer”, however since I primarily contribute to a Typescript codebase day to day I end up the most practiced at Typescript. TS code flows out my fingers much faster than other languages I know like Go or Ruby. I am fine reading Rust or Ocaml but need a lot of reference material to write new features. Sure I could ask my devs to write our CLI tools in Rust, and some of them would habituate to both languages but there’s no denying it’s a higher mental burden to split training time between two languages, or three languages.
andrewaylett 3y ago
On the other hand, it's quite plausible that TS is one of only a small number of languages that you know that all your co-workers will be proficient in. And in general I expect that the actual work I'm doing will be more interesting than the programming language I get to use. I really enjoy learning new things, and digging into new programming languages just for the sake of it, but when I need to actually ship something I don't want my programming language to be the exciting part of what I'm doing.
- randomdata 3y ago
  > it's quite plausible that TS is one of only a small number of languages that you know that all your co-workers will be proficient in. If by TS you mean Javascript with ": any" tacked onto the end of each variable, then perhaps. Actual TS proficiency is rare, in my experience. But if proficiency is a concern, you're not going to slap any random web developer on a command line tool project. It is an entirely different skillset. Amongst the developers proficient in command line tools, I expect the common language they are familiar with is typically not TS.
  - Capricorn2481 3y ago
    > If by TS you mean Javascript with ": any" tacked onto the end of each variable, then perhaps. Actual TS proficiency is rare, in my experience. This isn't even a lack of proficiency, this is just hiring bad people. Who doesn't know how to annotate a type? That hardly takes Typescript "proficiency," you can learn it in 5 minutes.
    - randomdata 3y ago
      > This isn't even a lack of proficiency, this is just hiring bad people. If there was some specific reason to hire Typescript developers, maybe. But across an organization, many developers won't be working on Typescript projects and there would be no reason to hire based on Typescript ability for those projects. It may be one of the few language all developers have some familiarity with, as proposed earlier, but that doesn't mean it is the language all developers focus on. And when hiring developers with a background in building command line tooling, it is likely that Typescript has never been a language that has garnered their attention. > Who doesn't know how to annotate a type? That hardly takes Typescript "proficiency," you can learn it in 5 minutes. Typescript is its own language – one that is even turing complete. While you likely can learn it in 5 minutes, same goes for any language, including the aforementioned Go, Rust, and Zig. Proficiency takes quite a lot longer, though.
h1fra 3y ago
Yet most people speak 1-2 languages (1.8 average in Europe). Maybe most people are not good human based on your definition.
- regular_trash 3y ago
  Transitioning from any derivative of a given ur-language to another should be fairly trivial. I don't think anyone expects table stakes for devs to be proficiency in Java as well as APL
- rowanseymour 3y ago
  Well most people aren't good linguists certainly.
nobleach 3y ago
While I totally agree, and I come from a time where one couldn't be a full stack JavaScript developer. (Also a time when folks DID make their living doing bread and butter style Delphi/PowerBuilder/FoxPro/VB apps). I get that some folks spend ALL day in a certain language/stack and it's easy for everything to begin to look like a problem they could solve using that language/stack. I do agree that is boring, but it also pays the bills!
solatic 3y ago
What is this magical world you live in where a company can put up job listings for "Polyglot Software Engineers" and consistently, successfully get them through the hiring pipeline and staff up teams? Where I live, (a) there's much more junior and mid-level talent with 0-2 years of experience than anyone else, (b) talent is far more likely to have TS/JS experience. If you hire for JS talent, you ship. If you try to hire anybody else, you struggle to hire, struggle to collaborate ("I don't know X, so I'd prefer to open a ticket than to struggle and open a PR to that other team's repository"), and therefore ultimately struggle to ship. Startups should run on the JS ecosystem by default and only write code in other ecosystems if there's a very good reason to do so (business competitive advantage, JS ecosystem options are severely lacking...).
- rowanseymour 3y ago
  Obviously you gotta work with what you got and it might be the best business decision to hire some junior devs with no experience outside of JS/TS and build your CLI tool in that. But that's never going to be the best tool for CLI development, and someone with no experience outside of JS/TS (or any single language) is never going to be the best engineer.
  - solatic 3y ago
    > best business decision The best business decision is the only relevant decision in the real-world, unless you're building the software as a hobby and you're willing to essentially self-fund the development without regard to anything else outside your own enjoyment. If it's not your hobby, then you don't get to build perfect software, you get to build software that people are willing to fund (either through investment or purchase). People are only willing to fund software that ships. Professional development is an endless struggle to manage the sources of imperfection in the codebase; shipping perfect software is a pipedream. Shipping necessarily requires getting comfortable with shipping something imperfect and improving through iteration by shipping some more. So the first thing that you need to optimize for is shipping, and that is a function of who you can hire, what skillsets they have, and organizational design (including making cross-team collaboration easier by choosing standards, including language standards) that promotes shipping. Should you be so fortunate that you have many, many people purchasing your software, or your investors (or CFO/VP Finance by proxy) are convinced that you need to leave the JS ecosystem to attain or preserve competitive advantage, then fine, build your CLI in a language that offers more technical advantage to building CLI tools. But that's not the default.
irrational 3y ago
Proficient? Yes. But I have better things to do with my time. I enjoy spending time with my family, woodworking, baking, gardening, home remodeling, painting, studying ancient Afro-asiatic languages, reading, hiking, etc. The only way I’m going to learn a new language is if my work requires it and makes time for me to learn it. Well, we have far too much work to do to carve out time to learn new languages, so they just keep us using what we already know. That’s fine with me. I receive a hefty six figure income to pay for my life outside of work.
zsyllepsis 3y ago
> If all you have are TS developers, the. IMHO, you don’t have very good developers. Does it change anything to reframe this as having a common denominator across all developers? As in, rather than “All of my developers know only TS” to “TS is the common language all of my developers know”. Particularly in small companies I think it makes more sense to focus on a restricted set of tools and technologies. It makes interviewing easier, ensures mobility of hires to different areas of the code, and produces an easier onboarding experience for new team members. > It is also boring using only one programming language every day Interest and passion come from more aspects of a project than the language it was written in. Some projects are interesting because of they incorporate cutting edge research, some because they have highly visible impact on users, and others because the solution involves a careful balance of design constraints. Choice of (or diversity between) language doesn’t have to be the distinguishing factor that makes a project interesting.
deleted 3y ago
[deleted]
solarkraft 3y ago
I'm not an X developer, but I have experience with certain tools. Building on that experience is usually more efficient than starting over at 0.

giraffe_lady 3y ago

I think that person made a mistake in specifically mentioning rust and zig, because those are relatively uncommonly known languages among working webdevs. But I think you're making a mistake in assuming they mean someone should force a specific language on them. In practice nearly every working TS dev knows something else, python, ruby, elixir, yeah maybe go. They should choose one of those other languages for the tool. A specific one doesn't need to be forced on them, just the decision that it should not be TS.

Timon3 3y ago
If you're saying "just use something else", you'll have to actually compare TS to the languages you're proposing. If for example someone were to suggest Python for a backend, I'd argue that TS is many, many times better than Python. Can you explain why TS is so very much the wrong tool in your eyes?
- giraffe_lady 3y ago
  Just on a quick skim it seems like there are enough other people willing to take the other side of your "JS is good actually" position so I'm gonna pass today.

bluefishinit 3y ago

> If all you have are TS developers, writing a CLI in TS is not just fine, it's the right decision. Companies should be properly staffed to support the platforms they're distributing on. If you're building a CLI tool, you should have devs familiar with doing that use an appropriate language. You should not repurpose front-end web developers to build the CLI tool in a web front-end language just because that's all they know. That's pushing your business, training and hiring problems down to the user. Not to say web front-end devs can't make great CLIs (or servers)! It's just that they should train up on an appropriate stack if they're going to do so.

Timon3 3y ago
If everyone thought as you do, many companies simply wouldn't release a CLI tool, because hiring experienced developers just so you can use the "appropriate" language for a domain isn't realistic for most companies. I know it sounds nice, and I'd like the world to work differently too, but the reality is that resources are constrained enough that many developers have to be all-rounders, and you don't do that by learning the "right" language for every problem.
- randomdata 3y ago
  > many companies simply wouldn't release a CLI tool That's his point, though. Command line tools require a different skillset. If a team has only worked on browser applications, they won't have the skills for command line tools and will need to learn them. Taking time to learn contradicts the grandparent comment, which suggests that people should stay in their lane and that there is nothing worse than forcing developers to work on things they are not already familiar with. If one is going to hold that developers shouldn't be forced to learn on the job, even if by way of fellow teammates trying new approaches that others will need to maintain, you simply can't have them working on CLI tools and bringing on new teams that will operate independently is the only way to see movement into new areas.
  - Timon3 3y ago
    > Taking time to learn contradicts the grandparent comment, which suggests that people should stay in their lane and that there is nothing worse than forcing developers to work on things they are not already familiar with. My comment said no such thing. There is a difference between "types of applications you build in a language" and "language" (the first 7 words in the earlier one). It is much easier to learn how to write a different kind of application in a language you know, because you already know the language. You have to learn less. I'm not sure why you're putting things as if I've made some absolutist statement. All I'm saying is: You only have the resources you have, and the efficient way to use them (especially in the long term) is not to leave architecture and implementation to a team that knows neither the language nor the environment.

happytoexplain 3y ago

>Nothing is worse than developers being forced to work in a language they are not used to I think there are much, much worse things than this. Most of the time, I would count among those things the humongous downsides of JS, but it depends on your situation, obviously. There are plenty of cases where you should use JS/TS. But if I only knew TS and had an opportunity to write a CLI in Rust, I'd jump at the opportunity. It's not always the case, but lots of things are appropriate to use as an excuse to learn something new.

Timon3 3y ago
> Most of the time, I would count among those things the humongous downsides of JS, but it depends on your situation, obviously. Could you explain these "humongous downsides of JS"?

soggybutter 3y ago

This line of thinking is precisely why node and TypeScript are so pervasive. It has nothing to do with them being the right tool for the right job and everything to do with perceived lower barrier to entry and resistance to learning better tools. I would never try and use a hammer to saw a board in half, and yet that's exactly what people try and do with node/TS

Timon3 3y ago
I'm not saying that you should use TS & Node for everything, not sure how you got that wrong. I'm saying: use the tools your developers know. If you have Java developers, use Java. If you have Rust developers, use Rust. If you have Typescript developers, use Typescript. Don't give a metaphorical person without arms a saw to split a board in half, even if it's supposedly the right tool.
- soggybutter 3y ago
  I didn't really think you were saying they should be used for everything, but I do think discouraging branching out into better suited tools perpetuates using the lowest common denominator. If devs are never pushed out of their comfort zones, it's really hard for them to grow arms in order to use the saw. I do acknowledge I have a lot of bias, though, because I work at a TS shop where the primary reason we continue to use it is because we always have. The longer I have to put up with it, the more I feel like this is a broken foundation to stand on
  - Timon3 3y ago
    You shouldn't let developers branch out by trying to write their first real application in a completely new language as a productive thing for your company or your customers. They should learn by implementing real projects that will not be important or improved and maintained long-term.
crdrost 3y ago
I mean, they're also just kind of fun. Suppose you are building a CLI tool just for yourself, Deno is way more fun than Bash, say. Especially if your usecase starts to get into like tree traversals and stuff.

renegade-otter 3y ago

A large part of the bullshit that this industry has had to endure was exactly because a lot of front-end developers writing Javascript declared "we are all backend engineers now" and started using Node, thinking that UI development somehow translates to backend concepts. These are totally different areas of craft, like e-commerce vs game development.

Timon3 3y ago
But also many, many wonderful things came about because backend development became more approachable. You're right that inexperienced developers working in an environment they don't know produces a lot of horrible stuff, but that doesn't invalidate the good! And I wouldn't strictly differentiate between these areas. My game development experience helps me to write better backends and frontends alike. They are separate insofar that you have to learn each environment to be able to write idiomatic code, but it's not like you can't re-use parts of your knowledge across all of them.
- renegade-otter 3y ago
  I think the worst aspect of it is that the cohort of engineers was not taught to appreciate the complexity (of distributed systems in particular). This is something the industry is just trying to burry itself out of. It was a bad combination of "green" JS engineers writing servers and a new batch of fresh FAANG veterans mentoring them into writing extremely complex and expensive systems. There is a large dollar value attached to this fiasco.
  - Timon3 3y ago
    > I think the worst aspect of it is that the cohort of engineers was not taught to appreciate the complexity (of distributed systems in particular). This is something the industry is just trying to burry itself out of. It sounds like you have a bone to pick - because when was this ever not the case? Most developers of any generation don't really know about the complexity of distributed systems. Some developers do, even in "the cohort of engineers" who you say wasn't taught this. People using inexperienced (in the topic) developers for complex systems is not something new either. People use who they have.

Cthulhu_ 3y ago

I mean while I think hiring and availability is an important reason to pick a language, and so it makes sense to have e.g. Node / JS / TS as a back-end language. But it's not ideal. Another one would be to pick Java or C#, but the stereotype of a developer like that is that they will overcomplicate and make a heavy, enterprisey back-end; Node backends feel lighter, so I can again understand why they would rather have a Node / JS type developer, they're more pragmatic. Ideally you'd get a "polyglot" developer, or a developer who has embraced that language is just an implementation detail, someone who can see beyond a language and its ecosystem and stereotypes. But the hiring pool for those is small, and convincing them to work for your company is really difficult if it doesn't do anything exciting, new, or cannot pay a lot.

Timon3 3y ago
> Ideally you'd get a "polyglot" developer, or a developer who has embraced that language is just an implementation detail, someone who can see beyond a language and its ecosystem and stereotypes. But the hiring pool for those is small, and convincing them to work for your company is really difficult if it doesn't do anything exciting, new, or cannot pay a lot. That's kind of the approach I'm proposing. Don't care about the language, use the one your developers know best, because the language itself is just an implementation detail, while the proficiency will help you in any language. You're not going to get a large group of great polyglot developers, so you have to reverse the process and choose the language your developers know best.

snarfy 3y ago

What about the users? This whole thread is entirely developer centric. Odds are you are going to have 1000x more time users than developers. A native solution and not some node interpreted monstrosity is the right choice. We all loathe electron apps because they perform like shit. What's worse, inconvenience a handful of developers to learn a native language, or make thousands of users run node apps? The carbon footprint alone is worth it.

Timon3 3y ago
I disagree. If the program is fast enough for its purpose, and my developers can write better code (as in, code with better architecture allowing for flexible development while being easy to read) and develop features faster, it doesn't matter which language is "right", it matters which one will get the thing developed in an acceptable amount of time. Users would rather have bad software than no software, as you can see with Electron apps that perform like shit. I'm not saying that performance, memory consumption etc. are completely insignificant. I myself prefer to use faster tools that use less memory. But if all you have is a bunch of Typescript devs, and you want them to develop a CLI, you're not going to get a better result by telling them to do it in Rust. To get a better result you'd have to tell them to learn Rust and work in it for half a year. And yes, that would be better for users in the long run, but that doesn't mean it's realistic in all cases.

Gibbon1 3y ago

Writing a CLI in rust is just dumb. Really really really dumb. Just write it in C# and take the afternoon off.