Especially regarding Bash.
Used to be in a few companies where most developers just couldn’t/wouldn’t write in more than one language and it was always a pain to maintain different runtimes, languages, packages and internal dependencies of things that could have been a 20-line bash script, and had to be maintained and updated from time to time.
I understand people have their own limitations and reasons, but having to constantly deal with “wrong tool for the job” for the thousandth time gets frustrating.
Especially in cases where four different languages were used across the company because different people had different preferences. Worst case was Python/Ruby/C#/Javascript.
I get that Bash is not perfect, but I enjoy the simplicity and directness, and dislike the multitude of problems caused by not using it have shown to me it’s a better tradeoff.
And fewer dependencies, and fewer vulnerabilities (if any at all, depending on your few dependencies).
Go is "only" a pain when you want to use your own copy of packages (because `replace` directives are always ignored everywhere except on the "root" package), and whenever you want to work with private Git repositories outside of the forges that have hardcoded config in the Go code (like GitHub) (because Go assumes there's an HTTPS server, and the only way to force it to use only SSH is with ugly workarounds AFAIK).
But despite this I still prefer it for personal projects because I can come back after not touching it for years, and the most I need to do is maybe update `golang.org/x/net` or something like that.
Shell for the scripts. I haven't tried to work through much DSL as I really am not a fan of DSLs. Maybe I'll give haskell a shot again to see if it sticks.
Despite we have different tastes in language and are in completely different ecosystems, TypeScript is still the lingua franca lol.
In theory most websites could be done statically with rendered HTML and CSS and maybe a little bit JS, but not mandatory, and having noscript fallback flows. MPAs are fine for most things and having noscript fallback flows can also be done kind of systematically, and in many cases isn't that difficult. Just that these days not many people bother or care.
Dabbled with Rust some years ago, I think it is an excellent choice for sudo-rs and such but for GUI and web apps I (perhaps too stupid) end up with arcmutex soup.
Curious if you've tried to use agents to read / write Haskell and how the experience has been?
If trying to avoid the cloud, like OP, which hosting option is suitable for Clojure, what do you use? I believe Clojure (JVM) has higher RAM requirements?
And GO has pocketbase.io which looks quite interesting. Do know whether something similar exists for Clojure, or maybe it's straightforward enough to compose your own by using various Clojure libs?
In the realtime/high assurance systems world, where garbage collection can be a huge source of non-determinism and overhead; we don’t have great options.
Zig is really the only language (idk about Odin?) trying to take the same approach that C did in giving you absolute control over a minimally abstracted CPU model. Us folks who need/want maximum control/performance should be allowed to have nice things too.
I can Highly recommend it, specially because you have Haskell experience (you get all the usual suspects, like ADTs, exhaustive pattern matching etc) in Lisette code. It has a fast compiler too, and produces human readable Go code. It also comes with great tooling out of the box (formatter/lsp etc).
We’ve a 1: 1 copy of the app; on JVM, it's using 2GB RAM using Spring Boot, and on Go, it runs on 512MB RAM and is blazingly fast.
ofc, it's possible to tune java app but why bother? when we get same low resource usage and better performance in Go from get go while still writing naive and dumb code?
Deployment is super simple in Go, upload a single cross compiled binary it's done. Very simple and easy.
Rust needs a lot more effort to write correct code than Go in my experience. We get the same performance out of Go, with much less effort. At some point, it's just cheaper to start one extra instance than perform some low-level optimisation; modern hardware is fast enough that Rust-level optimisation is rarely needed for what we do.
well there's your answer, isn't it?
In such context, I think Go might be a better or at least, more realistic, compromise in most cases.
If I use a JVM language, running my test suite takes 10 to 30 seconds. With Rust it spends 3 seconds compiling and half a second to run 250 tests.
The irritating parts of Rust are more related with bloated libraries like serde that insist on generating code which massively slows down compilation for not much benefit.
Sounds like a bad build tool.