|
Java is not really a good benchmark for having lean build artifacts. It is a monster but it has other desirable qualities. In .Net land, the dotnet core runtime weighs in at about 30mb (what you'd need to run a production server), the sdk is about 140mb (for development machines and build servers)(once off setup). If you compile a project that depends on 5 other packages, it will only include those 5 packages and a package for your actual project (assuming 1 project per solution, else n packages for n projects per solution). It boils down to having build artifacts that are super lean, provided you are using the installed runtime on the target machine. You also have the option to package the framework along with your own package, then you don't have to install the runtime on the target machine, and these typically compile down to less than 100mb. It is probably less by now, but I don't use it. You also have the option to bake everything into a single file, much like how Rust does it. So yeah, I wish more people would play with .Net Core and it's tooling a bit, it's bloody great at moment. Java and it's tooling feels like a behemoth once you get used to the new dotnet tooling. Take it from somebody that builds build servers and custom tooling (cloning git repo's, building prod binanies, packing them if needed and then move them around (deployment, nuget server etc), all on linux, with C# code) - it is a dream. Calling the the dotnet build tools from my own console apps is a no brainer. My build tools can then be called by other processes in linux like any other cli app, or if I build them as asp.net projects, a simple middleware to intercept calls from nginx to trigger workflows remotely... easy peasy. All while the build tools can talk to Digital Ocean, Azure, Aws via their api's... |