Hacker News Reader

Comment by jimmygrapes | Hacker News Reader

Genuine question here: would it be better for a backend server or cli to be written in a language that allows for compilation to a single executable, or run through an interpreter (python, deno/node/ts-node etc)? I'm not familiar with Go or Zig in that regard.

View on HN

That depends on what you mean by "better". What's your goal here?

A single executable would be easier to deploy/version/sign. You could in theory also make a bundle with typescript/javascript files as well. It would be no different from deploying a WAR file on a server running JAVA.

Do what is the easiest for you and your team.

Better than what, and in what way?

Compiling to a single executable like Go and Rust and Haskell do, has a bunch of benefits for a server. Notably, it used to be the case (before the container revolution) that if you used a scripting language like Python, say, you had to carefully pip install all your dependencies identically between your prod and staging and test environments and your local dev env. Scripting languages have this nasty habit of preferring to not break, they will start a script without having all of its dependencies in the hopes that by the time the dependency is actually used, it will have been installed dynamically. This is also why wizened programmers from those cultures write so many damn tests, because if there is a dependency that does not get exercised at test time then you might have a prod outage on the weekend when some user figures out how to exercise it, etc.

In other words you can view the rise of Docker as saying, “give me your scripts and I will give you this magical unicorn called a container image, which can be used to run your script like a single executable.” People did not use Docker for its security features (the people who cared about that used VMs before Docker and put Docker into a VM after), but for its operational feature. If anyone had understood this before the rise of Docker, I think they would have architected Docker differently: multiprocess containers and weird networking stacks could have been done away with, you would probably not throw all of the OS into the binary because that's overkill (just Terraform-like “providers” or so?) ...also Docker needs to run as root to establish its tentacular spectacular: if you had viewed the goal as packaging the scripting language as a virtual binary you probably wouldn't need this stuff.

If you are running a large enough company then you need something like kubernetes because you have thousands of developers all needing to deploy on to the same prod hardware clusters. Cloud computing generally tries to lump you into this bucket too. In those cases there is no difference.

But if you are running a small dev shop of less than 20 devs at a larger 100-300 person company, now prod is whatever Casey your sysadmin says it is, and Docker is forbidden by some policy that you can't run as root or so, so now it's easiest to just compile static binaries and then build a lightweight gitops thing out of that, put an NginX server in front (except Casey gets mad and makes you use Apache) and some FastCGI and with a bit of luck you can get it so that if the build or tests fail, the system sends you an email via nagios but keeps humming along with the old build. It's a few weeks of work and you'll complain to every dev you onboard “I'm sorry this is all held together by duct tape” but it'll chug along fine until that company becomes 5,000 strong and you have 500 developers and can afford to containerize or shift to cloud for new applications and "do it right".

Reply on news.ycombinator.com