[q3k]

Go. Lower your pitchforks and hear me out:

1. Sensible defaults, can go very with just the stdlib: no choice paralysis between frameworks, mental overhead of setting up a project or ecosystem fragments to pick from. Just start with a main.go with net/http, add things along as you need them.

2. No ecosystem churn, whatever you write now will be idiomatic Go and build without issues for years to come.

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.

4. Concurrency model that lets you spin up things in the background and keep processing in memory before you go into databases, worker queues, and whatnot. If you want to cache something slow, just put it in a map behind an RWMutex, and your single-process Go binary will scale way past any prototype stage.

You get things done, you don't spend your life obsessing over 'elegance', and whatever you build is probably high quality enough that you can make use of it for years to come.

[ferdowsi]

The developer experience of Go is really one of its killer features. I was reminded of this when I was starting fresh on a new laptop; I just had to run one command in VScode to set up the entire Go tooling stack, which just installed and worked quickly. The standard tooling is so strong that there's no decision paralysis or maintenance burden around linting, formatting, testing, and so on.

[biztos]

I would add:

5. Good documentation (and good culture of documentation)

Whenever I have to go look up a Go package[0] and figure out how to use it, I am impressed with how good most of the documentation is. Yes, you have to be familiar with the golang conventions, but it seems like accurately documenting libraries is just a thing people take seriously in the ecosystem, and in many others it stops at the good intentions.

Also I really like how explicit it all is. I usually learn something more than just an API when I dig into a Go package.

So, if you like to nerd out on that kind of thing, Go is one of the best places to do it.

[0]: I hate that they replaced godoc.org with this, but: https://pkg.go.dev

[chakkepolja]

Coming from well documented parts of python ecosystem and Go, I was surprised that spring being such popular framework had no approachable documentation. Maybe it's intuitive for people with 5-10 years experience in enterprise java but not for me.

[KronisLV]

Hmm, why would anyone even bother pulling out said pitchforks?

In my eyes, Go is a pretty reasonable choice: the language is decent, simple enough to be learnt in a relatively short amount of time, is reasonably readable and doesn't force you to work in a really low level of abstraction.

The runtime is also pretty good and the static executables that can be generated are a major boon in my eyes! None of the pain of Python's packaging challenges and performance that's generally pretty good when compared to many of the alternatives.

Sure, it's not as established like Java or .NET are, especially in the enterprise space, but nonetheless it is very capable for everything from utilities and small tools to web apps.

Edit:

> As Rails has waned in popularity, has any other tech stack taken that crown?

Actually, after re-reading the original post, i'm not sure what the question is, exactly. In my eyes, the languages that are fun are whatever allows me to solve problems and see results (which is where a lot of satisfaction lies for me) relatively quickly: so anything from aforementioned Ruby, PHP (with select frameworks), Java (with select frameworks), .NET (Core or newer), Python, Node and so on are still fun in my eyes.

Was OP perhaps looking for languages that feel more "fresh" and are more hyped, while still having vibrant communities around them?

[chickenWing]

> Was OP perhaps looking for languages that feel more "fresh" and are more hyped, while still having vibrant communities around them?

For me, it's more about the day-to-day experience, hence the reference to React Native. I'm dismayed by its popularity, because it feels like such a step backwards - the ugly language (Typescript is slightly better than JS but still not great), the massive amounts of external dependencies required for even simple projects, the bugs, the lack of a decent debugger, and so on. All those things take away from the day-to-day enjoyment of programming.

[q3k]

> Hmm, why would anyone even bother pulling out said pitchforks?

It repeatedly get raked over the coals here for being dumb, inelegant, stuck in the 80's and an overall Bad Language Which Cannot Be Taken Seriously. :)

[KronisLV]

I'm sorry that you had to experience that!

The biggest criticisms that i've heard of Go is that the error handling ends up with a lot of boilerplate due to the syntax, and previously people also complained about the lack of generics (which is now being added and refined).

If anything, i would expect people to be more negative towards PHP because, while the language and its ecosystem have both come a long way towards being pleasant to work in and overall capable, i'm sure that plenty out there have ran into horrible WordPress sites/plugins or old and neglected codebases with bespoke frameworks that have no documentation and that are just horrible to work with.

In contrast, to me Go actually feels like what Pascal should have been.

[q3k]

> I'm sorry that you had to experience that!

It's fine, I'm not religiously affiliated with any technology to be offended. I've worked with everything from Haskell to C, from Rust to Go, from Lua to Lisps, from BlueSpec to Prolog - and that's been a good lesson that there's more to a language than its' syntax and semantics as analyzed in a vacuum on an internet forum. And that you should use different tools for different jobs - and usually the simplest tool which works is the best choice.

Go is very often that simple tool which works for most simple things.

[GiorgioG]

> Go is very often that simple tool which works for most simple things.

If only folks applied that kind of thinking to things like architecture and devops.

[Scarbutt]

4. Concurrency model that lets you spin up things in the background and keep processing in memory before you go into databases, worker queues, and whatnot. If you want to cache something slow, just put it in a map behind an RWMutex, and your single-process Go binary will scale way past any prototype stage.

This the big one IMO when comparing to nodejs but a showstopper for some apps in ditching nodejs for Go is needing a nodejs process for SSR.

[c7DJTLrn]

1a. You don't have to go looking for libraries or frameworks with bizarre names like boingo or zapper or something to start serving HTTP traffic

[oftenwrong]

I agree with all of the good things said about golang in this thread, but I could not consider it "fun". It is boring in a good way.

[gameswithgo]

As a big fan of complex and interesting languages, the above is all very true. Go is nice to work with, despite not being interesting.

[tijs]

Top notch developer experience; it just works. But when i was building a semi large web app with it a few years back I got quite bored with the amount of cookie cutter code I needed to write. Perhaps the amount of rails type frameworks has progressed enough for that to have become a non issue though.

[scruple]

5. It ships with wide array developer tooling out of the box. You will not need to install an assortment of third-party programs to manage dependencies, refactor your code, view the docs, run tests, format, lint, run static analysis, check for race conditions, profile and trace, benchmark, etc...

[Zababa]

> 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.