If I were to inherit a C++ and JS+React codebase with a long-term intent to keep on developing and supporting it, I'd definitely write the "glue" code in CLJ[S] and interop with some lower-level C++/JS pieces of functionality. Anything new would be written in CLJ[S], unless for some reason it makes more sense to use C++ or JS for that particular part. JS interop is trivial, most of the time. C++ interop is cumbersome but doable. Not safe though as it may crash the whole app. But given that you start with a C++ codebase, that's already true for you.

There's also an option of going in the other direction - instead of Clojure, use one of its varieties that transpiles into C or C++ and use that from the existing C++ code. But this approach has caveats on its own.

I think it depends what is your c++ module built to do ! and what kind of integrate way you apply to your js/react & c++ module, restful api? abi? or other. also it depends how complicate your c++ part is, what function it provide? is it possible to rewrite it in clojure/cljs, that’s also an option if the code base scale and workload is acceptable as producivity of clojure is 10 times of c++ at least!

Thanks for your reply. A bit of background: the current codebase is a fork of https://github.com/cryptonomex. I hired some of the people who wrote the code of this open source project - Cryptonomex is a Blockchain based crypto exchange. But my product has NOTHING todo with Crypto or Blockchains. I could do it without the Blockchain part entirely. It just happened to be that I needed an order matching engine, an order book etc which this project had. Now I need a CTO and one of the best candidates has a Clojure focus... Rewrite everything from scratch with Clojure in mind? Instead choose a CTO with a C++ focus? Hard for me to decide since I'm not a developer.

And that's hard for us to advise on because we're not founders of your company. :) Personally, I'd lean towards good people instead of existing technologies. Assuming your judgement is correct, proper engineers will be able to figure out the best course of action on their own or with your help, but without you having to delve into technical details.

The good people approach makes sense. Thanks for the input!

From a distance, @U04H4BCJD6W, in my experience significantly revising an existing package always turns out to be tantamount to "rewrite everything from scratch", or worse because one ends wrestling with the legacy system's tech debt. Cue the metaphor about replacing every part of a chair one part at a time. A nice compromise might be to stipulate Cryptonomex as the functional target but give your CLJ candidate their head on whether or not to use CLJS. Having a specific functional target will avoid wheel-spinning over exactly what to build, the biggest risk to projects like yours.

From one non-tech founder to another who has spent the last 2+ years feeling the pain of integrating 2 huge C++ apps into our larger, custom Clojure app, my first question would be, have you searched for a existing, viable Clojure alternative to cryptonomex? https://github.com/search?l=&o=desc&q=blockchain+language%3AClojure&s=stars&type=Repositories. Perhaps you could find a different starting place that wouldn't require rewriting from scratch.

Thanks for the input, all very helpful. @U0PUGPSFR can you explain what you meant by functional target? I was pretty set on the Cryptonomex software because it had most of the functionality I need. I said I hired people already to adapt the Cryptonomex code for me, more accurate would have been: I was about to hire them because I was pretty set on it. Is an application written in c++ more difficult/ cost intensiv to maintain in general or why did you @U01040R5CJY hint that it's better done in Clojure than in c++? The conclusion I have drawn in general from your replies is: EITHER do prototyping extremely cheaply so that it doesn't hurt to do things from scratch at some point OR to do it right from the beginning which is more expensive but doesn't require starting from scratch at some point. Anything in the middle is painful.

@U04H4BCJD6W By "functional target" I meant you can say to your developers "see what Cryptonomex does in re order matching, order book, etc? That is what we want to build, nothing less, nothing more. Do it any way you think fastest for now and the long run." If you just say, "I need an order matching engine, an order book etc", the team begins by finding out what specific features you have in mind, and may well end up missing the target, leaving out important elements, and adding new elements that seem reasonable. Again, in my experience you will not save much time by adapting existing code, you may in fact go slower, and once you have your minimum product, you will be stuck with lesser tools forever. Mind you, if your chosen dev also loves the Crytonomex code and is adept at the existing tools -- that is why I suggested you ask them.

@U0PUGPSFR ok makes sense!

if there's no technical need for c++ i would suggest to move away from it (not really sure if clojure is a good fit for you (it might be), but java / c# / python devs are definitely way way easier to hire if in need, and if you want a safer feeling and a more modern language at low level i would look at rust instead) if your application really needs it. it's ok. if you want to grow your company quickly at some point - hiring good c++ devs that actually want to do something is pretty darn hard.

I would concur with p-himik’s advice, good engineers will figure out the way better. More than direct runtime interop I would expose the C++ code via http apis that will be called by the new ClJ code that the new founder might decide to build.

Of the two C++ code bases I referenced above @U04H4BCJD6W, one is a graphic editor (Inkscape) and the other is a CAD editor (Kudo). Creating our own CAD and graphics engines in Clojure was not an option and we did not find any existing editors built in Clojure, at least none that possessed the required GUI interface and editing tools. Since we're committed to Clojure/Datomic, our first approach is typically to try and find something written in Clojure that fits the requirement or at least part of the requirement. I was speaking only to our integration or interoperability effort, not ongoing maintenance cost which you'll incur to one degree or another regardless of programming lanugage. For us, Clojure to Clojure (all requirements being equally met) should result in lower one-time integration cost given our developers preference for, and the company's commitment to, Clojure. And searching for existing Clojure libraries that fill specific needs has proven a worthwhile endeavor for us. It's also a plus that a non-tech founder like me can conduct these searches which allows our developers to focus on writing code.

https://plantuml.com/ FTW

https://app.diagrams.net/ is a pretty good generic diagramming tool.

thanks, both tools looks great!

https://www.websequencediagrams.com/

(it's text, but it's simple text)

Web sequence diagrams uses PlantUML , IIRC

I've used SequenceDiagram (offline-first web app) for some pretty big sequence diagrams. Can recommend: https://sequencediagram.org/

plantuml

works just well enough

https://mermaid.live/ this is what i always go for.

https://www.umlet.com/

Another tool which i've used to do simple drawings is this on-line drawing SAAS product, https://whimsical.com If i recall they are implemented in Clojure/ClojureScript.