Hi,
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 don’t know exactly why Go become successful but it is not because it’s a great language.
I'm looking for a new language to write server code in. I have been using Node for years but I want something that compiles to machine code and is statically typed.
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.
> [Nim] is too new
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 guess I mean "new" as in still not stable (pre-1.0 and still sees breaking changes). The fact it's been around so long and still hasn't matured is not reassuring at all.
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.
>to have libraries for... anything really
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:
I addressed that in my other comment. It's not just Elasticsearch. That was one example out of at least 20 I could give you. The fact that there isn't even a client for the world's most popular search database is indicative of the ecosystem as a whole. It's fine if you use OCaml for whatever, but it's not what I'm looking for. Though, I am keeping my eye on this for personal interest: https://reasonml.github.io
It indicates that you haven't written one? That's a rather strange attitude, for sure it doesn't have a wrapper for any rest api, what it has is all needed tools for write it, that's what really matters. The tool in repo above does not even use a library, only generated bindings. It's much easier to write a client to a rest api in OCaml than in Go due to derivers [1], atdgen [2] and the power of the language. Take a look at graphql bindings as an example [3] [4].
[1] https://github.com/ocaml-ppx/ppx_deriving
[2] https://github.com/mjambon/atd