[mikedelago]

It's also really, really fun to use a language that's completely different than what you're used to.

I've learned Elixir, Scala, F#, and Common Lisp on the side in the past year or so. I like Elixir and CL to the point where they're typically my go-to for personal projects. I liked Scala and F# a lot but I don't reach for them so often; it'd be nice to work with them.

The worst part about learning (and liking!) new languages is that at work, we're pretty firmly in Go. IMO, while Go is nice from a minimalism and resource utilization standpoint, it's simply not fun to write after using much more expressive languages.

[phillipcarter]

> IMO, while Go is nice from a minimalism and resource utilization standpoint, it's simply not fun to write after using much more expressive languages.

It's definitely a blessing and a curse. What I think I'd say about Go is that it's a simple "day 1" language and a complicated "day 2" language. Speaking strictly from an expressivity and language semantics standpoint, as its runtime and standard toolset are simply great, it's just filled with so many head scratchers when you dig into what's going on and why.

Like the go modules import compatibility rules forcing you to create new vX versions of modules. It's not that it's unsound, it's just unlike everything else out there, and so you can't take your knowledge from other packages managers and apply them to Go. Maybe that expands the mind a bit, but in my experience it just confuses teams and forces them to sometimes go back and revert a major version bump because it's easier to just do that.

[bern4444]

> What I think I'd say about Go is that it's a simple "day 1" language and a complicated "day 2" language.

This resonates. I very much dislike Go's error handling model. Its overly simple and leads to exorbitant

    if err != nil 

checks all over the place. It clutters the actual business code and remains a clunky, leaky abstraction.

I think Go is a language designed for engineers who don't care to learn about more elegant solutions that come with more intricate semantics (Option, Either, Try etc).

It's get the job done inspiration is sloppy and poorly conceived.

[mikedelago]

The big thing too, with the `if err != nil` pattern is that it's _good_ Go practice to do that, but it doesn't feel good to constantly be spamming a 3 line error check on every single statement.

I really don't like hopping into a codebase and seeing a 27-line function (uncommented, of course) with 21 of the lines being `if err != nil` checks

[bern4444]

Plus go code seems to embrace as short of a name for variables as possible.

Have a parameter for an array of users? Call it ‘u’. Want to have a variable for a config object? Obviously call it ‘c’.

‘Idiomatic’ go code is bad code.

[wefarrell]

Elixir was the most pleasant experience I’ve had learning a new language. I really enjoy the ergonomics of pattern matching and the pipe operator. Really wish I had an opportunity to use it professionally.

[mikedelago]

I agree, so many of the idioms (tuple returns into pattern matching, comfortable lambdas, DI through behaviours) all just felt like a breath of fresh air.

It feels like the language was designed to be as good as any other language you've learned.