I don't know why anyone would write CLI tools in rust or zig. I/O is going to be your bottleneck way more often than GC, in fact I don't really get the GC hate outside of game dev, databases and other memory intensive applications. Why not use Go, Python, etc? People try to make a false dichotomy between memory safety vs. non-memory safety when really it's GC vs. no GC --- memory safety without it is going to be hard either way. More time should be spent on justifying to yourself why you shouldn't be using a GC, and less on which kind of GC-less language you use.

(If you go no GC "because it's fun" then there's no need for the post in the first place --- just use what's fun!)

▲

shmolyneaux 3 days ago | parent | next [-]

Instant startup times are really nice. You definitely notice the difference. It also means that you can be a bit lazier when creating wrappers around those tools (running 1000's of times isn't a problem when the startup is 1ms, but would be a problem with 40ms of startup time).

Distribution can also be a lot easier if you don't need to care about the user having a specific version of Python or specific packages available.

	▲	rixed 3 days ago \| parent \| next [-]
		What makes python very slow start up has little to do with the GC though. Actually, a GC program for a short-lived program such as most CLI tools can be the fastest option since you could disable the GC and let the OS dealloc all memory at exit.
	▲	nmilo 3 days ago \| parent \| prev [-]
		Fair. Python was probably a bad example. I think we need more languages like Go because even with its downsides, for projects that don’t need explicit memory control I’m picking it over rust and zig every time

▲

seabrookmx 3 days ago | parent | prev | next [-]

Go is a great option for CLI tools (even though I'm not a fan of the language itself). Python CLI apps can be a big pain to distribute if you have a bunch of dependencies. I think this is also why Rust and Zig are also attractive.. like with Go it's easy to create a statically compiled binary you can just cp into /usr/local/bin.

▲

efnx 3 days ago | parent | prev | next [-]

I will always reach for a language that has sum types, pattern matching and async support. Catching errors at compile time is a boon too. It doesn’t have to be Rust, but after those requirements- why not?

▲

astrange 3 days ago | parent | prev | next [-]

> in fact I don't really get the GC hate outside of game dev

Most mobile games are implemented in a system with GC (Unity with il2cpp), and it's not even a /good/ GC, it's Boehm.

	▲	pjmlp 2 days ago \| parent [-]
		And if not, they are probably written in a mix of Koltin/Java/NDK, or Objective-C/Swift with ARC (chapter 5, https://gchandbook.org/contents.html).

▲

pjmlp 2 days ago | parent | prev | next [-]

It is basically cargo cult, whole graphical workstations have been built with GC based languages 50 years ago.

- Interlisp => https://interlisp.org/

- Cedar => https://www.youtube.com/watch?v=z_dt7NG38V4

Imagine what we could have today with hardware that is mostly busy running Electron crap and CLI tools from the 1970s.

▲

K0nserv 3 days ago | parent | prev [-]

Not Python because getting Python to run on different machines is an absolute pain.

Not Go because of its anaemic type system.