7 ms·

Why should using different languages for front-end and back-end be a problem? I rather think that it is better to use languages that are appropriate for the giv

by ale42 4y ago

Why should using different languages for front-end and back-end be a problem? I rather think that it is better to use languages that are appropriate for the given problem. It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance applications. Of course using the same language for the front-end might make no sense at all.

pjmlp 4y ago
Its seems to be a new thing with younger generations. We never had an issue with multiple languages across tier-n architectures. Suddenly with the uptake of HTML 5, it became an issue not being able to use JavaScript everywhere.
- maverwa 4y ago
  I think the argument was/is not "its a problem we cannot have javascript" but "if we can have javascript everywhere, we only need to hire javascript devs and only need to care about javascript tooling", which is a fair point. That does ignore the fact that an experienced frontend JS dev is not necessarily also a good productive backend JS dev, but at least they know the language basics, can use the same IDE, etc. If thats worth it is something that depends on what you try to achive, I guess. I personally would not pick JS (nor TS) for the backend.
  - biztos 4y ago
    And isn’t Wasm supposed to (some day) free us from the need to pick JS for the front end?
    - ggktk 4y ago
      Unfortunately, that doesn't seem the way WASM is going. It's been 5 years and we still can't access the DOM without going through JS.
      - jpgvm 4y ago
        There isn't the political will-power to make it happen and force all the browser vendors to agree and implement. Hence status-quo remains.
        afiori 4y ago
        Which is ironic as the DOM interface was designed as an abstract interface (the IDL used in the spec is more interested in compatibility with Java than JS). In practice though the main reason is that to have decent DOM bindings you need to stabilize many other specs first (unless you do a ultra-specific DOM-only extension, but nobody wants that)
      - marcosdumay 4y ago
        WASM can access the DOM by its foreign functions interface. It still needs some data conversion, but it's not through JS. Rust, for example, has a huge package with interfaces for every DOM function.
    - szundi 4y ago
      I am waiting to be able to run the JVM and have client side swing again in WASM
      - pjmlp 4y ago
        Why waiting when it is already available?
    - marcosdumay 4y ago
      I have been very successful in replacing a JS browser application with Rust. It has been great, because Rust is much easier to change, and since the application is complex, I need to change it a lot. But I wouldn't recommend it in general, because JS (and for slightly more complex things, TS) is much easier to create because of all the old Rust features that surface every time you mention it. And most GUI code is simple enough that you only have to write once, maybe fix a few details, and forget about it. Wasm would be much more compelling if it was target by higher level languages.
  - jpgvm 4y ago
    I think this has been a huge failing of our industry of late. The rise of the "fullstack developer" has mostly reduced quality across the board. When you hire a "fullstack developer with 5 years experience" you aren't getting someone who is as good as a frontend developer with 5 years AND a backend developer with 5 years but someone that adds up to 5 years split between those 2 endeavors but probably with less depth as a result of switching. (as a side note I also think it's contributed to developer title inflation) Learning a new language and its tooling is comparatively easy compared to learning the required domain knowledge to be effective in a new area. i.e transition from frontend -> backend or visa versa has very little to do with the language or tooling. Your average frontend dev doesn't know squat about RDBMS schema design or query optimisation, probably aren't familar with backend observability patterns like logging, metrics and tracing, most likely have very little experience thinking about consistency and concurrency in distributed systems, etc, etc. Just like the backend dev is going to struggle with the constraints of working in a frontend context, understanding UI interactions, optimizing for browser paint performance, dealing with layout and responsiveness, etc. Meanwhile if you know say Java and some scripting language, say Python and you end up a new job doing backend in JS it's not going to take long for you to pick up JS and hit the ground running because you are going to encounter exactly the same stuff just different syntax and runtime. Backend being substantially divorced from frontend isn't a bad thing, it's generally a good thing that results in nice clean separation of concerns and healthy push-pull in design decisions about where certain logic and responsibilities should lie etc.
    - bigDinosaur 4y ago
      Most 'fullstack' positions don't have nearly the complexity where worrying about concurrency etc. is actually that relevant. The idea that most frontend devs have any knowledge about optimising for browser paint performance beyond using the correct CSS or framework is funny ;-)
      - jpgvm 4y ago
        I know, we have seen insane developer inflation the last 10 years. The bar is generally just a lot lower now across the board. We have people with the title "Senior Engineer" that still regularly need mentorship and peer-programming sessions. The title I have now (Principal Engineer) I feel like I don't deserve, it was reserved for folks I looked up to when I was starting and I don't think I have reached their level. Yet at the same time it's essentially necessary to distinguish myself from what is now considered "Senior". I have a separate rant for the lack of proper juniors and lack of structured mentoring etc but that is for another day.
  - kristopolous 4y ago
    It's a taxonomy problem. The chunking unit is programming languages which means as long as you can call the task the specific programming language, people will believe it's the same thing. In reality you have a hammer expert and are in the business of making everything look like a nail. So now we have complicated bloated applications of JavaScript in places where it's absolutely inappropriate and you need far more skill to navigate those waters then someone who uses more appropriate tools. It's a perversion in the name of simplicity because we're forcing too coarse of a model on too fine of a problem and as a result everything explodes in complexity, takes too long, is too expensive and comes out working like trash. We could do better but first we have to eat crow and admit how foundationally wrong we were and frankly things aren't bad enough to make that mandatory so the circus continues just like it did when we tried to make everything OOP and it made the same smell. They're useful tools, but that's their perimeter; they aren't zeitgeists... well they shouldn't be.
  - marcosdumay 4y ago
    > which is a fair point It's a very effective way to make sure your team is only composed by junior developers.
- Izkata 4y ago
  The impression I've gotten from some of my co-workers is that in bootcamps and college they only learned one language, remember the time and effort that went into that, and assume learning another language will take the same time and effort. Because they haven't really put effort into a second one, they don't yet realize just how much conceptually transfers between the languages.
  - jsiepkes 4y ago
    While concepts transfer over between languages the language is only 10% of it. The rest of it is the standard library, ecosystem, buildsystem and all kinds of intricacies you have to know about and what not which is specific to the language (ecosystem).
    - waffles2021 4y ago
      There is also an issue with conceptual leakage, most noticeably I've found with devs well versed in one language bending another language into behaving like the former.
      - john_the_writer 4y ago
        That wares off if they have decent PR processes, and mentors. I write elixir that smells like rails, but as the months move on, I change.
      - snorremd 4y ago
        Agreed. You see this a lot with people with a C# and/or Java background using TypeScript with annotation based decorators and libraries/frameworks that implement dependency injection, etc. They don't really embrace the nature of the new language and ecosystem. And I can sympathise, it is simpler to do things as you have been doing them before. You also see it when people who've mostly done imperative programming tries their hands with a lisp or some ml based language. I've been there myself. You still find yourself using the equivalent of variable bindings, trying to write in an imperative rather than declarative style. I guess when trying to learn a new language in a different paradigm you also need to unlearn a lot of the concepts from the former language.
- cryptonym 4y ago
  That's sad, JavaScript was already not great for front-end and we now get it in backend and even the edge. Most job offers are for a mythical full-stack developper that'll master web design, CSS/HTML, front-end interactions and code, networking, back-end architectures, security,... You end-up with people who don't have time to get enough expertise and write and build clean stuff. Hacking poor JavaScript code everywhere. With the same language, you may think you can somehow reuse stuff between front and back. A bad idea in most project, will typically create more problem than it'll solve.
  - beachy 4y ago
    I'm far from a full stack developer, but really how much code would actually be common across the front and and back end? I would have thought maybe some validation code, not sure how much else?
    - majewsky 4y ago
      Sounds about right. I have an API service written in Go for which we also offer a client library in Go. We moved the common ground between the two into a separate module to avoid code duplication. That module ended up having the type declarations that appear on the API in JSON payloads, plus some serialization/validation helper methods, and that's it.
      - cryptonym 4y ago
        True, that can be a valid use-case. Another solution would be to leverage language agnostic API discovery solutions, generating the serialisation and part of validation code (swagger/open api/...). This way you provide a nice documentation and don't have to care about language differences while keeping good productivity.
    - spion 4y ago
      It depends. If you do server-side rendering with something like nextjs, then its quite a lot of code. With trpc you can share types without going through an intermediary schema language (https://trpc.io/ https://trpc.io/) although I think it would've still benefitted from separating the schema from the implementation (hope you don't forget the type specifier and import your backend into your frontend by accident) For business logic as always the anwwer is "it depends". Does your app benefit from zero-latency business logic updates? Do you need rich "work offline" functionality combined with a rich "run automation while I'm away" for the same processes? etc.
- febeling 4y ago
  It needs to be all Javascript, because Javascript in itself is already at least 5 languages, with ES6, browser runtimes, Node, ESM and CJS, and TypeScript, some CoffeeScript remenants, and the list doesn't end. There is no end to complexity.
- ratww 4y ago
  Most developers don't seem to want to learn more than "one" thing. Once they do one tutorial, it seems they're done for life with learning. And they don't really have time to learn new stuff, as they spend too much of their time on Hacker News complaining there's too many new frontend frameworks or something like that.
  - jalk 4y ago
    I have never met such a developer - most devs I have met, are way more eager to learn the next shiny thing than just getting the job done.
    - ratww 4y ago
      I know a lot of them, it's easy to identify as they constantly complain about shiny things.
- Existenceblinks 4y ago
  The sooner they accept that there were no such thing as one language to rule them all, the better developer they become. I have never seen the "isomorphic" claim to be seriously analyzed. One aspect example is how much logic behind the wall is overlap with the optimistic ui logic? Some logic may seem reusable but it may not. It's insane when I saw a popular js framework author on twitter said javascript is a language of the web, other backend languages are not (not exact words). Like WTH.
- ckdarby 4y ago
  It's about hiring talent that can drive customer value without concern for anything else and the business can eventually hire more experienced individuals to fix the mud mountain if there's market fit and continued need. It is extremely easier to find more affordable talent that has come out of a boot camps knowing javascript but more specifically "react/nodejs" which lets them work both frontend and backend. They rarely know best practices, how to properly debug & troubleshoot a problem that isn't a Google search away, etc, but they will be hungry and work their butts off to ship their CRUD style features.
davnicwil 4y ago
How do you know what the performance will be in what language or needs to be, in numerical terms, before you are running the system in practice?
- ocius 4y ago
  You can't really tell for a Web App whether it'll be faster in JS or Python, but you can definitely expect a Computer Vision application with lots of heavy number crunching to be a lot faster in C++ than in Python. We have actually also made comparisons, and even if you use things like numpy and Python bindings for OpenCV, you won't reach the speed that a C++ application achieves easily without optimization.
  - catwell 4y ago
    That depends a lot on what that CV application does and what hardware it runs on. Naive C++ (that runs on CPU) is usually much slower than using Python as glue for libraries that run on GPU.
- jrumbut 4y ago
  For a lot of applications there are pretty straightforward calculations to meet a desired frame rate. Also I've seen UX research that established some guidelines for how long something can take while still feeling responsive allowing a user to remain focused. Knowing you can achieve the required/desired performance in any given language is mostly a matter of experience solving similar problems.
lmm 4y ago
> It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. But the overwhelming majority of the time you don't need it, at least not yet. I would say that unless you have actual evidence that your other language would not be adequate - i.e. an implementation of your system or some representative subset of it, in your main language, that you spent a reasonable amount of time profiling and optimizing, and that still proved to have inadequate performance - then it is indeed premature.
- nicoburns 4y ago
  That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter), whereas rewriting it later would be a massive undertaking. This I very different to say starting a with a micro service architecture which imposes relatively high overheads, with little benefit as splitting up a well designed monolith is easy.
  - lmm 4y ago
    > That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter) The cases where Go is significantly faster than JavaScript are vanishingly small. > whereas rewriting it later would be a massive undertaking. This is vastly overstated IME. Porting existing code as-is between languages is actually pretty easy. > This I very different to say starting a with a micro service architecture which imposes relatively high overheads, Disagree. You're imposing a huge overhead on hiring (if you want people with both languages) or on people's ability to work on the whole system (if you're happy hiring people who only cover one side or the other). Debugging also gets a lot harder. There's essentially twice as many tools to learn.
    - tluyben2 4y ago
      > This is vastly overstated IME. Porting existing code as-is between languages is actually pretty easy. Yep. We always implemented (parts of) embedded software in Java first and later in JS and then port it. If no additional functionality is added, this is trivial and saves a lot of work and errors as you already tested, debugged and fixed the logic parts.
sorry_outta_gas 4y ago
it's not but this article is just blogspam
- ocius 4y ago
  We try to limit the amount of languages we use, but we have high performance Computer Vision code that is written in C++, we're interfacing that with Python for simplicity, and a web app in JS. Right tool for the job!
  - ale42 4y ago
    > Right tool for the job! Well said: this should be the only rule!
raverbashing 4y ago
Sounds like "consultant talk", too much fluff and big words but no nuance "Using different languages" is just Tuesday in most places. Sure, don't use languages needlessly, but it's not a big hurdle unless you're just a "nodejs bro"
varispeed 4y ago
> It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance applications. Given that probably most developers support the push to tackle the climate change, they seem to be making no effort to ensure their apps execute in as short time as possible using as little resources as possible. You would expect that people would actually embrace doing things in C or Go to save energy. Maybe cloud providers should think of showing the carbon footprint as a first class performance metric.
- alpaca128 4y ago
  Just like with code optimization we should first make sure making code run slightly more efficient really has an impact on the climate. Because I very much doubt it does. When you want to save the climate there are many, many low-hanging fruits. The choice of programming language is likely not one of them, as much as I like efficient code.
mtrower 4y ago
Honestly these are not optimizations at all, but rather architectural decisions. Large architectural decisions are generally best made at the outset, based on problem domain analysis. They are costly to change later. Like so many others, the author appears to be latching on to the phrase "premature optimization" as a popular buzzword (buzz...phrase?). This is so far from what Knuth actually wrote in his book that it hurts.
FpUser 4y ago
Exactly what I do. C++ backends, JS frontends. I do not see any problems with using more than one language.
philliphaydon 4y ago
If you are building a SaaS company and build your site in RoR, but also have experience in say Go, and decide 'hmm instead of using RoR ill use Go for this backend thing so its faster' That's fine. Premature optimization would be saying: I don't know Go/C++/C... but I know its fast, so instead of using what I know to get up and running quickly, i'll waste time building it in something I don't know which probably wont be as fast as doing it in something I know well. The thing is, when you're building it, no one is using it! If it's slower in RoR than Go, who cares, get it up and running, and fix it later when people are actually using it.

by ale42 4y ago

pjmlp 4y ago

Its seems to be a new thing with younger generations. We never had an issue with multiple languages across tier-n architectures. Suddenly with the uptake of HTML 5, it became an issue not being able to use JavaScript everywhere.

maverwa 4y ago
I think the argument was/is not "its a problem we cannot have javascript" but "if we can have javascript everywhere, we only need to hire javascript devs and only need to care about javascript tooling", which is a fair point. That does ignore the fact that an experienced frontend JS dev is not necessarily also a good productive backend JS dev, but at least they know the language basics, can use the same IDE, etc. If thats worth it is something that depends on what you try to achive, I guess. I personally would not pick JS (nor TS) for the backend.
- biztos 4y ago
  And isn’t Wasm supposed to (some day) free us from the need to pick JS for the front end?
  - ggktk 4y ago
    Unfortunately, that doesn't seem the way WASM is going. It's been 5 years and we still can't access the DOM without going through JS.
    - jpgvm 4y ago
      There isn't the political will-power to make it happen and force all the browser vendors to agree and implement. Hence status-quo remains.
      - afiori 4y ago
        Which is ironic as the DOM interface was designed as an abstract interface (the IDL used in the spec is more interested in compatibility with Java than JS). In practice though the main reason is that to have decent DOM bindings you need to stabilize many other specs first (unless you do a ultra-specific DOM-only extension, but nobody wants that)
    - marcosdumay 4y ago
      WASM can access the DOM by its foreign functions interface. It still needs some data conversion, but it's not through JS. Rust, for example, has a huge package with interfaces for every DOM function.
  - szundi 4y ago
    I am waiting to be able to run the JVM and have client side swing again in WASM
    - pjmlp 4y ago
      Why waiting when it is already available?
  - marcosdumay 4y ago
    I have been very successful in replacing a JS browser application with Rust. It has been great, because Rust is much easier to change, and since the application is complex, I need to change it a lot. But I wouldn't recommend it in general, because JS (and for slightly more complex things, TS) is much easier to create because of all the old Rust features that surface every time you mention it. And most GUI code is simple enough that you only have to write once, maybe fix a few details, and forget about it. Wasm would be much more compelling if it was target by higher level languages.
- jpgvm 4y ago
  I think this has been a huge failing of our industry of late. The rise of the "fullstack developer" has mostly reduced quality across the board. When you hire a "fullstack developer with 5 years experience" you aren't getting someone who is as good as a frontend developer with 5 years AND a backend developer with 5 years but someone that adds up to 5 years split between those 2 endeavors but probably with less depth as a result of switching. (as a side note I also think it's contributed to developer title inflation) Learning a new language and its tooling is comparatively easy compared to learning the required domain knowledge to be effective in a new area. i.e transition from frontend -> backend or visa versa has very little to do with the language or tooling. Your average frontend dev doesn't know squat about RDBMS schema design or query optimisation, probably aren't familar with backend observability patterns like logging, metrics and tracing, most likely have very little experience thinking about consistency and concurrency in distributed systems, etc, etc. Just like the backend dev is going to struggle with the constraints of working in a frontend context, understanding UI interactions, optimizing for browser paint performance, dealing with layout and responsiveness, etc. Meanwhile if you know say Java and some scripting language, say Python and you end up a new job doing backend in JS it's not going to take long for you to pick up JS and hit the ground running because you are going to encounter exactly the same stuff just different syntax and runtime. Backend being substantially divorced from frontend isn't a bad thing, it's generally a good thing that results in nice clean separation of concerns and healthy push-pull in design decisions about where certain logic and responsibilities should lie etc.
  - bigDinosaur 4y ago
    Most 'fullstack' positions don't have nearly the complexity where worrying about concurrency etc. is actually that relevant. The idea that most frontend devs have any knowledge about optimising for browser paint performance beyond using the correct CSS or framework is funny ;-)
    - jpgvm 4y ago
      I know, we have seen insane developer inflation the last 10 years. The bar is generally just a lot lower now across the board. We have people with the title "Senior Engineer" that still regularly need mentorship and peer-programming sessions. The title I have now (Principal Engineer) I feel like I don't deserve, it was reserved for folks I looked up to when I was starting and I don't think I have reached their level. Yet at the same time it's essentially necessary to distinguish myself from what is now considered "Senior". I have a separate rant for the lack of proper juniors and lack of structured mentoring etc but that is for another day.
- kristopolous 4y ago
  It's a taxonomy problem. The chunking unit is programming languages which means as long as you can call the task the specific programming language, people will believe it's the same thing. In reality you have a hammer expert and are in the business of making everything look like a nail. So now we have complicated bloated applications of JavaScript in places where it's absolutely inappropriate and you need far more skill to navigate those waters then someone who uses more appropriate tools. It's a perversion in the name of simplicity because we're forcing too coarse of a model on too fine of a problem and as a result everything explodes in complexity, takes too long, is too expensive and comes out working like trash. We could do better but first we have to eat crow and admit how foundationally wrong we were and frankly things aren't bad enough to make that mandatory so the circus continues just like it did when we tried to make everything OOP and it made the same smell. They're useful tools, but that's their perimeter; they aren't zeitgeists... well they shouldn't be.
- marcosdumay 4y ago
  > which is a fair point It's a very effective way to make sure your team is only composed by junior developers.
Izkata 4y ago
The impression I've gotten from some of my co-workers is that in bootcamps and college they only learned one language, remember the time and effort that went into that, and assume learning another language will take the same time and effort. Because they haven't really put effort into a second one, they don't yet realize just how much conceptually transfers between the languages.
- jsiepkes 4y ago
  While concepts transfer over between languages the language is only 10% of it. The rest of it is the standard library, ecosystem, buildsystem and all kinds of intricacies you have to know about and what not which is specific to the language (ecosystem).
  - waffles2021 4y ago
    There is also an issue with conceptual leakage, most noticeably I've found with devs well versed in one language bending another language into behaving like the former.
    - john_the_writer 4y ago
      That wares off if they have decent PR processes, and mentors. I write elixir that smells like rails, but as the months move on, I change.
    - snorremd 4y ago
      Agreed. You see this a lot with people with a C# and/or Java background using TypeScript with annotation based decorators and libraries/frameworks that implement dependency injection, etc. They don't really embrace the nature of the new language and ecosystem. And I can sympathise, it is simpler to do things as you have been doing them before. You also see it when people who've mostly done imperative programming tries their hands with a lisp or some ml based language. I've been there myself. You still find yourself using the equivalent of variable bindings, trying to write in an imperative rather than declarative style. I guess when trying to learn a new language in a different paradigm you also need to unlearn a lot of the concepts from the former language.
cryptonym 4y ago
That's sad, JavaScript was already not great for front-end and we now get it in backend and even the edge. Most job offers are for a mythical full-stack developper that'll master web design, CSS/HTML, front-end interactions and code, networking, back-end architectures, security,... You end-up with people who don't have time to get enough expertise and write and build clean stuff. Hacking poor JavaScript code everywhere. With the same language, you may think you can somehow reuse stuff between front and back. A bad idea in most project, will typically create more problem than it'll solve.
- beachy 4y ago
  I'm far from a full stack developer, but really how much code would actually be common across the front and and back end? I would have thought maybe some validation code, not sure how much else?
  - majewsky 4y ago
    Sounds about right. I have an API service written in Go for which we also offer a client library in Go. We moved the common ground between the two into a separate module to avoid code duplication. That module ended up having the type declarations that appear on the API in JSON payloads, plus some serialization/validation helper methods, and that's it.
    - cryptonym 4y ago
      True, that can be a valid use-case. Another solution would be to leverage language agnostic API discovery solutions, generating the serialisation and part of validation code (swagger/open api/...). This way you provide a nice documentation and don't have to care about language differences while keeping good productivity.
  - spion 4y ago
    It depends. If you do server-side rendering with something like nextjs, then its quite a lot of code. With trpc you can share types without going through an intermediary schema language (https://trpc.io/ https://trpc.io/) although I think it would've still benefitted from separating the schema from the implementation (hope you don't forget the type specifier and import your backend into your frontend by accident) For business logic as always the anwwer is "it depends". Does your app benefit from zero-latency business logic updates? Do you need rich "work offline" functionality combined with a rich "run automation while I'm away" for the same processes? etc.
febeling 4y ago
It needs to be all Javascript, because Javascript in itself is already at least 5 languages, with ES6, browser runtimes, Node, ESM and CJS, and TypeScript, some CoffeeScript remenants, and the list doesn't end. There is no end to complexity.
ratww 4y ago
Most developers don't seem to want to learn more than "one" thing. Once they do one tutorial, it seems they're done for life with learning. And they don't really have time to learn new stuff, as they spend too much of their time on Hacker News complaining there's too many new frontend frameworks or something like that.
- jalk 4y ago
  I have never met such a developer - most devs I have met, are way more eager to learn the next shiny thing than just getting the job done.
  - ratww 4y ago
    I know a lot of them, it's easy to identify as they constantly complain about shiny things.
Existenceblinks 4y ago
The sooner they accept that there were no such thing as one language to rule them all, the better developer they become. I have never seen the "isomorphic" claim to be seriously analyzed. One aspect example is how much logic behind the wall is overlap with the optimistic ui logic? Some logic may seem reusable but it may not. It's insane when I saw a popular js framework author on twitter said javascript is a language of the web, other backend languages are not (not exact words). Like WTH.
ckdarby 4y ago
It's about hiring talent that can drive customer value without concern for anything else and the business can eventually hire more experienced individuals to fix the mud mountain if there's market fit and continued need. It is extremely easier to find more affordable talent that has come out of a boot camps knowing javascript but more specifically "react/nodejs" which lets them work both frontend and backend. They rarely know best practices, how to properly debug & troubleshoot a problem that isn't a Google search away, etc, but they will be hungry and work their butts off to ship their CRUD style features.

davnicwil 4y ago

How do you know what the performance will be in what language or needs to be, in numerical terms, before you are running the system in practice?

ocius 4y ago
You can't really tell for a Web App whether it'll be faster in JS or Python, but you can definitely expect a Computer Vision application with lots of heavy number crunching to be a lot faster in C++ than in Python. We have actually also made comparisons, and even if you use things like numpy and Python bindings for OpenCV, you won't reach the speed that a C++ application achieves easily without optimization.
- catwell 4y ago
  That depends a lot on what that CV application does and what hardware it runs on. Naive C++ (that runs on CPU) is usually much slower than using Python as glue for libraries that run on GPU.
jrumbut 4y ago
For a lot of applications there are pretty straightforward calculations to meet a desired frame rate. Also I've seen UX research that established some guidelines for how long something can take while still feeling responsive allowing a user to remain focused. Knowing you can achieve the required/desired performance in any given language is mostly a matter of experience solving similar problems.

lmm 4y ago

> It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. But the overwhelming majority of the time you don't need it, at least not yet. I would say that unless you have actual evidence that your other language would not be adequate - i.e. an implementation of your system or some representative subset of it, in your main language, that you spent a reasonable amount of time profiling and optimizing, and that still proved to have inadequate performance - then it is indeed premature.

nicoburns 4y ago
That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter), whereas rewriting it later would be a massive undertaking. This I very different to say starting a with a micro service architecture which imposes relatively high overheads, with little benefit as splitting up a well designed monolith is easy.
- lmm 4y ago
  > That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter) The cases where Go is significantly faster than JavaScript are vanishingly small. > whereas rewriting it later would be a massive undertaking. This is vastly overstated IME. Porting existing code as-is between languages is actually pretty easy. > This I very different to say starting a with a micro service architecture which imposes relatively high overheads, Disagree. You're imposing a huge overhead on hiring (if you want people with both languages) or on people's ability to work on the whole system (if you're happy hiring people who only cover one side or the other). Debugging also gets a lot harder. There's essentially twice as many tools to learn.
  - tluyben2 4y ago
    > This is vastly overstated IME. Porting existing code as-is between languages is actually pretty easy. Yep. We always implemented (parts of) embedded software in Java first and later in JS and then port it. If no additional functionality is added, this is trivial and saves a lot of work and errors as you already tested, debugged and fixed the logic parts.

sorry_outta_gas 4y ago

it's not but this article is just blogspam

ocius 4y ago
We try to limit the amount of languages we use, but we have high performance Computer Vision code that is written in C++, we're interfacing that with Python for simplicity, and a web app in JS. Right tool for the job!
- ale42 4y ago
  > Right tool for the job! Well said: this should be the only rule!

raverbashing 4y ago

Sounds like "consultant talk", too much fluff and big words but no nuance "Using different languages" is just Tuesday in most places. Sure, don't use languages needlessly, but it's not a big hurdle unless you're just a "nodejs bro"

varispeed 4y ago

> It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance applications. Given that probably most developers support the push to tackle the climate change, they seem to be making no effort to ensure their apps execute in as short time as possible using as little resources as possible. You would expect that people would actually embrace doing things in C or Go to save energy. Maybe cloud providers should think of showing the carbon footprint as a first class performance metric.

alpaca128 4y ago
Just like with code optimization we should first make sure making code run slightly more efficient really has an impact on the climate. Because I very much doubt it does. When you want to save the climate there are many, many low-hanging fruits. The choice of programming language is likely not one of them, as much as I like efficient code.

mtrower 4y ago

Honestly these are not optimizations at all, but rather architectural decisions. Large architectural decisions are generally best made at the outset, based on problem domain analysis. They are costly to change later. Like so many others, the author appears to be latching on to the phrase "premature optimization" as a popular buzzword (buzz...phrase?). This is so far from what Knuth actually wrote in his book that it hurts.

FpUser 4y ago

Exactly what I do. C++ backends, JS frontends. I do not see any problems with using more than one language.

philliphaydon 4y ago

If you are building a SaaS company and build your site in RoR, but also have experience in say Go, and decide 'hmm instead of using RoR ill use Go for this backend thing so its faster' That's fine. Premature optimization would be saying: I don't know Go/C++/C... but I know its fast, so instead of using what I know to get up and running quickly, i'll waste time building it in something I don't know which probably wont be as fast as doing it in something I know well. The thing is, when you're building it, no one is using it! If it's slower in RoR than Go, who cares, get it up and running, and fix it later when people are actually using it.