Ask HN: Which tech stack is the most fun?

This is great! I write a lot of one-off utilities that run on my main desktop as web applications backed by sqlite so you're really speaking my language here!

I enjoyed the little bit of exposure that I had to Tcl/Tk through EXPECT, I used to write a lot of embedded test scaffolding using it back in the 00s. I've also been interested in checking out Little Language [0].

Wapp looks like a great place to start with Tcl.

[0]: https://www.little-lang.org/

The most fun programming I ever had was Turbo Pascal in the days of MS-DOS, it was possible to do pretty much anything, and it compiled almost instantly.

When Delphi came along, it was easy to use, but the layers of code made knowing what was going on effectively impossible.

Now we're in the age of trying to force a GUI to appear on the other end of the tech stack that includes hardware not owned by the people who should be their owners, but rather companies driven by profit motives. Connected by a series of privately driven networks, snooped upon by hundreds of competing national agencies and companies from everywhere, and it all sits on top of something that doesn't have capability based security at its core.

I'm used to a GUI, so Delphi would be it, except it's now insanely expensive, and I can't afford it. Lazarus is an open source alternative that works well enough... so that's my choice for fun these days.

As for working a job, which I'll have to do, soon enough... I expect that I'll be stuck using some form of case sensitive, macro encrusted C derivative, or perhaps something "memory safe" and unintuitive like Rust, or "functional" that forbids useful things like goto and global variables like Haskell.

The tech stack that I love the most, however.. is the tech stack we all use, that starts with raw inputs pulled out of the ground, and refined in many ways, until we get laptops and smartphones. It's an amazing technology stack, capable of producing wondrous things that even Absolute Monarchs of the past couldn't have dreamed of wishing for, in quantity and quality that even working class folks can afford.

We live in amazing times, thanks to our shared tech stack.

> 3. Enough of a type system to catch typos, but not enough to bog you down in mental gymnastics on how to solve every problem perfectly. And definitely not enough to slow down builds and your iteration/test cycle.

I think the second part (not enough to slow down builds and your iteration/test cycle) is a false dichotomy between "languages that have 'advanced' type systems" and "language that compiles fast". OCaml has a more "advanced" type system than Go, and still compiles really fast. My understanding is that both have influence from Pascal and its descendants, and Pascal made some tradeoffs to ensure fast compile times. For example, OCaml has no forward definitions. I used the word "advanced" here but I'm not sure if it's the correct one, as in I don't want to imply that one is better than the other. Maybe "fuller" could work too, but it sounds very weird to me. Complete maybe?

To continue on why I think OCaml is a good choice, replying to your points:

1. Sensible defaults are definitely missing in some parts, though with frameworks like Dream (https://aantron.github.io/dream/) this is less of a problem. There are small things missing in Go, like CSRF prevention. Where you have a point is that you don't have a big transition from "writing Go code" to "using a framework", which is a problem that can lead to analysis paralysis in other languages. With Go, you can just start with Go.

2. No ecosystem churn: This is a bit of a hard one. I feel like "churn" in OCaml is closer to the one in Go, adding things that are actually needed and after having a good understanding of the problem. For example, OCaml is adding multicore, and doing it in a backwards-compatible way. I feel like the approach is a lot like generics in Go: existing code will continue to work, code that went around this feature before will probably need to be rewritten, but that's for the better.

4. This is the big one. Concurrency in Go is a pleasure. You can write direct-style code, maybe put a channel or a waitgroup or something and everything just works. This is a point where OCaml is not as good as Go. Concurrency works with colored functions/monads (they're the same thing), like in many other languages, or just plain old threads. Multicore may allow people to build a preemptive multitasking runtime, just like in Go, but it's not there yet.

For the other stuff:

Dev tooling is not as "intergrated" as with Go, probably not as good, but the language server, package manager and build tool are all good. The debugger is a pleasure to use, and having a shell/toplevel/REPL is great.

Performance is great. Not as good as Go (though it does beat it in a few benchmarks on the multicore branch for HTTP servers), but still better than almost all of scripting languages, especially the popular ones.

As for OSes, it's mostly good on Linux. The windows support is so-so, the mac support too.

Lastly, for the learning experience, it's hard to say. I find it harder to learn something in OCaml, in that it forces me to understand what I'm doing more than with other languages. This can be frustrating at times, but also deeply rewarding.

I have a lot of fun with shell scripting, even if it is a terrible programming environment in so many ways. It is fun to be able to quickly hack together existing tools in such a messy, but natural, way.

Thanks! What do you use for editor tooling, REPL setups, testing, etc.? Also describe your workflow if you can. I know this might mean a longer reply but I'd appreciate it ;)