4 ms·

I'm super curious, what would you recommend for a tech stack that "[has] a good build system, good incremental compilation, proper test framework integration, e

I'm super curious, what would you recommend for a tech stack that "[has] a good build system, good incremental compilation, proper test framework integration, etc"?

jpgvm 4y ago
Personally Kotlin/JVM. Gradle gets the job done, incremental (and concurrent) builds are fast, etc. You can also use just plain Java if you prefer if you really want a very fast compile time. Arguably Golang is decent here but it's not my cup of tea for other reasons but you do have to admit it has a very fast compiler and the way it's package system works makes for good incremental build support. .NET has always been very good in this regard. Rust is a bit slower on the compiler end but it's still very good, incremental support is good etc. All of these languages can also either produce code that works on all targets (JVM/.NET) or cross-compile natively (Go, Rust). This matters for packaging and deployment as half of devs use MacOS but deployment target is usually Linux and increasingly containers. Being able to construct Docker containers directly from artifacts without needing Dockerfiles is a huge win and all of the above languages support that via one tool or another (Bazel, Jib, etc). Literally any of these blow TS out of the water for DX, performance and tooling. Unless you are chained to TS for browser reasons or isomorphic code requirements it's just not worth it on the server.
- davidatbu 4y ago
  Thank you very very much for taking the time to write that out!
toastal 4y ago
Sounds like requirements Nix solves
- jpgvm 4y ago
  It helps but Nix just like Bazel can't handle Node.js in a cross-platform way. You still end up reverting to running `npm ci` in a Dockerfile and building the image in imperative style, giving up hermetic and reproducible builds in the process. The reason this is needed is node_modules contains platform specific native code. You can somewhat speed up cross-arch/OS builds by explicitly running the appropriate node-gyp incantation to rebuild the native components and skip entirely re-generating node_modules but that is still ultimately a bit gross. Compared to what you can achieve otherwise with Nix dockerTools.buildImage, Bazel docker_rules or Google's jib tool for JVM it's not even close to the same league in speed, reproducibility, convenience or maintenance overhead.

I'm super curious, what would you recommend for a tech stack that "[has] a good build system, good incremental compilation, proper test framework integration, etc"?

jpgvm 4y ago

Personally Kotlin/JVM. Gradle gets the job done, incremental (and concurrent) builds are fast, etc. You can also use just plain Java if you prefer if you really want a very fast compile time. Arguably Golang is decent here but it's not my cup of tea for other reasons but you do have to admit it has a very fast compiler and the way it's package system works makes for good incremental build support. .NET has always been very good in this regard. Rust is a bit slower on the compiler end but it's still very good, incremental support is good etc. All of these languages can also either produce code that works on all targets (JVM/.NET) or cross-compile natively (Go, Rust). This matters for packaging and deployment as half of devs use MacOS but deployment target is usually Linux and increasingly containers. Being able to construct Docker containers directly from artifacts without needing Dockerfiles is a huge win and all of the above languages support that via one tool or another (Bazel, Jib, etc). Literally any of these blow TS out of the water for DX, performance and tooling. Unless you are chained to TS for browser reasons or isomorphic code requirements it's just not worth it on the server.

davidatbu 4y ago
Thank you very very much for taking the time to write that out!

toastal 4y ago

Sounds like requirements Nix solves

jpgvm 4y ago
It helps but Nix just like Bazel can't handle Node.js in a cross-platform way. You still end up reverting to running `npm ci` in a Dockerfile and building the image in imperative style, giving up hermetic and reproducible builds in the process. The reason this is needed is node_modules contains platform specific native code. You can somewhat speed up cross-arch/OS builds by explicitly running the appropriate node-gyp incantation to rebuild the native components and skip entirely re-generating node_modules but that is still ultimately a bit gross. Compared to what you can achieve otherwise with Nix dockerTools.buildImage, Bazel docker_rules or Google's jib tool for JVM it's not even close to the same league in speed, reproducibility, convenience or maintenance overhead.