Драйвово
А я думал что гонщики автоматом не пользуются

угадайте, куда я это всё (юзкейсы) загрузил?)

а по поводу писать для себя  на разных яп - неэффективно. Для себя многие куски кода нужно реюзать в разных проектах. Если это будет на 1 яп, то это будет лучше

если невозможно на 1, то чем меньше яп, тем лучше

Главное не писать на С++

\o/

логично, с эффективностью уменьшения стека трудно поспорить. Только все языки между собой различаются, как уже где-то было выше - на одном полюсе низкоуровневые, на другом - высокоуровневые, посередине где-то ди. Логика подсказывает, что если супер язык будет на каком-то полюсе, то дотянуться до кейсов другого полюса ему будет очень и очень трудно). Ди всем хорош, но популярность сказывается на либах, мда...

ну так-то от середины тянуться проще.

для себя пишешь что-то? много общего кода уже?

впрочем даже не для себя можно реюзать свои же какие-то кусочки

скорее не общий код, а общий архитект. Пока у меня есть набросок фреймворка на java\dart\dlang, архитект тут неплохо синхронизируется. В принципе, любой объектный язык можно более-менее натянуть на объектный фреймворк, в котором основная задача - обойтись без контейнера зависимостей и это та еще задачка.

а у меня вот что выходит по кусочкам (примитивам) - https://github.com/egorpugin/primitives/tree/master/src

а  по поводу архитекта - тоже где-то внутри этих примитивов нарабатыватся зачатки пока. И в других репах много заготовок есть (https://github.com/egorpugin/examples)

я любой проект делаю через CCD - core, common, domain. Соответственно, в core к концу проекта формируется микрофреймворк всегда, с common можно перебрать, один проект так испортил. На другом проекте он обкатывается, например, гуевые тулкиты склонны блокировать наследование и у многих языков нет множественного наследования, если в языке есть трейты - хорошо, если их нет... то это может быть проблемой.

а есть что-то в паблике посмотреть?

в каком?

я бы взял на вооружение, если пойму и дело стоящее

ну код

на гитхабе или где-то

>  CCD - core, common, domain

вот это меня заинтересовало

а, нет, я все проекты выпилил по лицензионным соображениям). Раньше на гитхабе их держал, но в core формируется фреймворк, который нужно постоянно поддерживать и вливать туда фиксы, это очень сильно обременяет, поэтому петы на гитхабе досвидания, оставиль только чисто экспериментальные.
В такой структуре есть небольшой недостаток.... по логике вещей core можно выделить в либы, общие для всех проектов, но тогда все иерархии получаются заблокированными, возможно, для плюсов это меньшая проблема, но в языках с одиночным наследованием это не дает никак настроить core из domain-логики т.е. специфичной для приложения. И это такая беда, что есть смысл пойти на хак и отнаследовать core-компоненты от domain, что чревато проблемами.