Discussing Go idiosyncrasies (split thread)

Tags: #<Tag:0x00007f1148492130>


Sounds like a bug in the ecosystem there… ^.^;

In C++ I get reliable reproduceable builds as every dependency is marked to a very specific version and/or git commit (or other things), why would go at ‘least’ not do that, if not better systems like Rust’s cargo or Elixir’s Hex… >.>

Not about their speed at all, nor have I ever (they do have some bad corner cases of course, but most languages do), but rather about their the maintainability of the code written in them.

Not motivated to, that specific benchmark service is old and well known as quite broken on MANY languages. ^.^

You ignored the rest of that part. :wink:

Go’s syntax is quite the opposite of concise.

Here, let’s compare passing up errors between a few languages:

f, err := os.Open("filename.ext")
if err != nil {
    return nil, d
d, err := doSomething(f)
return d, err


let f = File::open("filename.ext")?;
return doSomething(f);
// Oh lookie, no close needed, the ownership system closes this properly...


ifstream f("filename.ext");
return doSomething(f);
// Also lookie, no close needed, RAII closes this properly...

In the average go code I’ve read more than 50% of the code (usually a lot more) is just error handling. The above Rust and C++ code is handling the errors as well (Rusts returns a result objects, C++'s throws an exception, though you can do the same in C++ as in Rust too). And to boot you still have to remember to manually close files in Go (a modern language that doesn’t handle resources automatically, that is still so horrible…).

‘Some’, and this is just falling back to C style void* pointers, which loses all compile time guarantees, and you really hope you remember to perform all the runtime checks that you can (yay slower and random runtime faults). This is absolutely abysmal for a modern language.

Not forget at all, a GC is definitely one of the major failures of Go. Why do they only have a system to manage one resource type (memory) instead of one that can handle all resource types (including memory, files, etc…)?

Not even remotely. Go specifically sets itself up to replace C/C++ in many areas, and it may do so for C (no generic resource management), but not C++ at all, and these tests were very recent (it was for a benchmark I was running for someone else a few weeks ago, latest release of Go).

You also didn’t answer a single thing I asked. ^.^
Like just, how would you implement something like ‘reduce’ that operates like what I specified before? Just start with that as it’s one of the most simple tests of any language. :slight_smile:


I’m with you here, and they seem to work at the problem. At least they have an official dependency management tool in the nursery which currently manages the vendor folder.

I do hope that there will be a way to specify dependencies with it and the will be handled recursively with that tool via go get, also I heard rumors (or prayers?) that it shall become such a tool. But currently there are far too many tools that are just pulling into vendor in quite different ways.

Also there is currently not even a uniform way to specify a packages own version.


This is what I keep hearing, you can grab from git, but it always grabs HEAD, which is very…confusing to me why they would possibly make that choice (if anything I’d expect HEAD to be disallowed but everything else allowed!).


The 8 space thing was a joke people


Channels orchestrate; mutexes serialize.


So tell me how you would make a, oh, the dead-simple reduce function

… though the regularity with which interface{} crops up kind of undermines the “Go is statically typed” argument. Its seem to be statically typed by default until it needs to be overridden which seems to happen with disturbing regularity. The problem with escape hatches like that being in common use is that it encourages their use even when they are strictly not necessary.

However this is acknowledged:

interface{} says nothing.


Going back to the topic instead of a language war. In my newbie opinion is that Go is simple in the concept of newcomers, they don’t need to worry about the “elegance” of Haskell Types, they don’t know/care about CSP vs Actor, they just want to do some code and make a program work. Go is easier to understand and “command” what to do, get your binary and run, it’s raw enough for that but higher than C. Go is popular for almost the same reasons as JavaScript, you can do a lot with it, knowing little about the science.

Also you can say that is popular because of the amount of packages it has, because they are small, just like JavaScript (ok here we have a lot of duplicates) hence it have a lot of repositories in GitHub for example instead of one big repository.

If the question is about how could Elixir benefit from the popularity of Go, I would say, keep concise, and easy to get started, once a newbie is hooked it will go through the bad parts.


To be perfectly honest that question never occurred to me because in my mind there is no benefit to Elixir. (Also “programmers” these days should care what all the hubbub about concurrency is - we’re not living in the 1970s anymore). Also the intent of the topic was never to incite a language war - X is better than Go - style. It was more to explore the reasons why primarily individuals and to a lesser degree organizations may gravitate towards it.

From a programmer’s perspective it looks to me like C all over again - it’s good enough to get some stuff done but it does very little to move you along your skill path. I always had the impression that a lot of the more advanced C developments were driven by people with significant experience in other programming languages. So knowing and practicing only C may not be healthy for any programmer.

JavaScript with all its warts, total lack of anything resembling a standard library at least has some Scheme-y bits that can encourage you to try something different.

Go can come across a being associated with a somewhat inward-looking culture - it seems you’re never encouraged to stretch yourself - if anything it can come across as somewhat conformist.


Yes they lack of a lot of stuff, and that’s what makes “appealing” for a newcomer because they aren’t looking for that, and when I say a newcomer is in general programming, not to the language. The language it self does not scale with the application, instead like the k8s article they had to invent stuff to get the code going . The thing is that when you are first learning about programming you just want to publish your code, if you get for example started with Java, you spend a lot more time figuring a bunch of stuff to just how to print on screen and that make people sad and they move away. Again what I’m talking is not about a experienced programmer moving to a new language, but a completely new person on the field.


This is one of their flaws as community. They have that jargon of “you don’t need a library, use the stdlib” for every. single. thing.


So you mean… its unfamiliar to you? :smiley:

Type assertions with empty interfaces loose the statically typing, go generate and casual interfaces keep them.

Maybe because this becomes complect? :wink:

Link? I see Rust as C++'s successor and it would be the first time, that Go claims to do that.

Rob states the opposite, again


This is exactly, what I am saying. I initially stated exactly this:
That the language is appealing to me as a newbie.

Now, I see people with decades of computer scientific background arguing about one, two language features, which may or may not simple.

And this in an Elixir forum, defending simplicity of Rust, C and C++



A google search for “golang kernel” will take you far.

Starting point, “golang accept interface return struct”. Other use of interface is as good as accessing pointer.

Basic concept, no nil and no exception. It fails when it empty, or on how you decide to fail.

I love Elixir because it serves a purpose and for being practical right now, so do Go.


Go appeals to me because it is so fast to get started with and has got a comprehensive standard library. It is also opinionated meaning that you just have to accept what is given to you and work with it.

For a lot of tasks this gets you very far, very fast. I also found it very easy to learn compared to other languages. And not just the language but the tools and structure around it. Perhaps it is my algol knowledge that works in my favor.

If I have a problem at hand and want to solve it quickly go is great. Two examples from my own:

  1. I needed to write an HTTP proxy which can save http requests and bodies to files. I looked into doing it in various languages. All with various complexity. With go, I could do it really quickly, using only standard library and compile-pile to a binary which I can ship to any 64-bit linux box as a utility.

  2. Dummy HTTP server with configurable randomized pareto response times. This is easy in many languages, but, again, I can just follow the documentation in the standard library, and get a performant, easy to deploy binary I can run anywhere.

Hence my experience tell me go is a very good choice for small utilities and services. I’ve also ported one of our larger services to go (which is quite a bit more involved). It was really quick to write (and read even with all the error handling). What I don’t like here is the mutability, and nil aspects of the language. Error handling is also problematic if you aren’t disciplined. I also haven’t designed and structured a larger application so can’t speak for go there.

Does it have warts? Yes, and I guess the troubling thing is that it wouldn’t have to have these warts. It is a new language which should have been able to avoid it, even without changing the goals of go.

Error handling has been mentioned. Yes, it blows up code, but in reality I don’t think it obscures the reading too much. If there was a way to type check that errors are being handled, and perhaps use Types instead of strings for your errors (which I actually think is possible) then the last two things to complain about is verbosity and that they don’t compose very well.

You can of course always panic, defer and recover, which may be legit depending on use case.

It depends on what sort of skills you are referring to? Pure language skills? For me, skills that make a good developer has hardly anything to do with the actual language. I.e

  • Sys Op
  • Databases (modelling, SQL querying, operations)
  • Integration protocols
  • System architecture

And you can get those in any languages. The golang constraints actually hinders you from exploring new language abstractions and I think it is by design. Yes, it makes the language feel a bit anemic, but you don’t spend time on making decision which have not too much impact on the overall result. And as they say, the wrong abstraction is much worse than no abstraction at all.

Yes. But it is a trade-off between statically typed and dynamically typed system. If in fact, golang was created to onboard new googlers with previous experience of java and python then I’d say it has succeeded in its goal. People do deploy dynamically typed system afterall. And when do you draw the line? Haskell for example is not as safe as Idris, so one could say that Haskell undermines the “Haskell is statically typed” argument too.

As a tangent. There is not enough research done, if statically typed systems are actually preventing bugs in software. There has been a few attempts, which doesn’t show any bigger difference, but their size and methodology has been a bit flawed (in my opinion).

Too soon. The bodies are still warm from the previous battles and you start joking about it?


This is my impression too! That’s what I recently used it for, and actually even had to fight my CTO to allow me to use Go :slight_smile: The two things I really like is that it’s easy to pick up the basics, and the cross-compile standalone binary (which was the main reason why I wanted it for the job at hand). It took me about a day to get from no knowledge to producing a working Windows .exe on macos.

I wouldn’t want to use it for more complex tools though, and definitely not for backend systems.


This is exactly my point. How much in C++ is utterly broken?
You could do a ‘C++: The good parts’ easily and it got already written, you find actual artifacts of it in the web.

O’Reily was obviously scared to receive a flame war after the inital announcement. :stuck_out_tongue_winking_eye:

There are so many parts in C++ you can bitch about and I am sure OvermindDL1 can tell us also something about that?

Type hierarchy comes in my mind, and that the code guidelines by Google for C++ contain probably more characters as the basic documentation of Go and F-Sharp together…

Does this make C++ a bad language?
Does this remove all its strengths?
C++ is still a superb language, if you know what you do.

I am still convinced that Go is superb for a lot of people, they are perfectly fine with it and the upcoming 2.0 brings fresh air.

That doesnt mean its free of errors, its simply incorrect to call it unusable and garbage.

And since so, also very unprofessional and unscientific, IMHO.

I also see its flaws, while those ones really become somewhat acceptable to me, when I look on most other imperative languages.

So, to answer the topic:

Go is so popular, since it removes a lot of issues in popular languages.

Even when it seems to add some more on the other side :wink:

Happy hacking :smiley:


I did not say that, I only said parts of it are unusable, namely the error handling.

Also I have said I miss parts I am used to from other languages, namely proper dependency management and generics (or templates).

This three are my main painpoints, I can workaround but these make me not like the language. Of course I am biased, as I know from other languages how it can be done “better”.

And to be honest, I like that I can draft and prototype quickly with it.

And when I have something that works (or stops to do so randomly) I pipe it through a linting tool that reveals all those places I did not yet handle the returned errors :wink:


Have you used interfaces?


Of course I did, but how can they help me? They do not let me express "a stream of Foo" vs. "a stream of Bar", only a stream of “things” and I have to type assert on the consumer.

Also mutexes are just a cenvention, nothing forces me to use them, after I have seen how it can be done in Rust or C++ where you have a Mutex<Int> which you have to lock to get access to the boxed Int (and even better, because of RAII you get the unlock for free), this is something I do miss everywhere else not :wink:


I simply asked because it get mentioned in the link above.


I only skimmed that article and it encourages a lot of things I learned over the years that are not good for various reasons…

  1. Repeat yourself (You have to change x-hundred occurences when you want to change something)
  2. Runtime type checks (Runtime types can be totally different from what you expect under some circumstances)
  3. Reflection (does things at runtime which belong into compile time, and therefore cost runtime, repeadately!)