8 ms·

While I agree with you, I just started a new project and we need a decent amount of backend work done, and I wanted to do that in Golang, Java, or Rust, but no

While I agree with you, I just started a new project and we need a decent amount of backend work done, and I wanted to do that in Golang, Java, or Rust, but no one else on the team knows Golang, Java or Rust, just Javascript and Typescript so it made sense to go with a language the team was good with. So far I'm liking typescript on the backend, especially because we use it on the frontend. Also my coworkers can give me much better code reviews because they all know the language. But we will see going forward, still very much a green field project.

johnwyles 8y ago
My $0.02 but that is NOT a reason to use JS on the backend. That is an argument to cross-train or hire someone. It's like saying "We only had an expert on building houses made with straw so we chose straw." Because they know the language doesn't mean for one moment that that will make a good background there are so many concepts, services, paradigms and best practices that the language is probably the least of importance other than it should be something solid, robust, and battle tested which I would argue against with most JS backends although some are fairly well understood.
- 2trill2spill 8y ago
  Yea sure, but removing the language as a thing to learn makes it easier to learn concepts needed for programing on the backend. Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust.
  - BigJono 8y ago
    > Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust. Oh god... Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.
    - 2trill2spill 8y ago
      What kind of "good engineer" refuses to write tests?
      - BigJono 8y ago
        I know a couple that would tell me to go jump if I suggested they aim for 90% code coverage on a CRUD app. They also write very clean, maintainable code and do it very, very quickly. There's always a trade off.
        2trill2spill 8y ago
        I'm not writing a CRUD app, I'm writing a program that my company expects to put into production. Writing tests is very much a part of writing production code.
        BigJono 8y ago
        ? CRUD apps generally go into production, unless something goes horribly wrong.
        TeMPOraL 8y ago
        If you're in webdev, CRUD apps is probably 95+% of what gets put into production. CRUD isn't meant as pejorative here, it's just most of the things people do with software fits in the model of Create/Read/Update/Delete access to a DB.
        spricket 8y ago
        I'm one of those. Unit tests are a waste of time IMO. It usually takes almost as much code to test logic as it does to write it, so I always wondered why the TDD folks don't just implement the code twice and check the result at the end :)
      - spricket 8y ago
        I don't write many tests. I've found with experience and heavy linting you can avoid the vast majority of bugs. Not much point to spending a ton of time on tests if they hardly ever break for nontrivial reasons. My normal setup for java is: Linters: ErrorProne Checkstyle PMD SpotBugs Nullaway All with highly customized settings All warnings enabled on javac Google-java-format to autoformat everything on build. For runtime analysis: LeakCanary to find memory leaks Hibernate with interceptors to find long queries Rest framework or gRPC with interceptors for long calls Proxied JDBC connector to find long or N+1 queries Opentracing/Zipkin integration to make debugging crazy stuff easier NewRelic for projects where the $ makes sense And I'm always on the lookout for more of these tools. In the long-run they save enormous amounts of time by preventing buggy code and keeping most shitty hacks out of the codebase. Unlike tests, they don't break constantly and add more maintenance burden to the codebase. And it's less work, one time setup vs ~50% codebase bloat to add tests. I see project leads call for more tests all the time to "fix" an unreliable codebase where there's zero linting. It won't save you from everything but I swear it's like 95% bug reduction. You should have most/all of these tools in place before you consider writing the first tests
winter_blue 8y ago
Seriously, not knowing the language shouldn't be a factor in choosing a language. Just choose the best programming language, and everyone can learn it; and they'll be happy and grateful in the long run that they chose to learn this new language, rather than use whatever they were familiar with. Moreover, Java is such a simple and an easy language to pick up. If the cruft is too much to deal with, go with Kotlin. An experienced developer could learn either language (Java or Kotlin) easily over a single weekend.
- RussianCow 8y ago
  This isn't always a useful way to look at it. For a startup or small team especially, any time spent learning a new programming language is time spent not working on the core product. Yes, you might be better off in the long run using a more foreign programming language, but then again the business might not survive that long if you aren't actually building anything. Also, it's easy to learn a language's syntax over a weekend, but it generally takes a lot longer to start being productive and writing idiomatic code in a new language, especially if you're also learning a new platform. That's time that you or your team may not have.
  - johnwyles 8y ago
    As I said above: hire someone new or invest the time to learn the language. Just because someone knows how to make a cute scarf using duct tape, safety scissors, and Elmers glue doesn't mean they should be building your backend driving the company 95 mph with seatbelts, airbags, and a chassis with crumple-zones.
    - 2trill2spill 8y ago
      Hiring someone is very time consuming, and requires paying another salary, benefits, etc. Also learning a new language takes time, yes a person can learn the basics of a language in a day or two, but it will be a long time before they are equally proficient with that new language.
      - 8y ago
tracker1 8y ago
I find that beyond this, not having a cognitive disconnect in working on the frontend/backend is really nice. And depending on your data tier(s), can even go there (Mongo, Plv8, etc). Compared to when I'd have to use ActionScript, JavaScript, VBScript, VB6, T-SQL daily... that was sometimes painful... then adding C# and VB.Net to the mix was ugly having to switch from one area of code to another.

johnwyles 8y ago

My $0.02 but that is NOT a reason to use JS on the backend. That is an argument to cross-train or hire someone. It's like saying "We only had an expert on building houses made with straw so we chose straw." Because they know the language doesn't mean for one moment that that will make a good background there are so many concepts, services, paradigms and best practices that the language is probably the least of importance other than it should be something solid, robust, and battle tested which I would argue against with most JS backends although some are fairly well understood.

2trill2spill 8y ago
Yea sure, but removing the language as a thing to learn makes it easier to learn concepts needed for programing on the backend. Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust.
- BigJono 8y ago
  > Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust. Oh god... Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.
  - 2trill2spill 8y ago
    What kind of "good engineer" refuses to write tests?
    - BigJono 8y ago
      I know a couple that would tell me to go jump if I suggested they aim for 90% code coverage on a CRUD app. They also write very clean, maintainable code and do it very, very quickly. There's always a trade off.
      - 2trill2spill 8y ago
        I'm not writing a CRUD app, I'm writing a program that my company expects to put into production. Writing tests is very much a part of writing production code.
        BigJono 8y ago
        ? CRUD apps generally go into production, unless something goes horribly wrong.
        TeMPOraL 8y ago
        If you're in webdev, CRUD apps is probably 95+% of what gets put into production. CRUD isn't meant as pejorative here, it's just most of the things people do with software fits in the model of Create/Read/Update/Delete access to a DB.
      - spricket 8y ago
        I'm one of those. Unit tests are a waste of time IMO. It usually takes almost as much code to test logic as it does to write it, so I always wondered why the TDD folks don't just implement the code twice and check the result at the end :)
    - spricket 8y ago
      I don't write many tests. I've found with experience and heavy linting you can avoid the vast majority of bugs. Not much point to spending a ton of time on tests if they hardly ever break for nontrivial reasons. My normal setup for java is: Linters: ErrorProne Checkstyle PMD SpotBugs Nullaway All with highly customized settings All warnings enabled on javac Google-java-format to autoformat everything on build. For runtime analysis: LeakCanary to find memory leaks Hibernate with interceptors to find long queries Rest framework or gRPC with interceptors for long calls Proxied JDBC connector to find long or N+1 queries Opentracing/Zipkin integration to make debugging crazy stuff easier NewRelic for projects where the $ makes sense And I'm always on the lookout for more of these tools. In the long-run they save enormous amounts of time by preventing buggy code and keeping most shitty hacks out of the codebase. Unlike tests, they don't break constantly and add more maintenance burden to the codebase. And it's less work, one time setup vs ~50% codebase bloat to add tests. I see project leads call for more tests all the time to "fix" an unreliable codebase where there's zero linting. It won't save you from everything but I swear it's like 95% bug reduction. You should have most/all of these tools in place before you consider writing the first tests

winter_blue 8y ago

Seriously, not knowing the language shouldn't be a factor in choosing a language. Just choose the best programming language, and everyone can learn it; and they'll be happy and grateful in the long run that they chose to learn this new language, rather than use whatever they were familiar with. Moreover, Java is such a simple and an easy language to pick up. If the cruft is too much to deal with, go with Kotlin. An experienced developer could learn either language (Java or Kotlin) easily over a single weekend.

RussianCow 8y ago
This isn't always a useful way to look at it. For a startup or small team especially, any time spent learning a new programming language is time spent not working on the core product. Yes, you might be better off in the long run using a more foreign programming language, but then again the business might not survive that long if you aren't actually building anything. Also, it's easy to learn a language's syntax over a weekend, but it generally takes a lot longer to start being productive and writing idiomatic code in a new language, especially if you're also learning a new platform. That's time that you or your team may not have.
- johnwyles 8y ago
  As I said above: hire someone new or invest the time to learn the language. Just because someone knows how to make a cute scarf using duct tape, safety scissors, and Elmers glue doesn't mean they should be building your backend driving the company 95 mph with seatbelts, airbags, and a chassis with crumple-zones.
  - 2trill2spill 8y ago
    Hiring someone is very time consuming, and requires paying another salary, benefits, etc. Also learning a new language takes time, yes a person can learn the basics of a language in a day or two, but it will be a long time before they are equally proficient with that new language.
    - 8y ago

tracker1 8y ago

I find that beyond this, not having a cognitive disconnect in working on the frontend/backend is really nice. And depending on your data tier(s), can even go there (Mongo, Plv8, etc). Compared to when I'd have to use ActionScript, JavaScript, VBScript, VB6, T-SQL daily... that was sometimes painful... then adding C# and VB.Net to the mix was ugly having to switch from one area of code to another.