The Value in Go’s Simplicity

https://benjamincongdon.me/blog/2019/11/11/The-Value-in-Gos-Simplicity/

by Cthulhu_ • 7 years ago

368 360 7 years ago

capableweb• 7 years ago

People who likes Go's simplicity, have you ever looked into the even simpler syntax of lisps? For example, Clojure have minimal amount of syntax, that once you know, you know the entire language. The rest is just libraries that you use, the actual program/data structures or language modifications (macros) that each codebase usually employs a bit different depending on needs. But lisp languages are really, really simple, even more simple than Golang (or any C like language) can be.

Take a look at this (short) page which describes ALL the syntax of Clojure (except macros) if you're interested: https://clojure.org/guides/learn/syntax

pixelmonkey• 7 years ago

As a long-time Clojure user, I find the claims that many Clojurists put forth that Clojure “has a minimal amount of syntax” to be quite misleading, especially toward beginners.

I think Clojure has a lot of syntax. The syntax is just embedded in a number of conventions, macro mini-languages, and the reader syntax itself. Because Clojure’s syntax can be extended in user space (via macros and related tooling), the syntax also grows more rapidly than other communities.

As a professional programmer who came from Python, Java, C, and JavaScript, I found a lot about Clojure compelling, but “minimal syntax” was not one of the compelling points. To the contrary, I think there is a lot more to learn in Clojure than other languages about how to properly structure your code.

As I wrote in my blog post comparing Python and Clojure:

... the Python programmer will observe that in the Clojure program, many aspects of the program are implied, rather than annotated by special syntax. Many Clojure proponents will say that Clojure has a “simple syntax”, but I think this is misleading. They don’t mean simple as in “easy to read without prior context”. They mean simple as in “unceremonious”. Perhaps they mean simple as a contrast to “baroque” (how you might describe Java or C++’s syntax). Clojure does have a syntax, but it is implicit from the layout of the code in the list data structures.

http://amontalenti.com/2014/11/02/clojonic

millstone3• 7 years ago

Agreed - a concrete example is the threading macros:

    (defn calculate* []
       (->> (range 10)
            (filter odd? ,,,)
            (map #(* % %) ,,,)
            (reduce + ,,,)))

This is nominally a library as it can be implemented via the language primitives. But in practice this occupies the same space as Haskell's do-notation, and the learner cannot ignore it. The lack of special syntax becomes an implementation detail.

robert_tweed• 7 years ago

An important difference is that Go not only has a concise set of constructs, it also tends to deliberately avoid abstraction.

So any given piece of code is very explicit and self-contained. Apart from function calls, you can tell exactly what it does without looking up anything else, like a macro definition for example. It similarly doesn't have a lot of different ways to do the same thing tends to be opinionated about idioms (gofmt, for example).

Something like a Lisp DSL would be antithetical to the Go model of what simplicity means.

ken2• 7 years ago

Apart from function calls, you can tell exactly what it does without looking up anything else, like a macro definition for example.

It sounds like you’re splitting hairs here. In my experience, macros aren’t any more mysterious than functions. The only difference, after all, is when they’re evaluated.

pjmlp8• 7 years ago

Yep. Copy-paste for the win.

Maybe they should do away with the abstraction that memory is endless.

_ph_9• 7 years ago

Go does not avoid abstraction, only certain constructs. You do have functional abstraction with high order functions. You do have types and methods.

edflsafoiewq• 7 years ago

The simplicity of Go isn't in a syntactic minimalism. It's in the self-conscious restraining of abstractive power (eg. the article's example of the only generic data structures being slices and maps).

ken2• 7 years ago

We already have a term for that: “low level”.

I assume that people are trying to attach it to the term “simple” because that word has a much more positive connotation, but the meaning isn’t the same.

jerf3• 7 years ago

Lisp is simpler on a completely different dimension. Lisp code can be arbitrarily complicated to read due to arbitrarily complicated macros. This is frequently blamed for Lisp's continuing failure to take off, that every major program written in it is eventually actually written in a custom dialect of Lisp. This directly opposes, for better or worse, the sorry of simplicity Go has. (I think there's a place for both, so I'm not judging one as "better" here.)

catalogia• 7 years ago

Avoiding Lisp because macros could be abused is like avoiding C because functions could be abused. What if I create a function called "log_error" that actually tries to reformat your hard drive? There is nothing in C that requires me to give functions names that aren't nonsensical.

Macros, like nearly anything else, are an abstraction that requires a little bit of restraint and common sense when you're using them. The answer to the "functions can have misleading names and therefore can be used to create intractable tangles of incomprehensible code" is "well then don't fucking do that", which is the same answer to the majority of problems people think macros cause.

kazinator• 7 years ago

Lisp code can be arbitrarily complicated to read due to arbitrarily complicated macros.

Lisp code can be arbitrarily simpler to read due to nice macros.

This is frequently blamed for Lisp's continuing failure to take off.

This is largely a meme spread by people who have never developed in Lisp.

The relative lack of popularity is discussed in Lisp communities, but that particular hypothesis isn't taken seriously, if it comes up at all.

bpfrh• 7 years ago

Not looked into it, but the simplicity of Go doesn't only come from its syntax.

It also comes from the standard libraries which cuts down on libraries you have to use.

For most of the stuff I do with Go I don't need extra libraries and when I use them, there are no suprises which mean I can easily check what they do.

Compare that to JS or even Python, where I have to either use libraries for even the most basic stuff or have a huge amount of syntax and keywords.

grenoire• 7 years ago

This is something that people overlook quite often. It is very important to have a well-documented, up-to-date, and capable standard library packaged with your language. It just creates a smoother experience altogether.

Besides that, it also sets the standard for the 'right' way of designing your interfaces and whatnot. In Go, the third-party libraries are often compatible with the standard library methods and interfaces, which is just fantastic in both mobility between libraries, and having consistency with different projects.

blondin2• 7 years ago

Compare that to JS or even Python, where I have to either use libraries for even the most basic stuff or have a huge amount of syntax and keywords.

in python, you don't have to. same for javascript, before the whole jquery era, and the nodejs era that followed, we didn't even know what javascript libraries were.

JohnStrangeII• 7 years ago

Yes, I've been programming in Lisp and Racket for the past twenty years and recently switched to Go. The main reason was the availability of a large number of packages and the general tooling for Go. So far, I'm quite happy with my choice. Productivity is slightly less than with Racket, but outweighed by the small size of the executables, easier deployment, and more 3rd party libraries. Of course, I'm missing a lot of features that pretty much any Lisp offers, but the simplicity and static typing does overall have many advantages.

Since you mention Clojure: That's useless for me, because it runs on the JVM. One reason to use Go is exactly that it produces static, self-contained executables that don't require any heavy infrastructure.

pmoriarty3• 7 years ago

For small executables, check out Chicken Scheme. For static typing, see Typed Racket (though Chicken Scheme is also moving in the direction of gradual typing, if I recall correctly).

bb1234• 7 years ago

If you care about a rich standard library, and static self-contained executables, I would strongly suggest Crystal. I have used both Go and Crystal, and the latter is much more productive as well as simpler. It’s standard library is richer. See, for example, the things you can do with strings with the provided functions. I used to love Go. But after some time the verbosity got tiring. I moved to Crystal, and there is nothing I miss from Go. Two big caveats: 1. I dont work in a big team. 2. My main use case is a web-backend.

zozbot2343• 7 years ago

FORTH syntax is even simpler than any lisp.

makapuf2• 7 years ago

So is BF... that does not mean it not complex to use.

_ph_9• 7 years ago

I am both using Go and Lisp and like both very much. As mentioned by others, the simplicity of Go isn't in the syntax, it is the conceptual simplicity. To large extend it does share this with Lisp. Especially if you look at scheme, most abstractions are built on top of functions, something you can equally do in Go, as you have first class functions and closures.

orbifold• 7 years ago

I‘be looked into clojure briefly. What made it unattractive to me was the lack of performance and complexity of the build tooling. Simplicity in go goes beyond the language itself. It is also very simple to build, depend on libraries and deploy.

silasdavis2• 7 years ago

Go has had an absolutely appalling dependency management complexity for a long time. Go modules looks like it is going to fix that but it's long time coming.

fortran77• 7 years ago

Simple syntax is why I prefer Erlang to Elixir. The syntax is so simple you can learn it in one day easily -- a big plus when you have to work in multiple languages at the same time for one project.

blondin2• 7 years ago

i agree with you. go is not the simple language its creators wanted. and i feel like it's only going to get more complex from here on.

for example, i couldn't get a library to work the other day because of one of the dependencies needed a specific version of another library but "go get" (1.13.4) was getting utterly confused.

i never looked into the modules thing and i found that there is a 4 parts series of articles on the official blog explaining modules are and why we need it. i just gave up at that point and decided to manually copy the version i wanted to the $GOHOME/src folder and it got me going...

masklinn6• 7 years ago

People who like "Go's simplicity" are talking about a completely different kind of simplicity than Lisp's or Forth's or Smalltalk's.

The latter are simple in that they're built around a few core concepts which are available to the developer, almost any tool the language designer had is available to the end user. They're simple in the sense that old school legos or meccanos are simple.

Go is simple in the sense of simplistic, it provides a much larger number of restrictive features and most definitely doesn't give end-developers access to the language designer's tooling. It's the simplicity of playmobil or duplo: the developer is provided with much more concrete (and effective in a way) but much less flexible "primitives".

And this is no secret, there's a pretty famous quote from Rob Pike explaining the design and purpose of Go:

our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

Making codebases look uniform and preventing building abstractions (by the language being actively hostile to abstractions which are not built-in) is in line with that.

tfha11• 7 years ago

What is with all of the condescension that other developers have towards Go developers? Go has a set of highly desirable features that are very practical for building large team projects.

Imo it's unnecessarily hostile to compare go to playmobile and diplo, and it really encourages people to overlook the genuinely excellent features that go supports.

millstone3• 7 years ago

"Our programmers are Googlers" comment is a retcon! It was from 2014; what was the pitch before that?

In 2010 Pike presented Go as "suitable for writing systems software" [1] such as: web servers, web browsers, compilers, programming tools, IDEs, and OSes ("maybe").

Today Google makes a web browser, and lots of compilers, and programming tools, and an IDE (Android Studio), and at least two OSes (ChromeOS, Android), and Go is not relevant in any of them (excepting Go tooling).

In 2012, Pike was still pitching Go as a C++ replacement, but was dismayed that it was appealing to Python/Ruby programmers. Why don't C++ programmers use Go? He hypothesized [2]:

C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way.

The saltiness was aimed at Google's own C++ engineers, but I honestly don't think that Go was or even is up to reimplementing v8 or Blink.

But today Go really is enormously successful and compelling. It failed at displacing C++ but found its niche. Kudos. But retcon - it is a mainly server-side language because that's where it succeeded, not what it was designed for.

Today Rust is busy displacing C++, so it can be done. Go just wasn't the one to do it.

1: https://web.stanford.edu/class/ee380/Abstracts/100428-pike-s...

2: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

petilon• 7 years ago

I wish developers of TypeScript would learn from Go. TypeScript is awesome, but it is getting larger and larger and larger with every release. Soon it will become like the US tax code, and no one person will know the entire language.

erokar4• 7 years ago

No wonder, since the man behind Typescript, Anders Hejlsberg, is also the man behind C#. The goal seems to be to include as much as possible and constantly evolve the language. Some people appreciate that, others not so much.

thomasz2• 7 years ago

Typescript utilizes black magic to help building large systems based on the shaky foundations of javascripts type system. C# is very conservative in comparison. It only adds concepts that have been implemented by (often times several) other languages before, and are therefore well understood.

frou_dh2• 7 years ago

The armchair psychologist in me considers there to be two camps of programmer in this regard. One that gets distressed by something like not having the entire language in their head, and the other that doesn't ponder that kind of quandary in the first place.

phamilton• 7 years ago

I've shifted toward the latter as I've embraced type systems that can substitute for having the entire language in my head.

At the end of the day, I rarely care about the language. I usually just care about my data morphisms. And a good type system helps me immensely in that regard.

tfha11• 7 years ago

That's really not it. The more complex a language is, the more ways there are to approach a problem. The more things to have to learn and adapt to when reading code another engineer wrote.

You want code to be obvious. The senior engineer smiles when the junior engineer reads his code and says in just seconds "I know exactly what this does and have high confidence that it has no bugs."

Simpler languages facilitate simpler codebases.

sek• 7 years ago

I think the situation with TypeScript is a little different. JavaScript is a very powerful language and you can do a lot of "hacky" things with it. It feels to me like most new features are an improvement, I use :any very rarely now and can model almost everything with it.

I you would design TypeScript from scratch, you might have a point.

TorbjornLunde• 7 years ago

TypeScript's complexity comes from trying to model typical JavaScript patterns using a compile-time type system.

It turns out trying to model a dynamic language's typical usage at compile-time is lead to some complicated stuff.

Personally I think it's mostly worth it since most of that is hidden behind API-boundries or (more commonly) in type-definition files and your own code typically either has really simple type annotations or is inferred (i.e. not explicitly type annotated).

But I see your point and it does sorta feel a bit C++-like in this respect sometimes.

implicit• 7 years ago

For what it's worth, I get the feeling that the reason TypeScript is growing so much complexity is not because the language designers expect you personally to use it all.

It's there primarily so that your development environment can give you accurate feedback when you're using your favourite JS libraries.

thomasz2• 7 years ago

Exactly. The <title> of typescriptlang.org is "javascript that scales". All those features in TypeScript exists to express common js idioms in terms of a static type system, which in turn enables stuff that makes programming in the large easier.

aikah• 7 years ago

Typescript's goal is to represent the complexity of a dynamically typed language with type annotations so you can run static type analysis and verification. Typescript shouldn't learn anything from Go, because their goals are completely different.

The great thing with Typescript is that you don't have to use all its spec to benefit from it, so no user has to know the entire spec.

But you can't complain that Typescript does exactly what it was invented for. Blame Javascript.

erokar4• 7 years ago

While there is certainly something to be said for simplicity in a language, I think Go is too extreme in this regard. What it gains in simplicity it looses in expressiveness. This leads to more lines of code per feature, and bugs in software has been shown to be a function of LoCs [1,2,3].

One example of Go's lack of expressiveness is that loops are not abstracted away, e.g. you can't use higher level constructs like map and filter on collections. There are other languages that IMO strikes a better balance between simplicity and expressiveness, like Python and Elixir.

1. https://ieeexplore.ieee.org/document/1702967

2. https://link.springer.com/chapter/10.1007/978-1-4471-3003-1_...

3. https://www.amazon.com/gp/product/0735619670/ (Chapter "Developer Testing")

vhakulinen• 7 years ago

What it gains in simplicity it looses in expressiveness. This leads to more lines of code per feature, and bugs in software has been shown to be a function of LoCs

If the lack of expressiveness equals to greater amount of code and thus more bugs (in Go), does the same apply for languages that are more verbose (say, Java)? And if language is more expressive and less verbose (say, Python or Javascript maybe?), does it mean less bugs?

fluffything2• 7 years ago

The OPs claim that it has been shown that bugs are a function of LoCs is unsubstantiated at best.

The number of bugs in a program correlates with the number of LoCs, but that's about it (correlation does not imply causation).

The claim is also quite absurd, since, for example, you can pre-process any C or C++ program ever written into a single line of code, yet this operation doesn't reduce the number of bugs in these programs, therefore the amount of bugs is not "just" a function of the amount of LoC.

Languages with better abstraction capabilities than Go (e.g. Rust or Python), might require programmers to type less, but the resulting lines of code are often dense. For example, I'm quite comfortable with Rust iterators and Python lists comprehensions, but it still takes me much longer to parse what code using these abstraction does, than code that just uses a simple for loop. It definitely feels great to cram a 10 LoC loop into a 1 LoC list comprehension in python, but reading that code 6 months later never felt that great, even for code that I've written myself. I just need to stop at those lines for much longer.

erokar4• 7 years ago

In general, yes. The more lines of code per feature, the more bugs per feature. Also, the guarantees you get from a typed language like Java does not seem to prevent bugs to a meaningful degree. Probably things like programming culture associated with a language is more important, like a strong preference for testing.

This is an interesting study on programming languages' effect on software quality: https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf

imode• 7 years ago

To add, here's a nice article on implementing map from scratch: https://blog.burntsushi.net/type-parametric-functions-golang...

It illustrates what you have to pay to get this kind of functionality for arbitrary slices.

I wonder how this would change with generics.

Un1corn• 7 years ago

I'm not sure I would have called Python simple, it's a great language and it's not as complicated as something like C++ but it's not simple.

For example when should I use NamedTuple and when should I use a dataclass? Should I be using a list comprehension or a map/filter/reduce? When should I split that list comprehension? I have seen (and made myself) terribly long lines with only list comprehension and it was hideous.

erokar4• 7 years ago

When I said Python was simple I was talking about the concepts, functions and datatypes in the core of the language. I agree that if you include all the modules that come with Python it is a "big" language.

Scarbutt• 7 years ago

You can write perfectly fine Python without any of the features you mentioned.

fernandotakai• 7 years ago

Should I be using a list comprehension or a map/filter/reduce?

yes, use list comprehensions -- they are more readable.

When should I split that list comprehension?

just use common sense. if you can read it and understand without thinking too much, that's good.

it's readability beats short code 100% of the time.

jerf3• 7 years ago

The results on code lines being directly related to bugs is getting old. Programming languages and practices have changed substantially in the past couple of decades. I'd want to see more recent evidence.

Besides, in practice I find lines of code in Go vs. Python are only maybe 20% different in many common cases, if you ignore the struct declarations which I have a hard time calling "code". (Being not a Turing complete language, that particular subset can't be considered vulnerable to the issues that Turing complete things can have.) I find myself very frequently wondering how many people complaining about all the lack of abstraction in Go have A: used it and B: used it to the point they're writing Go in Go. (Go just blows if you're trying to write Python in Go or something, or if you insist that you know better and must use map, filter, etc. rather than for loops. For all languages X, writing X in X is important, but Go is really graceless if you don't learn how.)

Now, if you do get to B, it is still true that Go does not quite abstract as "well" as some other languages, but it does abstract well enough that you can start having reasonably conversations about whether those other abstraction tools are actually paying their way in a lot of larger, shared code bases. If we throw out a ton of language complexity, but only pay a relatively small price, are they really carrying their weight? The answer will vary from code base to code base, but I think it's not necessarily some sort of horrid, unthinkably idea that not every program must be assaulted with the most powerful, complicated toolkit regardless of the price incurred by the complication.

coldtea5• 7 years ago

The results on code lines being directly related to bugs is getting old. Programming languages and practices have changed substantially in the past couple of decades.

The results in those "past decades" used all kinds of languages, some far more advanced and modern than Go is today (e.g. Lisp, Smalltalk, Ada).

eternalban• 7 years ago

https://play.golang.org/p/dOYpmSK-Xor

dantillberg• 7 years ago

I ported a fairly complex (thousands of lines of code, in use in production) program from Python to Go.

The Python version is around 1/3-1/2 the size of the Go version, but the clarity with which bugs are visible in the Go version is astonishing.

There's a lot of code in Python version that "looks right" and even "does kind of the right thing a lot of the time." But the Go version lays bare corner and edge cases that were not obvious in the concise Python version.

I agree that Go usage does suffer sometimes from lack of generics. I've sometimes used code generation in its place, and it works, but it's a poor solution. At the same time, the lack of generics has helped me avoid over-abstracting in other places, which is a common bane of mine whenever I work in more "expressive" languages.

sagichmal11• 7 years ago

One example of Go's lack of expressiveness is that loops are not abstracted away, e.g. you can't use higher level constructs like map and filter on collections.

This is (or was) deliberate, with the rationale being that it makes O(n) blocks of code trivial to identify in review.

Whether or not you buy that argument is a separate thing, of course.

coldtea5• 7 years ago

This is (or was) deliberate, with the rationale being that it makes O(n) blocks of code trivial to identify in review.

Whereas, greping for .map(), .filter(), .reduce() wouldn't?

h_r4• 7 years ago

Can you explain why you think it makes O(n) blocks trivial to identify?

How is such identification made easier by manually writing out a `for` loop applying a function foo to each element rather than writing `map foo myCollection`?

temac• 7 years ago

So how does it work exactly? Are functions forbidden?

alfalfasprout2• 7 years ago

And yet introducing higher level functionality also leads to more difficult to detect bugs. I'm not sure the "lines of code:errors" correlation truly applies to all languages.

That said, anecdotally I too have found it much easier to find errors visually in go programs due to its simplicity. I find the same is true of C vs. C++.

lacker2• 7 years ago

I’ve been working in a Node codebase for a bit, and I am really missing Go’s built-in profiler and benchmarking support. It’s pretty well integrated into the default tooling, and easy to use.

XCSme• 7 years ago

What about using the Chrome Dev Tools for Node profiling?

lacker2• 7 years ago

The node tools & chrome dev tools just seem very poorly integrated by comparison with the go tools. In go, if you have a unit test and you want to profile the code in it, it's just a few code changes to set that up. To use the chrome dev tools, you have to connect to some running process with a browser, which requires at least rearchitecting whatever you're doing so that it's an indefinitely running process. The built-in node profiling is sort of medium in ease of use, but low quality in the information it returns. Often it's hard to figure out what high-level function calls correlate with the low-level performance info.

pjmlp8• 7 years ago

Expecting mass exodus from Go developer to Oberon-07 as the language starts adopting more features.

The "simplicity" is shown in the amount of code generator frameworks.

FpUser3• 7 years ago

Why bother if there are already well developed relatives Delphi/FreePascal with nice tooling and plethora of libraries.

pjmlp8• 7 years ago

I was being sarcastic.

Object Pascal is already a PhD level language according to Go's design point of view.

musicale2• 7 years ago

I like Oberon, both the language and the system, but I don't see either expanding beyond niche usage, in spite of their elegance and compactness.

pjmlp8• 7 years ago

I was being sarcastic, as Wirth is probably the only language designer that removes features with each language revision.

While I loved my experience as Oberon user/dev, and it opened my mind to systems programming using GC languages, my favourite languages on Wirth's linage aren't done by him, rather influenced by his creations.

Modula-3 (which comes from Mesa/Cedar, not Oberon), Active Oberon (another ETHZ team), Zonnon, Delphi.

pcr9103032• 7 years ago

Ok, I understand that people that use Go has a different idea about it, but...

Code duplication is more acceptable in the Go community than elsewhere.
Many times, you’ll need to write that functionality yourself, or copy/paste it from a StackOverflow answer.

Am I the only person that this is regression? How can code-duplication be defended by 'simplicity'?

Fewer dependencies means fewer things that break while you let a project sit idle for a couple months.

I thought that pinning dependencies is \the\ solution for this? I don't use Go, so I'm not sure about the Go packaging story, but is there no package pinning solution? Yarn & npm handles this beautifully...

xwdv3• 7 years ago

Code duplication reduces coupling between multiple unrelated pieces of code.

Edit: not sure why the downvotes, perhaps these people have never seen a junior engineer go on a fanatical deduplication spree across a whole project, or perhaps these are the junior engineers.

YesThatTom22• 7 years ago

A little code duplication prevents mounds of dependencies.

I’ve seen people link to multi-megabyte modules to save one line of duplicated code. At Google this was a disease. Good to see they’re fixing it.

sidlls3• 7 years ago

It's not just junior engineers. Senior engineers do this, too: fanaticism and adherence to some set of practices no matter what, regardless of the context are as much a bane in this industry as chasing the latest shiny is.

robfig2• 7 years ago

Code duplication

It can be easier to maintain a small amount of code that you duplicate and check in and is purpose-built to your use case and treat as your own, compared to a general library imported for one routine that you have to think about (licensing, upgrading, auditing). Or sometimes libraries break backwards compatibility to add features you aren't interested in, and it makes busy work to stay up to date.

Is there no package pinning solution?

Multiple dependency managers have supported pinning since at least 5 years ago e.g. glock, dep, glide. Go Modules supports pinning.

Pinning is the solution for avoiding breakage due to dependencies

Related to the first point, in general you have to do work to upgrade your dependencies. If not because you care about bug / security fixes that happen, then because you use ANOTHER library that has the same dependency, and that other library uses a feature only present in a newer version. Any time you upgrade a library it takes work to verify nothing has broken, and potentially work to fix things that do break.

robfig2• 7 years ago

One thing I omitted in the response which might be relevant is that usually you can only use one version of a package in any given build[1], so you have to use a version that works for everything that depends on it.

I think that might be a difference for folks coming from other ecosystems.

[1] The asterisk is that you can have multiple major versions coexist using Go modules, or you can use gopkg.in import paths, or some other workarounds, but in my experience that is not common and typically you do have to find a single version that works for your whole program.

nnutter• 7 years ago

I do not think Go Modules supports pinning except at the major version level and even there v0 and v1 are treated as fluid.

My experiences trying Go Modules has shown it to “randomly” modify the go.mod file.

kortex• 7 years ago

My current mayhem is containerizing an object detector pipeline/system with dozens of gigabytes of dependencies. The main dev has pulled in a library that makes opencv look like small potatoes, just to be able to use a whopping two functions. Apart from the misery that is a 4 hour container build every time something breaks, someone upstream broke my implementation (python 2, because ROS, ugh) with a casual '@' for matrix multiplication.

Yeah I love DRY and code reuse as much as the next guy, but sometimes copypasta makes sense.

I will say go's nature and/or culture make grafting in functions a lot easier.

pcr9103032• 7 years ago

It can be easier to maintain a small amount of code that you duplicate and check in
compared to a general library imported for one routine that you have to think about

IMHO, that's why small, one-utility-function libraries in the JS ecosystem([0], [1], [2]) are useful. (Unlike the general tone in HN where npm and left-pad gets a lot of hate.)

Look at Quickutil[3] for examples of other languages. (In this case, Common Lisp.)

[0] https://github.com/sindresorhus/mem/blob/master/index.js#L7

[1] https://github.com/sindresorhus/tempy/blob/master/index.js#L...

[2] https://github.com/zeit/ms/blob/master/index.js#L48

[3] http://quickutil.org

littlestymaar2• 7 years ago

It can be easier to maintain a small amount of code that you duplicate and check in and is purpose-built to your use case and treat as your own, compared to a general library imported for one routine that you have to think about (licensing, upgrading, auditing). Or sometimes libraries break backwards compatibility to add features you aren't interested in, and it makes busy work to stay up to date.

The overhead you're talking about isn't a real problem in my experience, as long as your dependency manager has semver support (all of those I know).

When writing (or copying from SO) a simple snippet that's supposed to do just what I want, almost 80% of the time there will be a bug in it (typically edge cases are not covered)…

For instance, before Go 1.10, there was no rounding function in Go's std lib, and 99% of the code you could find on the internet to do this (simple) task was buggy: some failed with negative numbers, and others due to bad handling of floating point numbers…

mobjack• 7 years ago

Often developers create an abstracted mess to avoid code duplication.

The code is hard to follow and modify later if the common functionality needs to be handled differently.

There are many times when working on my old code that I was burned by this.

Code duplication isn't necessarily a good thing, but the cure can be worse than the disease. It is better to be pragmatic.

parhamn• 7 years ago

As with anything else this depends on context (code, assignment, goals, etc). One sentiment that I share with OP is that somehow, you do feel less pressure to over-dry than other languages. Probably because (1) more code doesn't necessarily feel like more bug surface (2) you can avoid a class of issues like parameter (mis)usage and excessive branching that you would need to satisfy de-duping.

Obviously trivial cases of code duplication could/should be resolved, but for less than trivial cases sometimes its just fine to cmd-c & cmd-v with some minor use-driven modifications.

Remember the lib versions of many of these snippets need many many parameters to satisfy everyone's needs.

urii93nci• 7 years ago

It’s easier, to me, cause I can open almost any Go source file and expect pretty much some vanilla looking code and not some cleverness from a dev that is no longer working there for whatever reason.

Look at our fiction and non-fiction writing; very few real plot loops and themes. There’s a common wisdom in writing I’ve heard called “kill your darlings”, those bits of prose that you love in isolation, but big picture, really don’t add to the detail of the world or motivation of the character

I do the same with code: keep code itself vanilla af to avoid complicating or distracting from the big picture of its value

Oh and that’s at work. To be certain, I fiddle with favored abstractions and ideas on personal projects when the mood strikes. I cram assumptions into abstractions because it’s just me.

But at my job, where I only go because of social pressure to conformity, I don’t really want to wade through other people’s emotional opinions. I just want to copy/paste together same old to keep it easy.

Give a programmer a job building some thing real like a car and you’ll get The Homer.

sidlls3• 7 years ago

Code-duplication and goto statements have something in common: neither is inherently bad, and both are zealously maligned inappropriately by the developer community in aggregate. Sometimes two functions perform the same abstract operation on the data but have subtle differences in the implementation: fully duplicating the common parts in two different functions is not a bad thing necessarily. But "testability" and "reusability" zealots will turn blue in the face arguing that one should carve the functions up into a mess of abstracted spaghetti to support them both. The result is code that isn't any easier to read or maintain and, worse, is less performant.

crimsonalucard7• 7 years ago

Most people are thinking of gos simplicity vs. javas over abstraction of oop. I personally prefer the ugliness of go to the over abstraction of java.

However go is missing fundamental concepts of algebraic data types that in itself is causing problems. In their effort to create a language that moved away from the flaws of OOP they failed to have knowledge about type theory and created a language that in removing the flaws of OOP they have also accidentally removed fundamental language concepts. My guess is that they didn't know about the theoretical concept of sum types at all because sum types exist in Java as inheritance.

The two biggest being parametric polymorphism and sum types and it is these two things and the consequences of these two things that are causing the ugliness in go. Everything from default zeros, functions that return both errors and values and repeated code.

coldtea5• 7 years ago

Am I the only person that this is regression? How can code-duplication be defended by 'simplicity'?

Easily. People can avoid code-duplication in many ways, and some of them are harmful.

E.g. by building abstractions that get out of hand and add mental burden to track the program flow and bugs.

Or by making any small piece of code into a standalone 2-3 line function, so that anything always happens elsewhere, and keeping track of flow is made difficult.

Or by prematurely putting code into a function when it's just used in 2-3 places, and then when another need arises that doesn't fit in to the already captured function, hacking the function to handle different behaviour on different arguments/flags and ending up with monstrosities.

YesThatTom22• 7 years ago

Go’s simplicity means I have to focus most of my time on solving the problem instead of showing off that I know (insert inscrutable feature) and figuring out what the last person to touch the code when they used (other inscrutable feature).

That sucks! Why sh I kid I help the company solve their business problem when I could be spending all afternoon debugging (insert language issue)

AzzieElbab• 7 years ago

I do not find go simple. Too many hidden conventions that my brain refuses to memorize because I do not see any logic behind them

kristianpaul2• 7 years ago

I would love to use Go just if it wasn’t for the garbage collector

bsaul• 7 years ago

Go is compiled to assembly. What makes you think it's an interpreted language ?

kristianpaul2• 7 years ago

Garbage collection

hu33• 7 years ago

Go is compiled. The compiler is so fast that for most programs it looks like it's interpretting the code:

go run main.go

---------

OP edited in "garbage collector" over "interpreted".

musicale2• 7 years ago

But the garbage collector only pauses for 100 microseconds... until the next memory operation, when it pauses again. ;-/

More seriously, as of last year at least mark phase pauses could be significant, on the order of seconds for large heaps.

ausjke2• 7 years ago

Does golang have an option to use 'shared' libraries/modules? while it is great its size is unfit for so many embedded devices, tinygo is a good try, but still.

takeda4• 7 years ago

As far as I know it doesn't. One of the selling point is that everything is a single executable.

suresh70• 7 years ago

I'm new to Golang and have been exploring it for a while. Go isn't simple to me when it comes to web dev. It starts with the scarcity of resources to learn from. I'm looking for how to structure the codebase(boilerplates, best practices etc), how to go about unit and integration testing, dependency and configuration management. Are there any resources somebody here can point to regarding these topics?.

christiansakai• 7 years ago

Checkout some examples of Clean Architecture in Go.

dhconnelly• 7 years ago

https://www.usegolang.com from Jon Calhoun, who is well-known in the community, could be useful

dunkelheit2• 7 years ago

One benefit of radical go-style simplicity that I haven't seen discussed much is that it forces you to focus on the task at hand. Like, you know that your code will look like shit anyway so it is pointless to fuss too much over it. Whereas many programmers using a more "clever" language like haskell will spend a lot of time trying to make code more readable, searching for the right abstraction, arguing whether something is a monad or some other gizmo. Most of it is wasted intellectual effort.

Everything in moderation of course. For me personally simplicity of go is too much and I don't feel comfortable writing it.

RHSeeger• 7 years ago

Most of it is wasted intellectual effort.

I would challenge this. I would say _some_ of it is wasted, but most of it works towards making the code more understandable. And code being understandable to the next person to read it (both in the small "what is this block doing" sense and in the larger "what is this algorithm doing" sense) is very important.

sidlls3• 7 years ago

I can't speak for the GP, but my interpretation is that the wasted effort comes from doing what you describe when, instead, one could have chosen a simpler language and produced understandable (albeit "ugly", "not eloquent") code the first time round. Then one can turn those intellectual wheels on a more interesting problem to solve.

dunkelheit2• 7 years ago

Some of it is wasted, some is genuinely useful and to know which is which you need experience and good judgment. My point is that it is incredibly easy to fall into the trap of pursuing maximum code beauty and abstraction and wasting a lot of time in trying to attain some shining ideal, especially if the language is conducive to it.

tfha11• 7 years ago

I find other people's go code is generally much more readable than other people's code in most other languages.

Go's simplicity and heavy idiomatic culture means all the code more or less looks identical. This is great for team projects.

frou_dh2• 7 years ago

Is the much touted "Make invalid states unrepresentable" consequence of garden-variety Sum Types wasted effort? Seems very good bang-for-mental-buck to me.

rectang2• 7 years ago

Joe Doffy argued, in my view persuasively, that Go missed an crucial opportunity by not requiring that users actually do something with returned error codes.

http://joeduffyblog.com/2016/02/07/the-error-model/#forgetti...

It’s surprising to me that Go made unused imports an error, and yet missed this far more critical one. So close!

Result/Option/Maybe types force unwrapping, which makes ignored return codes auditable and allows you to manage technical debt.

This doesn't speak to Go's simplicity so much as it does to Go's conservatism. Having the Go standard library use sum types, establishing a precedent and a culture, would be no more complex in the absolute, but would have been more of a stretch for its initial target user base.

corporateslave5• 7 years ago

Some of us need the intellectual delight to make the work bearable. If I can view my code as some kind of art, constructing great abstractions, it helps me forget that I’m spending a huge portion of my life logging, aggregating, and analyzing internet clicks.

sagichmal11• 7 years ago

You should view this condition as something to fix in yourself. Take joy in doing these things with precision and efficiency, and making your work easy to understand and explain to others. It's hubris and, frankly, rude to subject your professional colleagues to your artistic expression.

dev_dull2• 7 years ago

The problem is you’re delighted by the code but everyone who comes after you can’t stand it.

unethical_ban• 7 years ago

As for writing code, I write it cleanly and with proper, clear language in-code commenting for ME. Because I need to go look back at what I've done and why often.

ForHackernews2• 7 years ago

Consider trying to get a job in a part of the tech sector doing meaningful work. Just because the best minds of our generation are squandering themselves on adtech doesn't mean you have to do the same.

matthewmacleod5• 7 years ago

I find the opposite is true. It too often means the focus is on fiddly and tedious book-keeping - instead of writing some code that says “please do a thing”, I write some code that says “please perform these 20 steps to do a thing in excruciating detail even though you are much better at deciding how to do this than I am”. It’s noise that detracts from the readability of the code far too often for my taste.

zer013• 7 years ago

This has absolutely been my experience as well. Golang is good at being fast, but to say that it helps write better code because of its missing batteries/features is just silly I think.

"I want to interact with a REST API and pull a field out of its response JSON" is an incredibly common workflow, and yet to do that in golang is far from trivial. You need to define serializer types and all sorts of stuff (or you can take a route I've seen encouraged where people to use empty interfaces, which can cause runtime exceptions).

Same deal with a worker pool. Concurrency is great, but instead of providing a robust, well written solution as part of the language itself, it gives you a toy like this https://gobyexample.com/worker-pools (still the most common result on Google) that is only 80% of the way there. Then you find yourself bolting things onto it to cover your features (we need to know if things fail, so let's just add another channel. We also need finality, whelp, another channel it is), and before you know if you have an incomprehensible mess.

dkarl• 7 years ago

I agree with this 100%. Go is great for micro-readability: "what do these ten lines of code do." Go is horrible for macro-readability: what does this module do, what does this service call do. If you compare a fixed number of lines of code, I wouldn't be surprised if Go always wins out for readability. But if someone says, "Figure out the business logic behind this feature implemented in Go," get ready to spend a lot of time scrolling through low-level code.

I always thought code written as page after page of low-level details was bad code. I thought the same thing about code written as class after class after class of OO hierarchy. But people talk about Java and Go as if it's impossible to write unreadable code in them. I don't think code has to contain a single hard-to-understand statement to be "unreadable." After all, code that is unreadable because of abuse of powerful language constructs isn't literally "unreadable." You call it that because reading it requires an unreasonable amount of time and effort. The same thing can (and should) be said about code that requires an unreasonable amount of effort for any reason.

To me, it's just different ways that programmers can waste your time. One programmer might waste your time by combining powerful language features in cryptic ways; another might waste your time by hiding crucial structure in a vast sea of details. What's the difference?

atombender3• 7 years ago

I agree that Go forces you to focus on mechanics of your code more so than some "fancier" languages.

However, Go's poor type system also forces you to write worse and less safe code than you want.

For example, the lack of enums and sum types means it's hard to represent, safely and efficiently, anything that should be the same type but have different values within a strict set of allowed values. The nearest you get in Go to an enum is:

  type Color int
  const (
    Red Color = iota
    Blue
    Green
  )

Alternatively, can do the same with a string:

  type Color string
  const Red Color = "red"
  // etc.

This gives you some type safety, since a Color requires casting to force an int or string or whatever to become it. But that doesn't give you real safety, since you can do:

  var c Color = Color("fnord")

This comes up whenever you're handling foreign input. JSON unmarshaling, for example. You can override the unmarshalling to add some validation, but it won't solve your other cases; it will always be possible to accidentally accept something bad. Not to mention that the "zero value" of such a value is usually wrong:

  type Color string
  var c color // Empty string, not valid!

A more safe way is to hide the value:

  type Color interface {
    isColor()
  }
  type colorValue string
  func (colorValue) isColor() {}
  var Red Color = colorValue("red") // etc.

Now nobody can create an invalid value, and the zero value is nil, not an invalid enum value. But this is unnecessarily complicated and shouldn't be necessary in a modern language in 2019.

The case of genuine sum types is worse. Your best bet is to use sealed interfaces:

  type Action interface {
    isAction()
  }

  type TurnLeft struct{}
  func (TurnLeft) isAction() {}

  type MoveForward struct{
    Steps int
  }
  func (MoveForward) isAction() {}

There are some downsides. You have to use static analysis tools (go-sumtype is good) to make sure your type switches are exhaustive. You get a performance penalty from having to wrap all values in an interface. And if you're going to serialize or deserialize this (e.g. JSON), you will be writing a whole bunch of logic to read and write such "polymorphic" values.

gen2202• 7 years ago

I know it’s not a proper part of the language, so it might qualify a “hack” solution, but one can get around some of the issues you describe by defining your enums in protobufs, and using/trusting the generated code, no?

It’s not a pretty solution from a language design point of view, but it’s been more than effective for us from an engineering point of view: since we’d need those proto definitions anyway, why bother writing our own?

strken2• 7 years ago

Agree with this. There are couple of observations I'd make, though.

Firstly, "enums" using iota should always be defined as either

    const (
        Red Colour = iota + 1
        Blue
        Green
    )

    const (
        Unknown Colour = iota
        Red
        Green
        Blue
    )

to avoid the zero value problem.

Secondly, and this is a personal preference, I've really enjoyed not having to work with sum types. In practice other programmers seem to use them when a public interface would have been sufficient, and it's convenient to be able to do:

    // original package 
    type Position struct {
        X, Y int
        Rot Rotation
    } 

    type Action interface {
       Apply(Position) 
    }

    type MoveForward struct {
       Steps int
    }
    func (m MoveForward) Apply(p Position) {
        switch p.Rot {
        case Up:
            p.Y += m.Steps
            ... 
        }
    } 

    // second package wrapping the first
    type WarpToPoint struct {
        X, Y int
    }
    func (w WarpToPoint) Apply(p movement.Position) {
        p.X, p.Y = w.X, w.Y
    }

skybrian2• 7 years ago

It probably amounts to the same thing, but I think there's a more pragmatic approach to thinking about safety. A type is a way to remember that validation has already been done. This is true for constants by inspection (code review). For dynamic code, have a validator function that takes unvalidated input and returns a Color or an error, and always use that to create a Color.

That's usually sufficient. Any "cheating" should come up in code review as a suspicious cast to Color. In an audit, you could search for casts to Color.

Safe languages often have unsafe constructs. It's the same principle. The unsafe code is signposted, and you review it.

If you want further encapsulation, another useful trick is to make Color a struct with a private field. It's not usually necessary, though.

Go does have an unfortunate quirk that you can always create a zero value without calling a constructor, so you'll need to make sure a zero Color has meaning. (An interface doesn't really change this because the then the zero value is nil. That's not an improvement over making the zero value mean "black" or "transparent" or "invalid".)

weberc22• 7 years ago

I want to see generics and real enums (I.e., Rust enums, not C/Java enums) added to Go, but as far as it being unsafe or inefficient, these concerns are overblown for many apps. People who levy this criticism are often fine with Python and/or JS for similar categories of applications, even though they are far less safe and less performant than Go. We should be clear when we criticize Go that we’re talking about addressing the last 1% or so of type-related bugs and/or extending the performance ceiling a bit higher. We should also give Go credit for permitting a high degree of safety, performance, and productivity when other languages make you choose one.

lowmagnet• 7 years ago

  type Color struct {
    R, G, B, A byte // IDK
  }
  func (o OtherType) *Color {
    return &Color{R: o.r, B: o.b, G: o.g}
  }
  type Colorer interface {
    func Color() *Color
  }

A colorer would return a color regardless of its type. This is behavior-based interface. I just need a thing that when I call Color(), you get a *Color.

SEJeff2• 7 years ago

For json unmarshalling of structs at least, I've become a pretty big fan of the validator library from the go playground:

github.com/go-playground/validator/v10

It uses struct tags to validate the struct and is quite extensive.

https://godoc.org/gopkg.in/go-playground/validator.v10

gfodor• 7 years ago

When I used to work on PHP, we had a similar appreciation for this, and called it “the joyless programming language” (as a complement)

BurningFrog5• 7 years ago

As someone who thinks readability is the¹ most important quality of source code, that makes me less interested in learning Go.

¹ Yes, even over correctness.

tfha11• 7 years ago

That's really strange to me because I find go to be very readable. There are so few approaches to each of the basic programming building blocks in go that once you have read a moderate amount of idiomatic go, everything else just feels easy.

teunispeters2• 7 years ago

aesthetics are relative, not absolute.

zer013• 7 years ago

I'm firmly in this camp as well. A strong code quality metric is how easily understood something is - we write code in all sorts of states of minds at all hours of the day. If others can read your code and understand it, it means you can too when it's time to extend/modify it. This is also why things like Ruby's over reliance on metaprogramming bugs me - sometimes duplication is fine, and I'd much rather have some duplication than a wrong (or hard to discover) abstraction.

The argument that "all code gets sloppy so let's just have very verbose code from the get-go" is pretty insane to me.

tensor2• 7 years ago

This philosophy is about as far from what I value as it's possible to get. An easily understandable program that doesn't solve the problem is worth absolutely nothing. In fact, if it's code someone is depending on it's probably worse than no code at all. In some applications it could even cost people their lives.

Correctness is a basic starting point. It's the minimum viable offering.

Touche4• 7 years ago

Strong agree. I feel like the opposite is true of the Rust community. I follow a lot of prominent people in Rust and all they tweet about is intricacies of the language and new features/libraries. I'm not sure these people are even building anything, they seem to be "snacking" on the language only.

You don't see people in Go doing this, and it gives the impression that the community is small, but I think they're just building stuff.

steveklabnik11• 7 years ago

People build libraries to solve real problems. Language features need to have proper motivations in order to be accepted; we have rejected more academic features that don’t have direct uses. For example, async/await solved a real pain point for our largest production users, and that’s why everyone has been talking about it.

Sometimes, these connections can be unclear from the outside. For example, there’s a lot of talk about “generic type constructors” and “generic associated types”, which sounds academic. However, it’s something the compiler needs to understand in order to implement a very simple user-facing feature: async functions in traits. From the outside it may look like “oh those folks are out of touch” but it’s directly connected to real user needs.

(As a further aside, these two features are identical, but “generic type constructors” focuses on the academic, and “generic associated types” focuses on the end-user benefit; we changed out terminology here specifically to focus on what users get out of the feature rather than the type theory implications.)

Furthermore, some people tweeting about things they’re excited about does also not preclude others who are heads down all the time. You wouldn’t see them for the same reasons, they’re not tweeting.

These kinds of swipes against other languages lower the discourse and promote animosity when there really should be none. I’d encourage you to consider if these kinds of attitudes help bring about more people who are interested in building cool things, or fan flame wars that distract folks from doing exactly that. Every minute spent arguing over whose language is better is also a distraction from building cool things as well.

pcwalton4• 7 years ago

I follow a lot of prominent people in Rust and all they tweet about is intricacies of the language and new features/libraries. I'm not sure these people are even building anything, they seem to be "snacking" on the language only.

This is obviously false. How do you square that with all the Rust code we've shipped in Firefox, for example? I build things in Rust every day.

cgag• 7 years ago

I used to be a Haskell type and now enjoy Go greatly for this reason.

There was a thread on the Rust reddit where someone was asking how to do something relatively simple using some elaborate combination of map/reduce/filter/continuations/who-knows-what, and someone said "just use a for loop", and the OP was enlightened.

People don't know how great the burden of trying to model their problem to fit a fancy language is until it's gone. I didn't.

I want generics and sum types, but I miss them less than I would have predicted.

neandrake• 7 years ago

I’ve seen a similar effect in myself and others at work but I don’t think it’s only a symptom of the language. After we switched from java 6 to 8 a handful of devs including myself went overboard modeling problems to be solved with streams API when it wasn’t necessary. These days it’s leveled out and use of the api is on a much more appropriate level.

I think this is a process of learning. While learning a new tool you start to model problems so you can practice, even though not necessary. Once comfortable you realize when to use the tool and when not.

steveklabnik11• 7 years ago

This topic is more complicated than “for loops good, iterators bad.” I absolutely agree there’s a time and place for both; that’s why we included both in the language. But sometimes, iterators have less bounds checks than for loops do, so they can be more performant than a loop. Sometimes they’re the same. Depending on what you’re looking for, the details of what you’re doing, and your literacy with various combinations, different ways of expressing the same idea can be good. It all just dependents.

(Also, rust’s for loops are implemented in terms of iterators; they’re actually the more primitive construction in a language sense; a while loop with the Iterator library API.)

derefr5• 7 years ago

Sure, and then you ask how to fold over a tree or an infinite stream, and the answer is to reimplement all the HOFs from the “fancy languages” in a type-specific way, because otherwise every user of your ADT is having to write not just a for-loop, but an entire push-down automata.

I also write Go code without missing generics, but that’s because I’m also fluent in other languages, and tend to use those when I want something ill-suited to Go, rather than trying to force Go into that shape.

AnimalMuppet4• 7 years ago

I used to be a Haskell type...

Pun intended? If so, nicely done.

codygman3• 7 years ago

There was a thread on the Rust reddit where someone was asking how to do something relatively simple using some elaborate combination of map/reduce/filter/continuations/who-knows-what, and someone said "just use a for loop", and the OP was enlightened.

I think it's hard to discern between "that overly-complex functional and declarative definition is unfamiliar to me" and "that is way over-complicated and should just use a for loop".

Any chance you can track down that example so others can compare the two examples as well?

ketralnis• 7 years ago

“Some internet person did it wrong once [in my view]” isn’t really an indictment of the whole thing

matheusmoreira• 7 years ago

Most of it is wasted intellectual effort.

It is highly stimulating intellectual effort though. Sometimes I sit down and spend hours just thinking about the best way to do something. It's some kind of philosophy: the abstractions we create reflect the way we understand things. To write good code, we must study the computer science and the problem domain itself.

Without this, it's just boring mechanical work. Once the project has been figured out it ceases to be interesting. Some of my projects are unfinished because I can't justify spending more time on them even though I know exactly what must be done.

stiglitz• 7 years ago

Yes, this! If you walk slow, then you walk in a straight line to the destination.

SEJeff2• 7 years ago

I'm just going to leave a direct quote from Rob Pike:

""" The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. """

I read that as Rob Pike saying he wrote go for idiots google hires to write.

https://bravenewgeek.com/go-is-unapologetically-flawed-heres...

_ph_9• 7 years ago

Not idiots, but young coders who don't have 10-20 years of experience, who are required to write good code pretty quickly. So you want a language which is not only to quickly pick up but also quickly to learn to a point at which you are writing good programs.

andrepd• 7 years ago

Many programmers using a more "clever" language like haskell will spend a lot of time trying to make code more readable, searching for the right abstraction. Most of it is wasted intellectual effort.

I rather disagree that making your code readable and maintainable is a waste of effort.

Paddy3118• 7 years ago

Code is helped by being readable.

Saying your code is going to "look like sh£t anyway" seems rather defeatist, and an _excuse_ to write unreadable code.

oefrha7• 7 years ago

Just Enough Batteries Included

This is just an anecdote, but recently I decided to give golang a spin, and wrote a small command line utility in it.

I won’t tell you the pain of trying to find an argument parser with support for GNU-style long options. I suppose that’s something I should write myself rather than use the standard library or find a third party library, because simplicity. /s Edit: folks posted helpful suggestions, I take this paragraph back.

Instead, let’s talk about something basic, regexp. Turns out golang’s regexp package supports named capture groups, but if you want to actually refer to the capture groups by names, you need to manually pair FindStringSubmatch result with SubexpNames in a loop. Can’t make this shit up. Seriously, what’s the point of named capture groups if you can’t refer to the groups by names? If this is just enough battery included, your expectations might be a tad too low.

dev_dull2• 7 years ago

For CLI it’s true to the Go mantra. If the flags library is “good enough” why not just use it and avoid being fancy?

Besides, isn’t it feasible someone might confuse long and short options? “Is -d and —delete the same, or is -d —debug??” KISS even if it’s annoying.

As for loops, I know that they’re generally more common in Go. Another example is finding if an element exists in a slice. Most of the implementations is this stuff is just a loop under the hood in the end.

From a Java background it was strange to me because I’m used to dealing with classes and there’s always a method for this or that...

oefrha7• 7 years ago

For CLI it’s true to the Go mantra. If the flags library is “good enough” why not just use it and avoid being fancy?

Users of a command line utility ultimately don’t care what language it’s written in; having a familiar interface is a much more important goal. Since the vast majority of Linux utilities these days use GNU-style rather than Unix-style long options, it stands to reason that the latter is a better choice for users. (There are also technical advantages I won’t get into.) I know Rob Pike probably isn’t a fan given his background, but why not give developers the choice to build what they want to build, instead of shoehorning them into something they dislike? What’s the point of being opinionated here? (Edit: Sorry, didn’t mean to imply that the standard library ought to have it; however, I do find it strange that in the ten years of golang the community didn’t bother to come up with a reasonably good library for it.)

Btw, flags is very primitive and can hardly handle anything complex, even if you accept the Unix-style.

nickcw2• 7 years ago

For gnu style long options you want: https://github.com/spf13/pflag

It is a drop in replacement for the built in flag library.

I ususally start out with the built in flag library and migrate to pflag when things get a bit more complicated.

oefrha7• 7 years ago

Thanks, not sure why I missed this. Probably should have used this instead of settling on urfave/cli. I take back some of what I said.

andrewksl• 7 years ago

I've found that Cobra[0] does pretty much everything I've needed via a reasonable API, but I'll admin I'm not fussy about CLI utility behavior.

[0] https://github.com/spf13/cobra

Thaxll3• 7 years ago

This is what you're looking for: https://github.com/spf13/cobra They are many libs that do that, you probably didn't search very long ...

oefrha7• 7 years ago

This is one of the options I evaluated but rejected.

pmoriarty3• 7 years ago

Is Go simple?

It looks positively complex compared to Scheme.

13415• 7 years ago

I have a direct comparison, since I've been programming substantial amounts of code in both languages. I'd say that Go is much simpler in practice. Think about all those classical functional LISP exercises to recursively manipulate lists such as reverse a list, return the nth element, flatten lists, combine lists in various ways, and so on. I doubt you can write good Scheme code without having done those exercises at least once in your life. And at least for complete beginners these exercises are not easy.

There is no equivalent to this in the Go world. Of course, you could do it, you can do functional programming in any language. It's just not usual. Paradigmatic Go code is simple, imperative style with a lot of mutation. You only need to learn how structures and interfaces work and your good to go.

pmoriarty3• 7 years ago

"Think about all those classical functional LISP exercises to recursively manipulate lists such as reverse a list, return the nth element, flatten lists, combine lists in various ways, and so on. I doubt you can write good Scheme code without having done those exercises at least once in your life. And at least for complete beginners these exercises are not easy."

In practice, you'd just use a library function for pretty much all of those.

Nobody writes those from scratch in Lisp or Scheme except as an exercise.

Also, once you do get the hang of it, recursion is a much simpler and more natural way of expressing many algorithms. But it too is not necessary in Lisp or Scheme, and you're welcome to write the iterative equivalent, if that's what floats your boat.

As for writing in an imperative vs functional style, I personally find the latter simpler and more reliable. But nobody forces you to write in a functional style in Lisp or Scheme. They're both multi-paradigm languages, and you can write in an imperative style in either, if you prefer.

matthewmacleod5• 7 years ago

Okay, so there's definitely simplicity. I agree that this is in many ways a nice change from some of the more popular languages, which can get a bit complex and heavy, with a focus on features that are nice in isolation but add up to a surprisingly difficult architecture to comprehend at the global level. I just don't think Go gets the balance right.

There are some parts of the language that are such a joy to use – C interop is simple and elegant, the concurrency story is great, the standard library is great, and in contrast to some other people, I think the error handling is also a nice example of simple and effective design. The wider tooling system is decently usable (with the exception of gofmt, as mentioned in the article, which I think is the single best tool I've ever used in any language).

But "simplicity" in Go-land seems sometimes to be the enemy of expressiveness. The lack of abstractions over operations like filtering, mapping, or removing items from a collection is incredibly irritating for such a common operation – instead of immediately obvious actions, there are tedious manual loops where I end up having to read like 10 lines of code to figure out "oh this just removes something from a list". The use of zero values is a crime against nature. The type system is shameful in practice compared to other modern languages, with so much code just being "just slap an interface{} in there and we can all pretend this isn't a disaster waiting to happen". It feels like such a lost opportunity to exploit a richer type system to eliminate whole classes of common errors (which are predictably the ones I keep making in Go code.)

I guess it's frustrating that a language—which is relatively well-designed and intended to be simple—too often makes things more complicated overall by making fallible humans do things that computers are better and more reliable at. I'll keep using it, because it fills a really nice niche that no other language is quite suitable for. But I'll keep being a bit annoyed about it, too.

why-el• 7 years ago

I agree with you on most points, and they are working hard to fix the generics issue in a way that does not make you lose all the nice things you mentioned. The only part I didn't get is:

The use of zero values is a crime against nature

Can you elaborate?

crimsonalucard7• 7 years ago

Generics is only part of the issue. Go has a crippled type system.

Json in go cannot be represented as a type and also is not type safe. This is 100 percent because go is missing a basic type primitive.

Json contrary to what many people think is not untyped. Json is represented by a recursive sum type which go has no ability to represent.

I think what caused this issue is more because the designers of go are more systems people rather than language theorists.

matthewmacleod5• 7 years ago

This one is specifically the assumed values of some types when declared in a struct or variable. Like, a struct with a string field gets an empty string value by default. I appreciate the reason for it; it just jars horribly with my expectations.

The worst offender is `Time` – to quote from the documentation:

"The zero value of type Time is January 1, year 1, 00:00:00.000000000 UTC. As this time is unlikely to come up in practice, the IsZero method gives a simple way of detecting a time that has not been initialized explicitly."

That seems to be an absolutely baffling decision.

cle2• 7 years ago

I don’t know what the Go designers think about this, but I can at least appreciate the tradeoffs of not having map/filter/etc. Memory allocations remain clear and explicit, errors are handled consistently, concurrency is explicit, and it dramatically reduces the urge to write long chains of over-complicated functional operations.

Sometimes I run into a situation where I’m like “Sigh, filter would have been nice here.” But it’s pretty rare. On the other hand, ”clever” programmers love to make incomprehensible messes out of functional constructs.

steveklabnik11• 7 years ago

These properties depend on the language; iterators do not have to allocate, can still expose error conditions, and make concurrency explicit.

I think this is sometimes why it’s so hard to compare and contrast languages; even surface level features in two different languages can have two very different underlying implementations, which can mean you may like a feature in one language and dislike it in another.

matthewmacleod5• 7 years ago

That is the justification I usually hear, but I don't buy it. Like, 99+% of the time, I want to use these kinds of operations to manipulate lists which are orders of magnitude away from anything even approaching a scalability issue. I just don't care about memory allocations when trying to manipulate something like, say, a list of active users in a real-time chat or something. And often I find that the mess coming out of having to implement those same operations without expressive constructs is worse than the messes that people can create (though I grant I've seen those errors too).

This hints at some of the ideas behind Go – it's designed, perhaps, for Google-scale software. This is dealing with problems (like e.g. memory allocation) that I don't have when working with most datasets I'm likely to need. Maybe we just have to accept that.

Thaxll3• 7 years ago

I don't think I used interface{} in the last 2 years of using Go, the only case was unknown json object that went into map[string]interface{} that's it.

Rotareti2• 7 years ago

C interop is simple and elegant

C interop in go is super slow: https://github.com/dyu/ffi-overhead

_ph_9• 7 years ago

Which isn't a contratiction to the statement, that for the programmer the C interop is simple and elegant. Which I think mostly it is. The slowness comes from what goes on behind the szenes. Mostly the different way of handling stacks between Go and C creates quite some effort when calling into C and returning. Those languages, which use "C compatible" stack and register layouts get much faster C calling. That doesn't mean, they can call C as easily.

So calling C from Go for small functions isn't a performance gain. You should write those in Go. The calling of C is great for linking against larger libraries, which cannot be ported to Go. And for that it works nicely and is fast enough.

masklinn6• 7 years ago

Note they never say it is fast, or good.

enraged_camel• 7 years ago

My first car was a 2002 Honda Civic, bottom of the line. Aside from automatic transmission, everything - doors, locks, and so on - was manual. It didn't have a CD player or even A/C. You might say it was a simple car.

At first I loved its simplicity. It did its basic function (getting me from one place to another) quite well. I drove it only occasionally, as I was in college, and it didn't fail me in any way.

Then I graduated and got a job, and started commuting. Once I found myself driving that car every single day, I started to resent its simplicity. In a few occasions it bit me in the ass - one time, my passenger forgot to lock their door after getting out, and overnight someone got in and rummaged through the car and stole a bunch of stuff. That would not have happened if it had automatic locks!

That's how I feel about Go: if you're writing simple microservices occasionally, then it's a good language. But as usage becomes more frequent and serious, the simplicity starts to seriously hold one back. I understand the reasons behind that simplicity, but, as with all things, too much of a good thing can in fact be bad.

b0rsuk• 7 years ago

In Go's case, it's too early to tell how it scales. It has the opposite approach to readability as Perl.

I wonder if Go ends up sharing Perl's fate. Two languages that make people feel very productive, but don't seem to scale very well.

rollcat• 7 years ago

Define "scale"... Large codebases? Teams? Long-lived projects? So far Go looks excellent at all of these

bfrog3• 7 years ago

Go is so simple that there are dozens of code generators and project dependency management solutions. Yet people live to espouse it's simplicity. It's simple like C in that regard, you have to roll your own solutions to avoid copy pasta hell if you want type safety and sane project management. The real mistake though is the lack of an Option type. The inability to express optional differently from passing references efficiently is a large test case burden.

hu33• 7 years ago

Based on what you wrote I can't help but think you haven't used Go extensively or at all.

Code generators are rarely used and Go has an official built-in dependency management tool: go modules.

https://blog.golang.org/using-go-modules

bfrog3• 7 years ago

I wrote 100kloc rest service using go, so actually I do know a thing or two.

Granted this was 4 or 5 years ago so perhaps things have improved.

floatboth• 7 years ago

https://twitter.com/vertexclique/status/1194902103929569280

sosodev• 7 years ago

My feelings on Go are pretty mixed. I think a significant portion of software can be described inside the box that you’re given with Go but if you enter even moderately complicated territory it becomes a shit show.

I’ve had the displeasure of working on a pretty complicated Go project at work and it’s given me plenty of counters to what OP is saying.

First, Go’s dependency management has been terrible and inconsistent for years. Dependencies started very loose and without any versioning at all and I was bitten many times by this mostly because developers used the looseness of Go get to consume repositories that were never meant to be public APIs and without versioning those repositories had zero guarantees of compatibility.

The community eventually noticed this was a problem and vendoring was introduced but the community and Go itself flip flopped on a “correct” solution for ages which ultimately led to even more package incompatibility. Now we’ve got modules which is a step in the right direction but it’s going to take quite some time for all of the Go projects to implement it correctly. Modules have been nothing but a pain in the arse for us because our Go project has a lot of dependencies.

Another thing I hate is the idea that people spread that Go’s simplicity leads all developers to write simple, clean code. Some developers, I’ve noticed, pine for abstraction like moths towards a lightbulb. In Go abstraction can be very painful to do elegantly and I’ve seen some nightmares where developers have tried. Using reflection on interfaces produces some of the shittiest code I’ve seen in a long time and yet I’ve seen it repeatedly by different developers in different organizations.

I must not be the only one who has noticed these issues because the creator of Go himself made the Go Proverbs (https://go-proverbs.github.io/) which include things like “interface is never clear” and “reflection is never clear”.

Okay, I’m going to stop ranting now but I seriously don’t get the hard-on for Go. I think I kinda got it before I used it professionally.

bob1029• 7 years ago

This is exactly the take I have been expecting to unfold for a lot of developers regarding Go. It is a very compelling language to get started with because it is so reductionist compared to alternatives like Java and C#. This makes learning it very straightforward, to the extent that you would almost want to die defending the language that is feeding your dopamine loop.

But, one day you might wake up and realize it was all a fantasy. That is, if you ever step foot into a shop where you are expected to build a line-of-business application with sufficiently-complex business entities and rules. All of your ideas about how wonderful Go is will fly directly out the window. Sure, you can eventually implement anything in Go. It is Turing complete after all. But, that isn't to say you'll have enough time to implement it. Go advocates will happily dismiss the value of things like LINQ, generics & reflection until they are faced with a reality where tools like these are the most productive way get a feature into production before 2020 hits. If you open your mind up to the possibility of using different (god forbid, unique) approaches to solve problems, you might then find that Go does not even offer the best implementation of these alternative language features.

tfha11• 7 years ago

This is not my experience at all. We've spent the past few years building a multi-hundred thousand line of code distributed system in go and have found that sticking to idiomatic go has been very beneficial in building the thing successfully.

K0SM0S• 7 years ago

Everything you describe screams to me of choosing the wrong tool for the job.

Go certainly isn't a general all-around fits-all tool, it's a rather specific and opinionated approach. It's almost a given than Go alone can't solve 100% of most company's needs, this is not Js or Python or C#.

So trying to shoehorn a classic OOP or functional paradigm into Go is just asking for trouble, and no the language won't change to become a clone of another (what would be the point?)

If generics and reflection are core to your solution, there are languages for that. Don't make your life harder. Not every codebase needs to be in one language only.

alfalfasprout2• 7 years ago

Also have worked in some pretty massive Go codebases. It's about writing the language idiomatically. If you're super concerned with trying to mimic Java-style abstraction and shoe-horning OOP into Go you're going to have an awful time.

If anything, I've found shipping code to be WAY faster in Go than Java due to the much cleaner build system and approach to testing.

The one main area where Go struggles is in math-heavy code where the lack of generics or algebraic types means duplication or code-gen.

But you're right. It's not the be all end all of languages. If anything, it's just a much better substitute for the use cases where Java traditionally excels.

aws_ls• 7 years ago

Docker and Kubernetes are not real world enough for you?

I have ported stuff from Java to Go, for my long running app, and very happy.

Also at a client place, over the past year, I developed stuff in Python and Go, where Java was traditionally chosen, and it led to faster execution times, and stable microservices.

ausjke2• 7 years ago

C is popular also partially due to its simplicity by design. Javascript fatigue is caused by its 'complexity(imperfectness)' in design, but it took a good spot by accident however bad it was designed.

tetha• 7 years ago

After some work with go, I wouldn't call it simplicity that much. Simplicity has too many implications and expectations and by now, I'd call simplicity context dependent. In the right context, spring boot can simplify backend code, in the right context, libraries like panda can simplify data crunching algorithms in python. And even as this thread shows, "simplicity" immediately blows up into discussions between the different kinds of simplicity.

I rather tend to call what go does regularity and the language design of go does promote said regularity. Regularity in this context means: Go codebases and lots of go code tends to follow very similar patterns.

And this in turn makes it simple to digest even complex code bases, at least to me. A go codebase might just contain more code, but chasing some listener on the result of another listener through multiple annotations and config files in a java codebase... yeh.

And on top of that, this kind of regularity, as well as the kinda small set of libraries to do something makes it easier to get started with the language in my experience, especially for people who aren't seasoned developers.

FpUser3• 7 years ago

Without digging too much into syntax, issue of GC there is a simple ani-feature in go:

I can not create and control native threads. While Goroutines are nice and needed feature some of my software simply can not function without the native threads. Hence Go is no go for me.

api2• 7 years ago

When I write in Go I spend almost all my energy thinking about the thing I am writing, not the language. It's a breath of fresh air, like modern C with a safety lock on the footgun.

I learned how to code "thin" low abstraction C++ and un-clever dynamic code in languages like Ruby and JS as I matured as a programmer, but it takes discipline. When I was younger I fell like so many others into the trap of showing off my command of languages instead of showing off my command of algorithms and ability to solve problems elegantly.

I don't find Go that ugly, especially with standard 'gofmt' formatting. It's so simple the brain learns to parse it as effortlessly as the compiler.

The brilliance of a program is its results / its complexity, with the greatest code ever written being simultaneously the simplest and most impactful.

Go makes that maturity natural and easy. I think it's a great influence on the programming zeitgeist as well as a nice language.

Haven't tried Rust yet but my impression is that its somewhere between C++ and Go. Can anyone comment on Rust's cognitive load?

steveklabnik11• 7 years ago

Rust has an interesting relationship with cognitive load. At first, it is fairly high. But then, at some point, stuff just clicks and it drops dramatically. How long that takes depends on the person, they’re background, how much support they have, etc. As a random anecdote, we had a team at work who started a Rust project, and it took them a month or two to get going. Now they’re sailing quite smoothly. (We have other teams as well but I’m only really familiar with the process for one of them.)

The reason for this is that you have to learn to work with the compiler and its rules. At first, that’s a struggle. But later, it’s just helpful, and you have to think about things way less because the compiler is helping you keep track of them. It’s like a pair programmer.

tfha11• 7 years ago

Have you used a lot of go? I'm a big fan of rust and definitely like rust devs and the rust community, but I find that people haven't used go enough to "get" it don't really understand just how much it can take away from cognitive load.

Rust and go are not really comparable in this regard, even if rust is much better than most people realize. There are too many ways to approach a problem in rust.

That said, definitely there are plenty of places where rust is a much better language choice than go

api2• 7 years ago

That sounds promising. Reminds me of C++ RAII memory management patterns.

takeda4• 7 years ago

It's nothing like C, it is closer to Pascal or actually Algol.

cygned• 7 years ago

The biggest pain point I have is the lack of nil-able vars. Maybe it doesn’t make sense in term of type systems, maybe it is that way for reasons of reliability - but in practice it’s a pain to work with JSON APIs or NULLable fields in DMBS’ if you come from a language where these things just work.

erikpukinskis• 7 years ago

I’m curious, has anyone here had an actual need for genetics in production code? I mean, like you actually have an uncountable or at least large number of types that you want to push through a generic mechanism?

I use “generics” in TypeScript but it’s always a very small number of types: usually two, maybe up to 10...

There’s no reason I couldn’t do that without generics, just by writing a couple line plugin for each type that converts it to a common representation.

I’m not convinced that’s even strictly worse than generics from a usability perspective.

snagglegaggle• 7 years ago

Yeah. The usual case is a container type or composing with a container type, but there are many "algebraic" types that you may wish to use if they could accept types to parametrize them over.

vmchale• 7 years ago

I wrote a blog post about an example that came up for me: http://blog.vmchale.com/article/ats-templates

agumonkey• 7 years ago

There's something about russ cox writings that exemplifies go 'cleanliness', they engineer stuff to make a task clearly, nicely and nothing more.

People complain about the lack of generics but I wonder if they didn't allow it to avoid an abstraction explosion, at the cost of redudant/copypasting.

andy_ppp2• 7 years ago

If it so simple why are the developer ergonomics so bad, if err != nil is a mess (Elixir has a with clause that would be useful), everything points to github master and module management is still extremely basic. The error messages are absolutely atrocious compared with something like elm or even python or Typescript, the type safety is a lie fairly often and you can still write programs which crash due to that. Then there are go channels which are kind of cool until you realise they can very easily lead to race conditions and a version of the actor model would have been much better. I could go on but go is like a nicer C rather than a modern language people should be building web services in.

chrisseaton• 7 years ago

Isn’t the actor model just as racy as channels? Race conditions everywhere is one of the big downsides of actors compared to other concurrency models.

andy_ppp2• 7 years ago

Within any distributed system you can have races but in Golang the mutable nature of channels makes this almost impossible to reason about (in my experience most people use mutex’s in go unless doing something extremely simple).

ryan_glass• 7 years ago

This article really, really makes me want to give Go a shot - more than anything I've read about the language before.

takeda4• 7 years ago

You should, you either will love it or hate it. I personally don't like it, but from your response it sounds like you might have a different opinion.

dana321• 7 years ago

Some great points about go:

If you don't use it, remove it (compiler checks to see if a variable / module import is actually used)

The real pleasure in go vs c/c++ is compiling / linking is easy with the new go modules support, multi-platform out of the box. Kinda like cargo in rust. Kinda.

Downside is.. C/C++ modules are 2nd class citizens that can slow your whole code down.. Conversion is much better, but usually someone has done it yet.. sqlite needs a go port.

I think of go as an advanced assembly language with some c-like idioms and a powerful runtime to handle processor thread scheduling.

pstuart• 7 years ago

Unfortunately no recent activity, but this comes to mind: https://github.com/elliotchance/c2go

Animats• 7 years ago

I tend to agree. I was a big fan of Rust at first, but they put in too much stuff. Borrowing is brilliant. The semi-functional programming features, not so much.

Go was created so Google people could write server-side stuff in something less brittle than C++. It's a good match for that. The library stability is a good thing. Those are libraries Google uses internally, so you know they're executing millions of transactions a second somewhere. The error cases have been encountered already.

zozbot2343• 7 years ago

The "semi-functional" programming features have always been a part of Rust - some of them have even been removed since, such as typestate. The borrow checker as we know it was actually added quite a bit afterwards.

verdagon• 7 years ago

Fascinating! I thought Rust was built around the borrow checker. Did Rust ensure memory safety back then? Back then, was their goal to make a more modern C++ with functional influence maybe?

Keats• 7 years ago

In my opinion, of recent languages, Go has the sanest versioning and dependency story. I haven’t had a single breakage due to an update in Go.

I don't know about that. I've tried to build 3 Go applications in the last couple of years and none worked because some of their dependencies had breaking changes in master. Hoping that someone doesn't push a breaking change on master, doesn't change username or doesn't delete their repo doesn't seem very sane to me. At least vendoring is well supported.

jeffrallen• 7 years ago

Go is simple enough that your idiot co-workers can understand it. (Remember: They think the same about you, and they are right.)

apatheticonion• 7 years ago

It's important to remember that Go isn't by itself enough to write quality software.

Developers must arm themselves with established and tested software design patterns to utilize the language effectively.

The same goes for other languages as well, however Go's emphasis on providing a tiny toolset amplifies the benefits/consequences.

... Also we need generics

edgarvm• 7 years ago

Go is not a simple language, it lacks of features.

martincmartin• 7 years ago

In woodworking, the only tool you need is a hammer and chisel. With enough effort, you can make a decent table leg, you don't need a lathe.

But if you do it several times, you think "if I just invest time into learning the lathe, I can save a lot more time when making table legs. In fact, I might be able to make a more complicated table, since the time and effort saved when making the legs can now be spent on other things."

millstone3• 7 years ago

I don't know Go, but from my outsider's perspective it doesn't look simple!

For example compare inserting into a list in Python:

    list.insert(index, obj)

with apparently idiomatic Go:

    a = append(a[:i], append([]T{x}, a[i:]...)...)

Or compare Python's `list.reverse()` to Go's recommendation:

    for i := len(a)/2-1; i >= 0; i-- {
        opp := len(a)-1-i
        a[i], a[opp] = a[opp], a[i]
    }

This seems quite error prone.

Idiomatic Go taken from https://github.com/golang/go/wiki/SliceTricks

andrenth• 7 years ago

One of the things to keep in mind with Go is that in general it doesn’t try to hide possibly costly operations under simple to use interface.

So in your example, append may need to allocate, and the fact that it returns a new pointer makes that clear.

For the second example, you could use sort.Reverse, but the loop makes the cost of the operation clear.

xyzzy_plugh• 7 years ago

Additionally, at least in my experience, you don't ever want to just "reverse a list", you want to do something, like print it in a certain order. Writing the loops yourself makes it simpler to accomplish the task at hand, I find.

CAMLORN• 7 years ago

In the insert case call the function InsertWithAllocqation, and also provide an Insert variant that doesn't allocate but can fail. In the reversing case, call the function ReverseInPlace, then require the user to make a copy either before or after. This gets you the same goal--not hiding the costly allocation--while also making it convenient to use and removing the possibility of mistakes.

The real problem is that without generics, such functions actually have to be written in the same fashion as sorting where you provide a function for reading and writing both, as opposed to just working--so the "simple" loops which are indeed error prone actually become less code, and we all use them instead. I highly, highly doubt even the best Google programmer will always get the boundary condition on that reverse a list loop right especially in an emergency or at 3 AM, and this is a very simple case where Go just can't abstract on par with anything-with-generics.

But my point is that you can meet the goal of not hiding operations just with good naming, if that's what you consider a terminal value of good pl design, and don't need to forego abstraction to do it.

azth2• 7 years ago

golang is too simple. Real projects are complex, and having a simplistic (dumb) language just pushes complexity to the programmer instead of having it built in to the language and compiler.

There is a balance to reach, and languages like Java do a much better job at this than golang.

ryanmccullagh• 7 years ago

I _hate_ Go’s encouragement and use of single letter variable names.

photon_lines• 7 years ago

If anyone is interested in learning Go, I made a relatively simple web-server with demo apps which you can find here: https://github.com/photonlines/Go-Web-Server

I don't agree with other people calling the language simple. It makes doing something like building a web-server from scratch very simple, but the actual language syntax and expressiveness is lacking in my opinion.

vpmpaul• 7 years ago

Follow up article in months..

Go's Simplicity is its weakness for XXX thing.

I find these constant take one aspect of a language and paint the world with it to be unhelpful and distracting. However based on the comment section HN eats it up, no wonder people keep writing them. Its like Instagram for nerds I guess.

The Value in Go’s Simplicity

Related Stories