Why Go? What is the most important feature that led to you becoming a Go programmer?

[Louki Sumirniy]

I just wanted to jot down and share my personal most important reason, and make this thread a short sample of the most important aspect of Go that drove you to learn and use it.

For me, it was this: I have been tinkering with programming on and off over the years since I was 8 years old, when a TRS-80 CoCo arrived in my house, and in all the time, and with many languages, from BASIC, Assembler, Amiga E (this was the first that really came close to this reason for me to learn go), C, Python and Vala, but in all of these instances, until Go, I was unable to do the most important thing, as I have very good visual thinking skills, but poor attention - to be able to complete even a relatively simple application. 

My usual problem always was that I would get bogged down in some detail, forget the bigger picture, and hit some big blocker in this detail and then basically turn off the computer and go ride my skateboard. I have now written several useful libraries, and massively extended and rewritten (now around 80% done) a bitcoin-based cryptocurrency wallet/node server suite.

Without Go's immediacy and simple, logical syntax and build system, I am lost. Go may be unforgiving in its syntax and semantics, but this is good because it's less decisions to make, and its really very possible with Go to start writing code immediately, and figuring out how to slice up the pieces and add new parts is far easier than in many other languages, start from a very simple, vague base and sketch out the details bit by bit. No other language has had this property that I have encountered before. I often remark that the language's name and the short-attention-span and high intelligence of many of its adopters have in common to some degree.

I think part of it has to do with how one must be explicit with many things, but at the same time, other places you can skip explications because of the implicit, also lets you focus on what's important and not so much distract you with superficial details.

Many other languages force you to really separate coding and architecting, Go lets you do it all on-the-fly.

[gp...@appliedgo.net]

For me, the first thing that stood out was the readability. Clear syntax without distractions or cryptic ornamentation. This becomes especially obvious when reading other people's code. Then the small and clear language spec. For me this document is the first stop for looking up language questions. Quick and easy. Try this with the 1300+ pages of C++ spec!

I also appreciate the intentional lack of inheritance, the stability of the language, the get-things-done mentality of the community (or large parts thereof), as opposed to discussing "clever" code constructs as the umpteenth "elegant" solution to the ever same problem, the libraries-not-frameworks attitude, and all the other awesome aspects of the language and the people around it.

Oh yes, and the garbage collector that clearly increases programmer productivity and reduces the number of possible bugs at the same time.

On Tuesday, February 26, 2019 at 1:07:58 PM UTC+1, Louki Sumirniy wrote:

I just wanted to jot down and share my personal most important reason, and make this thread a short sample of the most important aspect of Go that drove you to learn and use it.

For me, it was this: I have been tinkering with programming on and off over the years since I was 8 years old, when a TRS-80 CoCo arrived in my house, and in all the time, and with many languages, from BASIC, Assembler, Amiga E (this was the first that rFor eally came close to this reason for me to learn go), C, Python and Vala, but in all of these instances, until Go, I was unable to do the most important thing, as I have very good visual thinking skills, but poor attention - to be able to complete even a relatively simple application. 

[minf...@arcor.de]

Am Dienstag, 26. Februar 2019 13:07:58 UTC+1 schrieb Louki Sumirniy:

Many other languages force you to really separate coding and architecting, Go lets you do it all on-the-fly.

This is fine as long as you work your design around the capabilites of Golang. If not...

Sounds trivial but it is not. Different data models, the famous lacking generics, etc. can really make Golang not to be the right tool for the job.

Otherwise I think you are right. Golang hits a sweet spot concerning the limited average human brain capacity - and programmers are only humans after all.

[Chris Hopkins]

What brought me to it was the concurrency. I spent my entire career frustrated by not only how concurrency wasn't more of a thing in popular languages, but also how so many people didn't seem to think it was a problem. I pounced on Go when I heard about it. (Although I am currently fluttering my eyelashes at Halide...)

What made me stay is the clarity and simplicity. So many languages seem to be an exercise in showing off how clever you are, by using x clever pattern. Go doesn't seem to suffer this.

If I could just use it for the embedded stuff i do...

Chris

[Louki Sumirniy]

These two points really nail it:

On Wednesday, 27 February 2019 11:02:23 UTC+1, Chris Hopkins wrote:

What made me stay is the clarity and simplicity. So many languages seem to be an exercise in showing off how clever you are, by using x clever pattern. Go doesn't seem to suffer this.

 C++ code you find in cryptocurrency server particularly demonstrate this problem. Ok, so partly, I just don't understand the generic syntax, the template, and I find its syntax absolutely repulsive (and completely unintuitive). But it's not just that, the code is cryptic and incredibly disorganised, and I guess this is where the novel build system of Go really shows its superiority - CPP syntax is also very cryptic. More than one include root... We have modules now, and right off the bat it eliminates so much of the manual handling that makes code like this so irritating to adopt and work with.

 

If I could just use it for the embedded stuff i do...

Go would require a separate runtime system for embedded, due to the usually tiny resources. The MIT-PDOS Biscuit research OS is an example of a modified runtime designed for launching off bare metal, this might be a direction that could do with being further developed. Embedded software tends to need very fussy, hand-written and careful handling of resources. Mainly I think for these cases one simply has to expose more of GC's controls and possibly write different resource managers (gc modes, perhasp) better suited to such environments.

[Dan Kortschak]

For the embedded, https://tinygo.org/, but limited back ends.