Clojurians Log v2

@robert.todea 98% of the repo is Clojure. Now polylith support cljs we rewrite old Javascript code to ClojureScript. The old Javascript is in a folder and don’t part to the polylith stuff.

@robert.todea Imagine you've got a polylith with three project bricks, 1. one for a Ruby Go program 2. another for a Python program 3. and the third for a Clojure Rust program and for some reason they all depend on some C library you wrote for something they do (through FFI or their own wrapper libraries). You would have the C library in a component brick, and (probably) one base and one corresponding project brick per program that you write in any of the languages using the C library. Each project brick has its own name (unlikely to be suffixed by the programming language they deal with as they exist for their own purposes) and its own build/deploy tooling. Each project brick would be built, released, sold, as a thing of its own. Despite being in different languages, despite doing different things, despite all three depending on your C library component brick.

@licina.luka is this hypothetical something you worked on? 🙂 You mention things at the project level. How is it on the component level? How would you make sense of the different languages having to live alongside each other. E.g. components/foo/analytics (for Python) and components/foo/converter (in Rust). Wouldn't, for example, the info tool get confused when showing the dependencies? How would also the development folder look like? The one hosting the REPL stuff. Just curious.

You've got a point that it's a bit more involved however if a software system can't deal with a polyglot polylith its got other problems. Polylith is good at allowing multiple different teams do work on a system comprised of many different parts and avoid conflicts or confusion. From my point of view a team doing Rust work in a polylith would have even fewer run-ins with another team doing Python work in the same polylith compared to a non-polylith environment. At work I'm about to deal with these, I'd done it in solo hobby projects (Clojure dominated polylith with two CRuby projects, another is a Python dominated polylith with a Clojure project (extracted here https://github.com/lukal-x/datomic-schema-postgres/).

Hi! Yes I think you could. At work we have old NodeJS service still write in JavaScript. We have put them in a specific folder at the root of our polylith repository.

Ask yourself, “Can I solve this with a monolith?”. If the answer is yes, then you can also solve it with Polylith (with or without tooling support).

Sweet :)

@jean.boudet11, is your polylith mono-repo a combination of JavaScript and Typescript? > Can I solve this with a monolith? @tengstrand I don't think for this case the answer is a yes. For me, a monolith is confined to a single language ecosystem. The monolith shines when I can easily import things around (and have a good IDE). But let's make a small sketch for > How would that work in a polyglot monolith? E.g. 1. Go --- build with go 2. Python --- build with uv 3. Rust --- build with cargo You could keep the overall folder structure, and rely on some conventions at the level of the namespaces, e.g.: 1. foo-go --- the namespace for Go stuff 2. foo-py --- the namespace for Python stuff 3. foo-rust --- the namespace for Rust stuff Then you would need REPLs for each language. Sometimes you would define models that need to be used across. Maybe you would need to settle on an IDL (Interface Definition Language) like OpenAPI/JSON, Protobuf. Also you might want to abstract the various CLI tools via something like a Makefile, Taskfile, nix etc. To recap, @aaronrebmann, I don't think polylith was built with this in mind. It can be evolved into a polyglot polylith (`poly*²`)* but it will require a more intricate setup 🧶 Would love to see it, nevertheless!