
Go 1/2 Proposal: Immutable Types - romshark
Hey guys, I just published the Go 1.x &#x2F; Go 2.x proposal to &quot;Immutable Types&quot; that I&#x27;ve been working on for the past month and it&#x27;s now official:<p>https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;27975<p>Please be sure to check it out and feel free to join the conversation! Even if this feature is never introduced to the language specification - reading the design document will make you a better Go developer, that I guarantee!<p>original design document: https:&#x2F;&#x2F;github.com&#x2F;romshark&#x2F;Go-1-2-Proposal---Immutability
======
x0re4x
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](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.

~~~
noncoml
I don’t know exactly why Go become successful but it is not because it’s a
great language.

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

~~~
mbo
> [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.

~~~
jazoom
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...](https://www.elastic.co/guide/en/elasticsearch/client/community/current/index.html#ocaml)

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](https://kotlinlang.org/docs/reference/native-overview.html)

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

~~~
mbo
> 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 ;).

~~~
jazoom
I am already very familiar with 2 interpreted languages, but not very familiar
with any compiled languages. I'm doing the exact opposite of restricting
myself.

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

~~~
mbo
> I am already very familiar with 2 interpreted languages, but not very
> familiar with any compiled languages. I'm doing the exact opposite of
> restricting myself.

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.

~~~
jazoom
>_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.

~~~
mbo
Yeah look, I do think you're wrong. 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 - I'm questioning whether those are legitimate.

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

~~~
jazoom
_Yeah look, I do think you 're wrong._

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.

