my humble opinion: how much would "Immutable Types" add to the language? How much complexity would it add? Things can already be made immutable from outside by hiding them in private variables/struct elements.

The question is: why did Go became successful without having "Immutable Types"? (or "Reference Types", ADTs too please?) Maybe those things are just frills, "nice to have" features.

Example like "type ImmutableMapAndKey const map[const * const Object] const * const Object" looks like really ugly Go to me... this is starting to look like C++...

https://www.youtube.com/watch?v=cQ7STILAS0M (why Golang is Sucessful by Creator of Golang Rob-pike)

P.S.: I wouldn't mind having "Immutable Types", "Reference Types", ADTs, etc. in Go. But not if it means abandoning simplicity of the language.

I've been looking at Go and I like that it is simple, has opinionated, official tooling, compiles very quickly for multiple platforms, is popular enough to have a decent library ecosystem, and I really like the idea of goroutines.

What language would you suggest would be better? Nim sounds cool but it's too new. It's not stable and has a small ecosystem.

It's actually a year older than Go (2008 rather than 2009).

If you don't want to use Nim because it's not stable enough or has too small an ecosystem (I disagree), you could try out Scala Native or Kotlin Native. A large portion of their ecosystem successfully compile to native code (although you may have issues with Scala Native compile times).

You can also check out OCaml.

I have checked out OCaml but it's not mainstream enough to have libraries for... anything really. Here's the first thing I checked just now: https://www.elastic.co/guide/en/elasticsearch/client/communi...

The OCaml client was abandoned 5 years ago. Nim doesn't even appear on the page!

This page says Kotlin Native is still in preview: https://kotlinlang.org/docs/reference/native-overview.html

Also, I am not seeing a reason why Go is not a good choice.

I think you may have unnecessarily restricted yourself by wanting a language that produces native binaries and is GC'd. There simply _aren't_ that many mature and mainstream languages that compile to native binaries with a GC. I'd personally much prefer a more expressive language with a less robust ecosystem (and a virtual machine), but if an Elastic lib is a hard requirement for you, then I can't argue with your choice of Go.

Or use Haskell. Native binaries, opinionated, decent library ecosystem ;).

And it's not just Elasticsearch. That's just one example. I would come up against many other requirements. Here's just one more: https://nats.io/download

Edit: And you're right, Haskell is something I should probably look into more. I haven't thought about it too much since I already do a lot of functional programming in JavaScript and I don't hear too much about Haskell being great for creating API servers.

One of my other concerns is that the project I'm planning will be a long-haul, and will have several other developers join in future. I want to have a decent market to choose from. And, being in Australia, it's small enough as it is. I'll shy away from remote workers since it's relating to sensitive healthcare data.

Like, no, compiling to machine code is only one class of compilation. All the VM-targetting languages have far more robust ecosystems than Go, with good abstractions, performance and tooling to boot. _Any_ language that targets the CLR or JVM should suffice.

That's a very bold thing to say when you don't even know what I'm planning to do with it. Like, NodeJS will "suffice". Why don't I just use that since I'm very experienced with it? Reasons. Why don't I use Java? Reasons.

I feel like this is going nowhere. I'll probably choose Go. Stranger on internet thinks I'm wrong. This is the story whenever the topic of programming languages comes up. Everyone thinks their preference is the one true preference.

I'm not suggesting you use my personal favourite language, merely use anything but Go.

I respect your courage in just coming out and saying that.

You've given yourself a very tough set of constraints (has to compile to binaries, has to have a GC, can't be in preview, can't be under v1.0, can't have a slightly unstable API, has to have "good" libs for an arbitrary selection of tech, can't target a VM) that makes Go the only viable option

Half of that is "I want something stable", which is almost universally appreciated among programmers. The way you've said that makes it sound like I chose Go then decided "I want whatever he's having". No. I have a list of many "nice-to-haves" and Go satisfies more of them than any other language/ecosystem. It's as simple as that. If I was going to settle for 2nd place, I'd probably just use NodeJS. I am extremely productive in NodeJS, and I'm still not 100% sure I won't choose it for this next project.

I'm not suggesting you use my personal favourite language, merely use anything but Go.

Although I find that a strange position to take, I appreciate your honesty.

It has thousands of libraries, check opam out. If something is absent, why won't you write your own library anyway? Elasticsearch is really not that complex, here is the example:

https://github.com/cyborgize/es-cli

I like it's stripped-down feature set, and opinionated concurrency (although it's occasionally clunky).

It's not perfect, and could have a lot more support for concurrency, but it's very workable and a joy to program in.

If you want language optimized for productivity with a lot of high-level features, use Python. If you want maximum performance and low-level control, use C++ (or C, or Rust). If you need relatively high performance but can tolerate it not being 100% in exchange for nice things like GC, use Java. Where does Go fit?

You need a good reason to get rid of the incumbent, it's not just arbitrary.

And to suggest Go doesn't offer anything different to Java is just silly.

How could the absence of sum types possibly be a good thing?

Yes, you can hide state behind interfaces and opaque types, but you don't take into account, that the implementations of those types and interfaces need to be reliable as well. An interface with read-only types, for example, can declare its methods immutable enforcing an immutable receiver type on the implementing functions which makes sure that it's always correctly implemented and doesn't mutate its object for sure! A field can be declared immutable to make sure it remains immutable after the object is initialized, and so on. Immutable types allow you to better express your intentions when implementing something because in a month from now you'll be a different person too and you won't remember certain implementation details like "why you shouldn't mutate this inner slice in this struct" etc.

The whole concept is actually composed of 5 fundamental rules that are relatively easy to pick up. It also shouldn't be compared to C++ or even C style const qualification, because it's easier and safer.

https://en.wikipedia.org/wiki/Cliché#Thought-terminating_cli...