I Love Go; I Hate Go
dtrace.org
dtrace.org
The fact that there is not a compiler flag to disable this behavior, and that the core team is opposed to adding such a flag (https://golang.org/doc/faq#unused_variables_and_imports), is simply ridiculous and makes programming in Go a real pain in the ass.
I can't think of any other language that does this.
> There are two phases: active development and release
> engineering.
A program doesn't suffer from that. Forcing these things to be showstoppers makes sure they NEVER become a problem, and the "cost" (in terms of the developer) is pretty small in the grand scheme of things.
Adding a _ to the front of an import is not the correct way to get around this "problem" during development, commenting out the whole import is the correct way. That way if you forget, it's not in your code anywhere (as it shouldn't be since it isn't used).
The underscore system is meant only to be used when you need to import for side effects (something that i've never actually needed to use).
If you can't even agree among yourselves what is the right thing to do then I think that this is another sign that this go behaviour is not the proper solution.
If you comment out code that uses an import, comment out the import too. It's not just the recommended way, it's the only logical way of doing things.
And how is having 2 opinions on how to do something a sign that this is not the proper solution? People still can't agree on tabs vs spaces (and probably never will be able to), that doesn't mean that all programming isn't a proper solution. There are also people that think using version control is a bad idea, but that doesn't mean that all version control is broken...
That's a very negative way of saying "that's not my personal behavioral preference"
> There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter.
Many of Go's idiosyncrasies are for code readability and maintainability, which is very much a part of active development. The point being to mitigate the likelihood you end up with spaghetti code (yes, I know you ultimately end up with code quality only as good as the developer, but some languages do still make the process easier than others)
> If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.
Except it does though, since that's the very behaviour you're complaining about.
>That's a very negative way of saying "that's not my personal behavioral preference"
In my experience, Stockholm syndrome is not used to describe personal behavioral preferences, but rather (unexpected) transitions between such preferences from the negative to the positive.
In the grandparent's own words:
>>> i was shocked by that at first too. Then I came to love it.
Stockholm syndrome refers is a victim forming emotional bonding with his or her captor[1]. Which would mean in instances like this, where the "captor" is a voluntary choice of language, the term is used akin to "masochism" (albeit without the sexual element). In essence, saying "the pleasure from use feature x is derived from the pain of using feature x".
Which is why I commented that "Stockholm syndrome" is a needlessly colourful way if saying "I disagree".
No, the meaning was: if someone cannot handle unused things, that someone is screwed. Go will not save him in other aspects which require a little bit of discipline and are not checked by the compiler.
So what you're saying is, there are two kinds of people—those who don't need the feature, and those for whom the feature isn't sufficient?
My personal view on this is that warning the user should be enough. The compiler designer is basically saying: I can't trust developers to fix warnings and it is my duty to protect them from their own laziness by enforcing a certain way of working. This apparently attracts a certain kind of people. I prefer to be the one telling the compiler what to do, instead of the reverse.
I'm with you there, I just was making a snarky comment :-)
The end result of Go's opinion on warnings is that you know a certain class of bugs in not present anywhere in both your code and all of your dependencies. While it's true that people and teams that follow the best practices around warnings also tend to follow the best practices for other things but there is no guarantee for the ecosystem in a language that allows warnings, and no project lives in a vacuum.
The Go compiler could simply include a bit in the resulting binary/library that indicates whether or not it was built with the "disable-unused-variable-error" flag. If you're using a library that was built with that flag the compiler can simply refuse to compile your code without that flag, forcing you to acknowledge the problem head-on.
The result will be that everyone compiles with that flag on so they can use the libraries they want/need. It's in fact actively worse than just allowing warnings. At least if you allow warnings that way you aren't forced to lower your own codes protection just because one of your dependencies does.
So here's a language feature that you don't like. Other people don't like it and then, after they get more experience, decide they like it after all. And you call it Stockholm syndrome? By saying that, you're asserting that there is no possibility that the feature could possibly be anything other than harmful. That's... pretty arrogant, actually. Both the language designers and the users who like it are objectively wrong, and you're right?
Look, you don't like it. That's fine. It doesn't work with the way you like to develop. That's fine, too. But your assertion is that it is worse than useless for all users, and that's a bit more than you have the knowledge to assert.
For example, most JS linters do that check and as a general rule, the build servers would reject the commit when the linter complains. I actually have a (very hacky) plugin to ESLint that automatically removes unused variables before `hg push`. It's totally not optimal, as in, you can still run/compile/transpile/whateverify the code with default options, but a language with no backwards compatibility worries can just add a flag to override strict checks to make a developers life easier, can't it?
I understand not implementing something that perhaps may not fit the language well or is so complicated that it really needs a lot of thought (read: generics). But this decision seems to be dogmatic at best.
I have the exact love/hate relationship with Go as the author of the article.
One under-appreciated consequence is that this policy limits Go to one implementation. Say I write an alternative implementation of Go, that has a different "unreachable code" detector. If I issue errors on new cases, then I'm incompatible with lots of existing Go code. If I fail to issue errors, then code developed against me may be incompatible with the standard Go. The effect is to suppress alternative implementations.
Better to just put my smarts into a linter, which is then just reinventing compiler warnings under a different guise.
I already mentioned that case. To be more clear: Let it not build with default options. Make it not `go get`able.
Let me develop first, and not force me to optimize prematurely.
I'd argue that cleaning unused code as you work isn't optimisation. It's a part of the refactoring process of development which is something that must happen during the main development phase.
But arguments for and against aside, most developers don't see these kinds of compiler errors that often as you'd generally be commenting out unwanted code while you're prototyping. The biggest annoyance is easily the imports and pragmatically that still takes up such an insignificant amount of effort when compared with the overall time spent writing code in any particular language. Which is why many Go advocates are willing to put up with it.
How is it refactoring if my code never builds in the first place?
> pragmatically that still takes up such an insignificant amount of effort when compared with the overall time spent writing code in any particular language. Which is why many Go advocates are willing to put up with it.
It's not a time problem. It's a focus problem. I'm working on something and then out of nowhere, receive compilation errors, which aren't urgent at all, but they distract me anyway. Even if this were indeed a very small problem, I still don't see why something most people see as a problem is pushed down the developers throat with false, dogmatic reasoning. Don't get me wrong: I have huge respect to the people who created go. I just don't like when people defend all the choices they made as "one true way".
Why would you be typing in imports that you've never used? I guess that could happen, but the more likely scenario you had used them at some point, even if just briefly, and then you're refactoring the code.
> It's not a time problem. It's a focus problem. I'm working on something and then out of nowhere, receive compilation errors, [...] pushed down the developers throat with false, dogmatic reasoning
Please don't be so melodramatic. It doesn't happen "out of nowhere" - you've purposely requested the compiler runs. And if you're compiling then you're doing so to either test your code compiles or test it runs - in either case your focus has already intentionally shifted from writing code to testing and debugging it.
> Don't get me wrong: I have huge respect to the people who created go. I just don't like when people defend all the choices they made as "one true way".
I'm not defending it. I'm saying people are being melodramatic about the actual inconvenience it causes. In all of the years I've been writing Go, I think I've spent just as much time coding around that annoyance than I've spent in this thread chatting about it. The difference being, occasionally that annoyance is useful where as the internet arguments about it literally serves no benefit to anyone.
No, I'm compiling to see if my changes still allow the tests to pass. This is a huge problem if you're doing TDD. The main argument you make is that it's not such a big problem and I think the number of people complaining says otherwise. Or maybe we developers just like being melodramatic. I honestly can't tell. Maybe what triggers such passion is go being very close to a perfect tool for certain things and those annoyances look like small black dots in a perfectly white surface (That sounded dramatic as well, what's wrong with me? :) )
Isn't it implied that programmers are adults?
It's one of those irregular situations:
I'm a senior developer.
You're an adult programmer.
He's a stark raving juvenile lunatic.
I can't say I blame Rob Pike for not trusting developers, and I've definitely seen more than one case of a C/C++ codebase riddled with thousands of compiler warnings that were just ignored en masse during compilation.
There is another side of the coin, which is that experienced and disciplined developers who think they can take care of themselves, thankyouverymuch, would end up feeling limited by Go.
The point about alternative implementations is interesting. Java has a comparable situation with unreachable code; the language specification has a simplistic definition of what unreachable code is, and makes it a compile-time error. A smart compiler can find more cases of unreachable code, but isn't allowed to make them errors. So it makes them warnings. It doesn't seem to be a big impediment to alternative implementations in practice.
There is a cost to this too. It is another option. Another thing to document and maintain. Another thing for developers to learn about. Another thing for newbies to be confused by. Another thing that will asked about on the mailing list.
In that world, this sort of thing enforced strongly makes me much happier.
For random one-off hacking, yea, it'd be a pain.
Differing use cases lend cause to different tooling.
> Differing use cases lend cause to different tooling.
What?
If you're messing around with your own test code, it's fine if your compiles get slower, etc. On the other hand, if you're writing code that thousands of other engineers are immediately going to depend on, it's better if you're not allowed at all to make things slower via unused imports. True, if you could globally mandate the use of a lint/presubmit rule disallowing unused imports, that would also work. But, that's a harder swing.
I am not writing code that thousands of other engineers are going to depend on. A company that requires this can enforce methodological rules. Go is supposed to be used in different contexts, not just Google, right?
> What?
Different needs, different languages.
I write 100-line scripts in Perl that rip apart text files and extract the bits I want. I don't write 100,000 line embedded systems in Perl.
So, if you're complaining that a language doesn't satisfy a need well, then go find one that satisfies it better. Use that instead.
I use Sublime Text 3 with GoSublime and have noticed that the undo stack is just my changes (makes sense, the goimports is an external process), but that's cool because any CTRL+S is going to trigger goimports and so the correction of the imports is invisible and always there.
I get the sense that most Go programmers use "goimports" to work around the annoyance. I have my Emacs configured to use it automatically. I never even think about imports anymore.
Also, if goimports solves import issues, why isn't it just built into the compiler?
So how is it better than C where you get a warning (at least from GCC) that you have unused variables? You can quickly test things and you are coming back to fix all the warnings later anyway.
It's not as easy to do with a compiled language, of course, but I don't think it would be over the top to have the compiler exit with a non-success code if there are warnings when building.
The "warning fatigue" you get from C is because the warnings are either about false positives or about things that are too trivial to bother with, not because of a property inherent in compiler warnings themselves.
The problem is that while you do that, essentially no-one else on the planet does — and anyone who uses a library thus has to deal with the fact that that library has approximately a 100% chance of having nits like unused variables.
You haven't yet encountered clashing names?
https://golang.org/pkg/crypto/rand/
https://golang.org/pkg/math/rand/
Or?
https://golang.org/pkg/text/template/
https://golang.org/pkg/html/template/
goimports is wonderful, but some care is needed to make sure it has added the one you intended to add.
NB: Only an issue when new imports are added, not an issue if the correct package is already referenced.
It just finds a match and goes with it, and that does cause issue. Both of the above have potential security implications.
Filippo suggests preferring crypto/rand over math/rand as a softfix in this twitter conversation: https://twitter.com/filosottile/status/752210041709719552
I'd probably prefer html/template over text/template as it's better to have someone ask why their output was HTML escaped than to have someone render HTML in plain text without explicitly wanting to do so.
If you don't think of imports anymore, how can they save you from bugs?
(I do (somewhat) understand the "more importantly, the use requirement for variables" part, but also there, I think a warning should be sufficient. Your editor could/should color-code dead code, anyways, making it stand out before you compile)
The requirement that packages aren't used isn't to prevent bugs, it's to prevent packages from claiming spurious dependencies that you're then too afraid to remove. Or, in the case of a static language like Go, don't want to take the time to remove one-by-one and see if the compilation breaks. I deal with this problem in Perl where, basically, in a source code base that's been developed now for over a decade you have no idea whether a given module is actually used in the code, and it could be pulling in a whole bunch of other stuff very confusingly. The problem is less acute in Go to start with, but it's still nice to be able to rely on the imports being accurate.
I don't think I misquoted the OP. He said "A and B help me with C" and I questioned how A could help with C, given the other claim that the OP doesn't pay any attention to A anymore.
"Or, in the case of a static language like Go, don't want to take the time to remove one-by-one and see if the compilation breaks"
That is a problem with perl, a language whose 'grammar' is about as free-form as it gets (aside: iOS is funny at autocorrecting programming language names: cobol => cool, perl => peril or pearl, depending on context), but not with go. The compiler can generate errors for unused imports; it easily could generate warnings instead.
I like clean code, but I also like it if a quick experiment doesn't require extra tooling to remove imports to make things compile, more so if it is not guaranteed that undoing such changes can be automated (adding imports isn't 100% reliable; if it were, why have import statements at all?)
In summary: Go is too opiniated here for me.
Also, this requirement effectively rules out ever using go in a repl. I think that is a minus for modern programming languages.
I don't think so either. What he wrote was unclear (sorry, tptacek). I was clarifying what I'm pretty sure he meant. It's not like I've never done the same thing in writing myself.
"Also, this requirement effectively rules out ever using go in a repl. I think that is a minus for modern programming languages."
It's ruled out for a lot of other more fundamental reasons. Go is probably the most highly polished language from the 1980s.
This would be a much greater condemnation, except the sort of people who tend to frequent HN (including me!) tend to grotesquely overestimate how much most programmers are spending coming up to speed on the latest and greatest. In many contexts, a "really nicely polished 1980s language" is a step up in either reliability or speed. Perl is nominally a more advanced language, but on the whole, most programmers just use it as a sort of dynamically-typed C. I think the majority of programmers still aren't all that clear on what a "map" is. Arming my fellow programmers with more capabilities doesn't solve any problem either I or they have, but can make them worse.
Also, I'd observe that even for modern programming languages, "needs a REPL" is setting the bar high. Rust will probably never have a REPL. I see a couple of defunct projects trying and I haven't studied them, but at best Rust could have an all-in-unsafe REPL dialect, because who's going to be able to reliably type borrow-safe code into the REPL on the first try?
And thanks for the relativism in that remark about the most highly polished language from the 1980s. I fear you are right in that (example: today, a colleague said this was the first time he created a thread. He has had a job as a developer for a few years, and, given his age, likely never wrote for a CPU that isn't multi-core. Luckily, he isn't dumb, as he asked what would happen if that thread threw an exception)
I think ML pretty objectively takes that crown, semantically speaking. For simplicity and elegance it's pretty difficult to beat.
Highlighting dead code is not a trivial matter, at least for anything that could be referenced external to the module.
Go eliminates an entire class of bugs with this feature. It doesn't just make them detectable and less likely. It eliminates them. If you don't care about eliminating them then Go's philosophy isn't for you.
But I for one am sold on that philosophy. I'm disciplined enough that in my rust code I ensure all warnings are fixed before I release. But I don't know if everyone else is just as disciplined. For Go code I do. Every library I use in Go has an entire class of bugs that are impossible. That's a useful guarantee in my book.
On a side note why do we as developers tend to prioritize making the act of writing code easier than the far more frequent act of maintaining that code? Optimizing writing you code over reading and maintaining that code long term seems like a case of premature optimization to me. Allowing something like warnings is one of those things that adds overhead to writing code but eliminates overhead over the life of maintaining that code. The gains are higher longer term at the expense of a shorter term pain. And a pain that tooling like goimports can almost completely eliminate in almost all cases.
Different phases of the development process call for different priorities: in early dev, you want reduced friction and quick turn-around time (something that the unsed imports and variables errors in Go infringe upon). Later on, you want maintainability and ensure that things don't randomly break (at this point, those errors become quite desirable). We shouldn't emphasize readers over writers all the time, we should emphasize them when it's the correct time to do so, which I'll admit is the majority of the time.
> Optimizing writing you code over reading and maintaining that code long term seems like a case of premature optimization to me.
That's actually something I've been thinking about quite a bit in the past few weeks :) I think if we were really concerned about readability of code, we would have much better literate programming tools (e.g., better integration with existing dev tools) and our programs would be written with the intent of being read by others. How many times have we felt lost in a foreign code base (or worse, a code base we wrote, but don't remember too well) trying to implement a change and not knowing or understanding some of the design decisions, being unaware of key assumptions, etc. There is a lot more to readability and understandability than having functions without unused locals. (By the way, why is it okay for a function to have unused input parameters?)
(By the way, why is it okay for a function to have
unused input parameters?)
The amount of development time I save by allowing warnings temporarily when testing easily outweighs any benefit to the ecosystem derived from making that warning abort compilation. I was partially responsible for making this a warning instead of a hard error in Rust and this wasn't even close to a tough call. I would be surprised if a single project in the ecosystem has ever benefited from this: projects that care about software quality pay attention to warnings, and those that don't care about this minimum standard of quality are going to be full of so many other bugs that the unused variable/import warning will make no difference.
> Go eliminates an entire class of bugs with this feature. It doesn't just make them detectable and less likely. It eliminates them. If you don't care about eliminating them then Go's philosophy isn't for you.
Go's philosophy is not about eliminating bugs above all else. If it were, then for example zero values wouldn't exist, reading from a nil map would panic, constants would have stronger types, all fields would have to be supplied when initializing structs, init ordering wouldn't be undefined, overflow would trap, errors would be required to be handled, and that's just off the top of my head.
But it only solves the unused imports issue. During development (especially when playing with code) I often need to temporarily comment out a section of code. I go build, and the situation usually unfolds like this: - ERROR! Yes, now, I have an unused variable dangling around, because this code was using it. - No problem, let's go on and comment out that variable as well. - Oh noes! That variable was defined using two other variables which are now unused! - The first one comes from a function result, but I still want to call that function, so I need to actually change (not comment out) the calling line to use an underscore. - The second is a global variable which using another variable? Where is it going to end?
At this point I end up following the FAQ's advice and just add the line "_ = unusedVariable". The only problem I have with that is that wasn't all this unused variables thing meant to keep us from shipping code with useless bits we don't need in production? Now I actually might end up not using this variable, but because I've ended up adding "_ = unusedVariable" during my debugging and left that on, I have no way of knowing that.
What people are arguing about is errors vs. warnings.
> things that can really cause bugs
"can" means that they don't always cause bugs: other compilers treat such uncertainties as warnings because the human looking at the screen is the one who is in charge.
Go allows you to compile code which does not respect "go fmt", why? aren't you afraid of committing working code that does not abide to the proper style? Improper formatting can lead to confusion, bugs and maintenance problems too, after all.
That has significant value, and is why I've conclude Go's choice here was the right one, despite the annoyances it causes.
I like gofmt, but I don't really care whether the compiler enforces it. It's unlikely to catch bugs.
A sufficiently bureaucratic compiler.
var _ = unusedImport
Or use goimports. Then you don't even have to think about it.
Can't agree with that. We once had an issue with our code because someone had made a copy of his code base and goimports was importing an older version of a library.
Yes definitely this is something the programmer could have prevented. BUT! "not think about it" is not really true.
> var _ = unusedImport
This is what the devs suggest as an alternative to having a compiler flag to turn off the check.
But with a compiler flag, I can easily discover the unused import when I build for production, simply by turning that flag off. By using the variable in a dummy way, I need to remember to go back and check for such things.
Presenting this as a way to address the problem feels like it's missing the point.
>I'm glad there are not such compiler flags.
Because if they were there people would force you to use them? Or are you just unhappy that people could have a different debugging workflow than you?
You can fork it and set it to only remove unused imports. In fact I've done just that few days ago but for different reasons(i.e. I generate some small programs and I use goimports as a quick and dirty way to to clean-up the unused imports). Here is the line where you need to return https://github.com/golang/tools/blob/master/imports/fix.go#L...
> Because if they were there people would force you to use them? Or are you just unhappy that people could have a different debugging workflow than you?
Yeah, I don't want being forced to use a dozen of flags just to compile a hello world program. Nor I do what to see various warnings that nobody really care about. It should fail or succeed. I prefer basic/minimal API that I can build upon not a kitchen sink approach. I think that's what makes Go a great ecosystem compared with many others. Compare the current Go compiler with various C++ compilers and you understand what I mean.
To sum it up you may use separate tools to do various magic things (i.e. goimports), they do not need to obey the Go1 compatibility rules. The issue is not that big to warrant a compiler flag.
This seems like it removes half the value of the tool, though. I can comment out a line of code, compile and test the program. But if I uncomment that line, I'm now missing an import.
edit- how does a tool like this sound?
* If it sees an unused import, it comments it out
* If it sees an import is needed, and there's a commented-out import which would fit, it uncomments it.
* It can run in a "check for commented-out imports" mode, so that commit hooks can reject such a state.
I guess (making some assumptions about go's import semantics) this would avoid the ambiguous name problem; it would mean you avoid having to edit both the import and the usage at the same time; and it makes it easy to tell if a file should be cleaned up.
Maybe it would cause issues if you're trying to choose between two libraries which both provide the same symbols?
import _ "unused/package"
If you want to explicitly import unused packages, you just prefix it with `_`, like this: https://play.golang.org/p/ltfQgco22t
Remove the `_` in the import of `crypto/rand`, and the program won't compile anymore.
Also doesn't that workaround completely nullify all the arguments they made in that section? And it puts the programmer in a worse position than if they could just turn it off temporarily.
The answer to this and a lot of similar such questions about Go is "scale". Things that were sorta kinda convenient for you in a couple hundred lines become nightmares when several dozen developers on several hundred thousands lines of codes had differing ideas of what was convenient for them at the time.
Just as you can't understand Erlang until you understand its emphasis on reliability, you can't understand Go until you understand its emphasis on coding at scale. Almost (but not quite) everything people can't understand about Go are things that people want to do because they work well locally, but things that have become serious problems in source code bases at scale. You also can't understand Go until you realize that the problems weren't merely hypothesized, but extracted from real already-existing source code bases.
That said, I still feel they missed some steps. I'd like non-nil-able pointers. (Optional, like C#, because the way Go methods work means that if you're careful nil pointers of a certain type are perfectly legal and can have sensible methods on them, but that's not always the case.) Packaging is another obvious case where Google had an answer that worked for them so they didn't see a problem, though that's being worked on. (I'm struggling through this because I consider it a non-negotiable feature that my packaging solution allows me to locally mirror everything I use, which all packaging systems (not just Go!) seem to consider some bizarre use case. Strange, I consider it a basic requirement for truly professional development.) So bear in mind I don't mean this necessarily as a defense of Go, I'm talking about what it takes to understand it.
(Edit: also, yes, I consider it a bit sad that Go doesn't have iterator support, per my comment at https://news.ycombinator.com/item?id=12210351 You can sort of bash some stuff together, and io.Writer and io.Reader cover a common case for Go programs and can be composed, but it's still a bummer.)
It is completely the case that some people will come to a greater understanding of Go, and realize it's the wrong choice for their problems. But perhaps it will, at the very least, be less threatening that other people do consider it a good choice for their problems.
That can be a bit annoying, but it's not terrible. Back when Go had insanely great compile times, it was worth it. Now that compile times are … okay … it's — okay.
Anyone using a modern IDE pretty much never even thinks about imports, which are (and should be) automatically managed by the tool, not by the programmer.
In this particular case, the IDE could automatically remove the imports when you remove the corresponding symbol from your source, or automatically add the import when you introduce a new symbol.
The "can be supplied by any external tool" is a cop out that was acceptable in the 20th century but this is 2016, we have a higher bar for developer productivity.
No, they're not.
There are a few necessary conditions for this kind of symbiosis to work well:
- The language has to be statically typed. Without type information, the IDE is completely blind and can barely help you at all without human supervision.
- The IDE has to be written on top of the same runtime as the language it's editing. This is what makes Eclipse/IDEA and Visual Studio so spectacular: they understand the bytecode they are working with.
These are necessary conditions but they're not sufficient. You can still write crappy IDE's if these conditions are met, but thankfully, IDEA/Eclipse/Visual Studio are technical wonders that multiply the productivity of their users.
For example, in Go, the simple action of selecting the the surrounding expression simply doesn't exist anywhere. It's the most basic automatic action that's trivial to do with the proper language and IDE, and yet nonexistent in Go. Along with tens of others.
That's the price to pay when a language is designed without any consideration for its tooling nor basic things we learned about language design these past twenty years.
Go is statically typed.
> the simple action of selecting the the surrounding expression simply doesn't exist anywhere
How so? It's trivial with the `go/ast` package.
Take a look at this adaptation of a keynote talk on the design of Go, with the title "Language Design in the Service of Software Engineering": http://talks.golang.org/2012/splash.article Section 7, "Dependencies in Go" addresses this issue: http://talks.golang.org/2012/splash.article#TOC_7. The relevant paragraph states,
The first step to making Go scale, dependency-wise, is that the language defines that unused dependencies are a compile-time error (not a warning, an error). If the source file imports a package it does not use, the program will not compile. This guarantees by construction that the dependency tree for any Go program is precise, that it has no extraneous edges. That, in turn, guarantees that no extra code will be compiled when building the program, which minimizes compilation time.
Further, the talk justifies this approach through their analysis of how their C++ codebase was compiled:
The construction of a single C++ binary at Google can open and read hundreds of individual header files tens of thousands of times. In 2007, build engineers at Google instrumented the compilation of a major Google binary. The file contained about two thousand files that, if simply concatenated together, totaled 4.2 megabytes. By the time the #includes had been expanded, over 8 gigabytes were being delivered to the input of the compiler, a blow-up of 2000 bytes for every C++ source byte.
As another data point, in 2003 Google's build system was moved from a single Makefile to a per-directory design with better-managed, more explicit dependencies. A typical binary shrank about 40% in file size, just from having more accurate dependencies recorded. Even so, the properties of C++ (or C for that matter) make it impractical to verify those dependencies automatically, and today we still do not have an accurate understanding of the dependency requirements of large Google C++ binaries.
Basically, as soon as I save my file, it gets formatted, linted, unused imports are removed, the project is then compiled and unit tests are ran. I couldn't be happier.
But just as in the article - some of Golang choices are opinionated and IMO just stupid. Lack of assertions is one: Sure programmers are prone to ignoring errors, but Go is not helping at all. Just bans assertions and provides no improvements. No `try!`&`Result` like Rust, not even warning by default if you ignored returned error (IIRC, go lint or go vet checks it) . So what's the point?
How do you decrement an atomic in Go?
AddUint32(&x, ^uint32(c-1))
That's how. Easy to read, and self-explaining. https://golang.org/pkg/sync/atomic/ . I mean... come on.
Unused errors being an error is super annoying, and changing variable capitalization everywhere, because you want to change symbol visibility is another daily frustration source.
Oh, and all my contacts with the community were very unpleasant (maybe it's just me, or bad luck). Any questions ended with some form of "you must do it one true way, otherwise you're stupid". Eg. once I was looking for a way to terminate unit test in case of error, instead of writing `if err != nil { t.Errorf(...) }` over and over again after every line, as in test, every error is just terminating condition. In Rust I would just `.unwrap()` or `.expect()`, which would fail the test, report backtrace, etc if anything unexpected went wrong. All the help that I got was just snarky comments for being lazy.
I will continue to use Go in some projects, as it gets the job done, performance is OK, has some userbase, and ecosystem is quite vital, but overall, it seems to me that it's rooted in same form of stubborn crudeness that has no good reason in XXI century, ignoring years of research and good ideas. For anything more demanding, or fun I would always go with Rust.
Ooh. How do you delete from a slice in Go? With append() of course!
http://stackoverflow.com/questions/25025409/delete-element-i...
Is that really the _best_ way to delete from a slice in Go?
Yep[0], and it needs a special case to remove the last element of the slice (if the index is user-provided). If you don't care about the slice order you can also swap the element you want to delete with the last element of the slice and shrink the slice by one element. Also fun, it can leak memory.
If the final argument is assignable to a slice type []T, it may be passed unchanged as the value for a ...T parameter if the argument is followed by .... In this case no new slice is created.
https://golang.org/ref/spec#Passing_arguments_to_..._paramet...
(Otherwise, I completely agree that having to use append to remove an element is stupid.)
And why would one even remotely want that?
Unless they seriously think that if the syntax is painful, people will avoid doing it and get better performance...
If you need to delete from the middle of an ordered collection of items then it's better to use a linked or doubly-linked list (unless it's small then it doesn't matter).
So?
> If you need to delete from the middle of an ordered collection of items then it's better to use a linked or doubly-linked list (unless it's small then it doesn't matter).
Meh. Deleting from the middle of an array is one memmove, you don't get 1~2 pointers memory overhead, caches blown and having to deref' n pointers getting to the item to remove in the first place. If your language provides arrays, there are almost no cases where you should reach for linked lists without having seriously benched both cases.
And that's before the consideration that a Go linked list means loss of type safety or a hand-rolled hand-specialized implementation.
slice[n] = slice[len(slice)-1]
slice = slice[:len(slice)-1]
Probably one should campaign for adding a delete operator to slices, though so far I have never missed it.
I can testify to this! I even got banned from the golang subreddit :-D
EDIT: I didn't bully anyone or anything, just told them that they can't call the language as golang, because when I had asked feedback on my work an year ago, the only feedback I got from a certain person and that too very rudely was "to not call the language Golang and call it Go, ruby is called ruby and not rubylang"
> I can testify to this
Even though you showed up on the golang subreddit, asked a question about javascript [1], got two answers (one without jquery, one with), you can attest to the unpleasantness of that subreddit? Even when you posted your todo manager written in Go, the majority of the feedback you got was positive.
I find your reaction a little surprising.
[1] - https://www.reddit.com/r/golang/comments/44g3ln/help_require...
When you look at the Go ecosystem there are two classes: 1. core team (the elites) 2. others (us plebeians)
The parent post has a brilliant line, which made me laugh for half hour:
>I wanted to check an invariant; how does Go do assertions? Fuck you, you’re a bad programmer. That’s how.
the others are awesome, my interaction with the core team was far from pleasant. They are rude and outright snarky. They focused on the book title more than the content and didn't even bother to read the content. I mean they did take a cursory glance, but the others on reddit were amazing:
https://www.reddit.com/r/golang/comments/3zle8c/i_am_writing...
https://groups.google.com/forum/#!searchin/golang-nuts/suraj...
This is how I got banned from the subreddit. Anyways Good for me, I stopped browsing reddit that much.
https://www.reddit.com/r/golang/comments/4lj0yn/congrats_bra...
On the last link, click the downvoted comments, I deleted few comments, but yeah, that's about it, I got banned because I questioned the elites, it is called bullying!
Later I spoke with that guy himself, turns out he wasn't being rude :-D
And people are falling over themselves to use Go in places that seem inappropriate. Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc. So why do startups choose Go? You're just shooting yourself in the foot. Use OCaml, use C++, use Clojure, hell, use Swift or Rust, just use something that at least pretends to care about expressiveness and abstraction. I actively avoid working for shops that use Go heavily, it's an indicator of cargo-culting.
I find some of those strengths and others shine in a small team of strong developers too, if they "get" Go.
But to your point: some people expect their startups to eventually employ a large number of programmers, at which point they will inevitably have some mediocre ones, that being a side effect of "hiring only the best."
Planning for that day is not shooting yourself in the foot.
Enter Go, and while we all agreed that the language kind of sucks and $FAV_LANG is better, we somehow stopped bike-shedding and started to get real work done.
Sure, it's not the most exciting language in the block and its community seems to live in the 70s, but sometimes targeting the lowest common denominator can pay off, as is the case for us.
Except that even Algol 68 is more feature rich than Go, assuming a 60's powerful computer, like the Burroughs B5000. :)
But I do appreciate that every line of written Go code is one less of written C code.
Go thinks fast compile time is a feature. How fast is your Algol 68 compiler on a ten million line code base?
But if you want numbers, Turbo Pascal 5.5 was doing 34,000 lines/minute[1] on MS-DOS back in 1989.
Of course faster hardware is part of the answer, but I suspect that it doesn't cover nearly all the ground between Turbo Pascal's compile time and Go's.
Besides I am comparing an 8086 with 640 KB against a i7 with 16 GB and three level caches.
Go being fast isn't that much of an achievement in 2016.
If Go compiles faster than Turbo Pascal with an 8086 CPU and 640 KB RAM, that is an achievement.
My point is that Go's compilation speed isn't nothing extraordinary, I can keep giving examples of other compiled languages that had equally fast compilers in the the mid-90's.
Oberon, Go's grand daddy could bootstrap itself and build a full working graphical workstation OS in less than one minute if I remember correctly.
2. How many of those people would have much smaller codebases if they used a more expressive language?
3. Of the people who have 10 million line codebases and would still have 10 million line codebases in a more expressive language, how many of those could actually compile their programs faster if they used a language that allowed partial compilation of only the parts of the code that were changed?
Very few people have Google's problems, and I'm not even completely convinced that Go is the best way to solve Google's problems.
Lots of iOS applications use it already.
> Would you use C++ for a web API?
Facebook and Google apparently do use it.
There's no active program to rewrite things in Go, and most things are not meant to be written in Go from now on or anything -- it's just one of the supported languages.
He said "hell, use Swift" -- which didn't imply that he's considering it the first or best recourse.
That said:
1) There's far more Swift in production (on iOS devices as native apps, not as backend, but still production code) than Go.
2) Merely 4-5 years ago nobody had seen Go in backend (web/server) production either. Or at least very few.
3) There's already some support for server side Swift: http://perfect.org/
4) And more: IBM uses Swift for apps AND server side, and has open sourced a Swift web framework/server: https://github.com/ibm-swift/kitura
>Would you use C++ for a web API?
If I needed the crude speed yes, and in fact lots of web APIs delegate to C++ behind the scenes (e.g. for task queues), whereas some are in C++ directly.
In fact Facebook itself used to transpile PHP to C++ and run that (through their HipHop project).
>Go was developed because C++ is a horrible language
Go was developed because some old C/UNIX hackers didn't much like C++/Java and wanted to do their own thing, bringing some Plan 9 flavor on.
C++, warts and all, has proven itself time and again.
Most of the things we depend on and use, from the browser you're using, to JITS and compilers (LLVM for one, V8), to the Windows OS, nearly all major GUI programs (all major DAWs, NLEs, Photoshop, 3D programs, KDEetc), to 99% of AAA games, to Google's search engine core are written in C++.
And C++11/C++14 standards have made it a much better, even new, language. The automatic C++ dislike is cargo cult from people who usually don't use it and just repeat old wives tales.
I've got that but it was too late... the comment was already posted. I've up-voted his response.
The rest of your points are invalid. Development is not only about a http server(which I'm sure is subpar compared with Go). You will burry your time and energy in making basic things work. As developer that's great because you can use your experience on your "next" project but as a start-up you are very likely to fail. There may be some IBM developers that played around with the language but I'm sure IBM has no swift powered service in production. Swift is still a language in flux with many changes pending in the next 2 -3 versions. Big corporations don't really like to invest in unstable environments. Maybe in 3-4 years from now Swift will be able to compete with Go but today there is really no reason to use Swift over Go for a backend service.
> Go was developed because some old C/UNIX hackers didn't much like C++/Java and wanted to do their own thing
I must say it again: C++ is a horrible language. It may perform well and it may be widely spread but that doesn't change much as far as its design is concerned. C++ competes mostly on its reach not on its merits. Hopefully that will change as new platforms emerge(i.e Rust).
> In fact Facebook itself used to transpile PHP to C++ and run that (through their HipHop project).
Yeah, that's a pretty picture for what C++ is really good for. I rest my case.
Edit: I would also say "experienced hackers" instead of "old hackers". The C++ or Swift hackers are not younger anyway.
The are many reasons for that, but most importantly, Go doesn't support deterministic memory management (like C++, Rust and Swift) and opts for GC instead, which makes life easier for at least 95% of its use cases, but not for some of the use cases C++ used to shine on.
I think that the Plan 9 Googlers dislike of C++ (and in truth, Modern C and UNIX as well) is closer to be the real reason for creating Go. It really was never designed to be a proper system language.
The same could be said, and was said for Go compared to Java C#, etc just a few years ago. And it probably can still be said, as older languages have much more stable, richer ecosystems, support, tooling, and use bases.
>I must say it again: C++ is a horrible language. It may perform well and it may be widely spread but that doesn't change much as far as its design is concerned. C++ competes mostly on its reach not on its merits. Hopefully that will change as new platforms emerge(i.e Rust).
Well, it gets a lot of things right. Compatibility with C. Great performance. Enough abstractions to be usable. Enough batteries built-in compared to C. Great ecosystem and tooling, first class vendor support, etc. A language is not just its syntax -- not even just its semantics.
I don't say that you should never use C++. Sometimes it's a necessary evil but that doesn't make it a great/pleasant choice(at least for me).
>> Great ecosystem and tooling
I think it could be considered GREAT 20 years ago but now it is miserable compared with the new languages. For example it has no kind of distribution model(i.e package manager). Cross platform compiling is no fun... C++ parsing is no fun either so you could say that its syntax is quite important if you were to develop new tools.
I'd keep using Go for one-off scripts (grab SSH keys from LDAP for sshd, that sort of thing) and system integration stuff, though.
For now! Phoenix [0] will hopefully help turn the tide.
I switched from Go to Elixir/Phoenix a year ago and I couldn't be happier. I've used a lot of web frameworks over my decade as an engineer, and Phoenix is the first one that has remained fun to use, fast (!), and productive.
Crucially, its community has remained accepting and helpful under Jose's leadership - in contrast to the unfixably toxic Go community.
It's not perfect - among other things, it can't type-check certain things that can and do happen in Erlang/Elixir programs, and won't complain about some errors - but it's better than being purely dynamic at not a whole lot more effort.
[0] http://elixir-lang.org/getting-started/typespecs-and-behavio... [1] http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html [2] https://github.com/jeremyjh/dialyxir
Rust is noisy in other parts, for other reasons (trying to explain to compiler how to write super fast and data-race free code). But visibility qualifiers are not a problem.
`extern` is only for importing crates, which is like 10 lines at in whole package/crate. Irrelevant.
Ultimately in the end, for this example it really seems like the same amount of work. You add one word, I run one command.
You are incorrect on multiple fronts - 1) there is not even an active proposal to this effect, its just an idea that was passed around and not even really discussed, 2) the idea did not involve making rustc depend on cargo at all. It would be shocking to me for the Rust community to ever accept a proposal which required rustc to depend on cargo.
In general, please try to avoid contributing to the spread of misinformation by not stating as facts things you are not very confident are true.
It was "lol what?" for me. Rust's compiler error messages are very informative and sometimes contains tips what to change in your code to make it work (not just general words, but code you can use right now, with your variables/functions etc.).
Borrow checker explains step-by-step where ownership starts, where it ends and where you are trying to use it.
Panicking messages - another story, but it's not compiler's error messages, it's runtime. In example of code Adam using as proof, author is using 'panic' and 'unwrap' - reasons to don't expect gentle behavior.
If you can't write code in idiomatic way, try to catch your panics and give more descriptive runtime error message in your code - other users of language shouldn't pay for it.
rustc --explain EXXX
The blog explaining the author's disdain for Rust mostly just seems to whining about the borrow checker.
The author links to a previous post on the subject, from mid-2015, so they clearly have at least tried Rust in the past.
And while many Rust messages are OK, one should be careful not to confuse familiarity with Rust's error messages[0] with Rust's error messages being good (being inherently informative and good).
Here's a clearer example (fixed since): http://dbeck.github.io/My-First-Steps-In-Rust/ note two issues:
* the error message is busy as all hell which is a common issue in Rust, before you've built the habit and learned how they're structured Rust error messages often look daunting. By comparison Elm makes much more extensive use of spacing and tries to avoid repeating the same information (e.g. file names) over and over.
* the suggestion it provides is just plain wrong, it suggests implementing Debug for T, but T is always a standard number which already implement Debug, what's missing is a trait bound. To a beginner that was not a helpful suggestion as it would only send them on a wild goose chase (of trying to implement Debug on either T or i32/f32, and good luck with those).
> The blog explaining the author's disdain for Rust mostly just seems to whining about the borrow checker.
So? Just like monads in haskell, the borrow checker is hard until it "clicks" (and then it fundamentally shifts your understanding and it becomes hard to understand not getting it).
[0] and experience/understanding for the various possible sources of the most common ones, but that you can build for any compiler, even G++'s pages of template expansion garbage from the early aughts
Er… both? In separate sections of the comment?
> Because I can [not agree] about error messages
I've provided a clear example of an issue, are you denying objective reality or are you asserting that providing incorrect suggestions leading beginners in entirely the wrong direction is fine?
Now what the hell are you talking about?
I didn't reply to your comment I replied to valarauca1, they're the one who mentioned the borrow checker, if you're unhappy about that whine to them don't include me in your pity party.
"And while many Rust messages are OK, one should be careful not to confuse familiarity with Rust's error messages[0] with Rust's error messages being good (being inherently informative and good)."
So you will still try to pretend we are not talking about error messages here?
I'd appreciate you not insulting me, as well as you starting to make sense.
> You are responding to the branch my comment started
I was not, however, replying to your comment. As I already told you I was replying to valarauca1's comment, which is why my own comment was threaded below and in reply to it, and quoted it.
> So you will still try to pretend we are not talking about error messages here?
I'll repeat my previous query in a new context and with slightly more alarm: what the hell are you talking about?
I never "tried to pretend"[0] we were not talking about error messages, my answer[1] to your original query[2] specifically noted the opposite.
[0] and would again appreciate not being insulted
Yeah, but you need that kind of repetition to get text editor jumping to correct line number.
AFAIK, Rust already implements concise messages on nightly.
Not really, what you need is a regular and parseable structure.
Though to be fair I am not huge fan of Elm's one error per build either.
Still way better than C or C++'s though, I suspect. (I'm too fluent in C++ errors to have a proper feel for how bad they are anymore...)
Iterator errors as well get massive when dealing with passing tuples down lazy lists.
Most (negative) discussions about Rust are about the borrow checker. I sometimes wonder if people dislike it because it makes them feel the same way they felt the first time they learned to program and the compiler would never accept their code.
I do like the current errors, but that's no reason to rest on our laurels! There's a lot of ways in which they're not great.
Once you understand the paradigms, Rust error messages make sense. It's like the folks who describe git by starting with a exposition on merkel trees: technically precise, but incomprehensible if you only know cvs.
> Rust, I think, suffers from a lack of empathy with a novice audience.
We're actively working on fixing up errors to be even better, so hearing about specifics here would be quite valuable!
The borrow checker is the simplest thing once you internalize it's rules. Just the road to breaking all the bad habits C/C++ teach you are fine over the years takes a while. And most these rules are mostly excessive and unnecessary coming from a C perspective. The borrow checker is kind of like type systems. It prevents a whole class of errors, but you lose the ability to express some perfectly valid code.
It is really a kind of mental-quantum-leap. Once you internalize it's rules you really lose the ability to understand how other people can't.
Also to deflect some blame from The Rust-Community. I'm just kind of a horrible person on the internet. I'm working on improving :\ Sorry for the coarse comment.
You could have said the exact same thing of G++'s pages of template error messages. That's indictment not praise.
If you must be highly familiar with the language to understand the compiler's error messages you might as well remove the messages altogether and just print "?" as ed(1) does, developers familiar with the language obviously don't need them and beginners apparently aren't allowed to understand them so why even bother?
(good thing the Rust developer team disagrees with your vision of the subject).
No. I'm clearly replying to a clear opinion, there's no catch although I might be exaggerating very slightly.
> but it's just not true.
What is not true?
> I went my way from the 0-noob in Rust to comfortable using and I can say compiler errors were always helpful.
That's got nothing to do with the comment you're replying to.
Go it easy to learn, as its a moderately sized language, but it has just enough abstractions, that your programs are not held back by the lack of those, without opening the traps too "powerful" languages bring with themselves, namely complexety.
On top of all, the whole infrastructure is very well thought out and a pleasure to use. A very fast compiler which produces static executables, a good module system without header files, a rich standard library, many things. There are quite a few quirks, especially for the beginner, but the more I gain insight, the more I agree with the choices made - with some I don't, but the agree to disagree ratio is surprisingly high. And most of them don't get into the way of writing good programs, which is what counts.
And of course, there is always the question of the environment. The Go universe has tons of libraries, actively developed.
Static executables by default is something that Go is famously good at, but I'm pretty sure Haskell can do this as well without so much pain and with a type system many times stronger than Go's.
Wirth's work also includes languages with GC. :)
Check Active Oberon:
http://www.ocp.inf.ethz.ch/wiki/Documentation/Language
Component Pascal is a Oberon-2 derivative but Wirth hasn't collaborated much there:
http://www.oberon.ch/blackbox.html
They made the very last version available for free. It was a kind of Delphi like, with the Oberon ideas of full stack OS.
www.pas.rochester.edu/~skulski/Presentations/BB_Class.pdf
> It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system.
Strict type checking? Have you used any other languages besides C? Go's type system is a joke.
Like literally, it's a joke. If you get a bunch of people who know about types languages in a room discussing types, "What about Go?" is guaranteed to get a laugh.
For example you cant write a thread-safe map container in Go without sacrificing type safety (i.e. one that would not crash the program when there are concurrent writes to the map).
The standard library doesn't offer one either.
This means you end up copy pasting the lock related code for every map you want to make thread safe. You have to remember to declare and initialise its lock, to use that lock every time you access it, and to remember to unlock it.
Now for some things, this cost isn't too bad. For others, it makes the language a joke.
As a result, Go is a toy, or at least, a non-general-purpose language. If the problem you're solving fits its limited set of built-in abstractions, its great. Otherwise, its a disaster.
In my experience, well written programs evolve over time to gain new carefully chosen abstractions that cleanly implement shared underlying concepts of the problem domain. These abstractions often require the use of generics.
When this happens in a Go project, however, you're out of luck. Even worse, developing primarily in Go means distorting your thinking to fit its limits.
This is more or less true in any language, and its not a binary thing. Languages are all over the place on the ladder of abstraction (with lisps being close to the top, Go near the bottom).
p.s. Java also suffers because it added generics too late: by the time they were added there was already a clear picture painted of "idiomatic Java". To make matters worse lambdas were also added way too late, and the verbosity of type declarations is still staggeringly high. However, modern Java is a much better language than Go.
I've no particular love for Java's type system, but I can't criticize it as much because it was a lot more reasonable when it was released (1996). In 2016 there's no excuse for having a type system as broken as Go's.
So what, you're on par with a 20 year old language? C# for example learned from Java's mistakes; why couldn't Go?
You don't need generics, sure. You can write working code in assembly, too. But abstractions catch more of your mistakes for you.
> There is a workaround for it, though. Basically you write a template and do code generation off of that to sort of approximate generics. I've never done it myself, though.
So, basically slightly more powerful macros, like in C, with most of the pitfalls and dangers associated with them.
There are better approaches to these problems.
In other languages you can compose errors just as regular values, which allows you to handle the errors at the place where you have all the information to deal with it.
Not only that, the types represent the structure of the computation you ran.
For example, your type is Future[Option[List[Person]]] and just by looking at the return types of the things you called, you can tell exactly _where_ an issue occurred and how to handle it:
Your value is a Success(None)? -> The method inside your asynchronous computation that returned Option[List] failed!
Just to note, Future[Option[List[Person]]] is not some made-up example, it could be a real-world query against the database–for instance "do we know the friends of user X"?
- Future – we run it async
- Option – we might not know it
- List – his friends
- Failure – "the database response from the database timed out"
- Success(None) – "we have no idea about user X' friends"
- Success(Some(Nil)) – "X has no friends"
- Success(Some(List(...))) – "here are X' friends"
In Go the closest pattern would likely be to extract the string from the error value and compare it to error strings you recognize. An alternative would be to define a special single-purpose data type specially for each type including all combinators, as Go would not be able to express any commonality between Future[Option[List[Person]]] and Future[Option[List[Pet]]]. You would need to define 4 new data types and all operations anew.
Go is a much bigger problem in our industry than the tone of my post.
> I have never claimed that Go has the most advanced type system.
You claimed it had "strict type checking", when it has the least strict type system of any statically-typed language in common usage except C.
> But indeed, compared to C/C++ which still are the most commonly used languages in industry, it has a strict type system.
With template types, you can definitely get more strict type-checking out of C++ than out of Go.
So basically, Go has a more modern type system than C. And that's arguably not true. None of which disproves what I said: I said, "people who like Go only like it because they have no idea what has happened in programming languages for the last few decades."
> And it gets work done.
You can make that claim about any language. The question is, does it get work done as efficiently as other languages? And the answer is pretty clearly no.
Not really, multi-paradigm.
> and at least Go has reflection.
Go is introspective.
Lisp has both introspection (e.g. find-class allows to look at existing classes) and intercession (e.g. ensure-class creates/modifies a class at runtime).
Yeah, that's probably a better way to describe it; it certainly ain't Haskell. But Go really doesn't want you even to use things like map and filter.
Edit: and the author mentions that at the end of the post. That's what I get for commenting before I've read the whole thing.
No language can be everything to everyone. One thing that encourages me to keep writing Go is the team has done a very good job at communicating their intentions for the language.
It's very clear to me when to write Go and when not to. That's a sign of strength to me, as it shows the language has the confidence to tell you "perhaps I'm not the best choice for this particular problem".
Would you care to elaborate on this? :)
I actually enjoyed going from dynamic to static typing for command line tools, the compiler saves me a lot of time tracking down bone-headed errors, which are typos in variables 95% of the time.
var t int
t, err := someFunc() // that's fine
var s struct{ x int }
s.x, err := someFunc() // doesn't compileIn your example, you end up modifying the struct value x, even if there was an error. Maybe there are cases where that is the correct behavior, but even then I would advocate for explicitly setting the struct value after handling the error, to make it very clear that it was your intention to do so, rather than doing it be accident.
Go's opinions were, for me, especially helpful while learning the language.
I think strong opinions are helping Go not being "yet another language". So that's good. Like most things, it isn't for everyone.
When you see all those new system languages, (go, rust, swift), D was there before them, and did not pretend to be a new cool thing with good ideas, it just tries to be a nicer C++ to work with.
I don't need to do things the right way, I just need a language that is usable and doesn't try to do the job for me.
I still use it but I also have a love, hate relationship with it.
From Microsoft:
https://msdn.microsoft.com/en-us/library/dd233052%28v=vs.110...
https://msdn.microsoft.com/powershell
Xerox PARC used Cedar for the software implemented on Xerox 1132 (Dorado) and Xerox 1108 (Dandelion) systems, including interpreters delivered on the system:
It didn't have to be this way - Swift could have been written atop the JVM, v8 could have been implemented via Boehm, etc. For whatever reason, when it counts, the stuff under the hood doesn't use garbage collection.
It doesn't matter where those interpreters are being used, the fact is that they exist.
> Microsoft's C# CoreCLR is C++.
Yes, but they have moved their compilers to C# with the Rosylin project with MDIL and .NET Native moving more code to C# side.
Also check the Phoenix compiler framework, a LLVM like project from MSR using C#.
> Go's core runtime is in a Go-minus-GC subset.
Of course, there needs to exist a Genesis for the GC, but once it is there, 99% of the remaining infrastructure makes use of it.
If you take Nashorn engine running on Jikes, it is an 100% Java stack running a JavaScript interpreter.
> For whatever reason, when it counts, the stuff under the hood doesn't use garbage collection.
Most of the time it is just building on top of whatever already exists instead of starting from scratch.
Taking Swift as an example bootstraping the language would increase the burden designing it, as they are still far from fully stable design.
If they would throw away in man years invested into the LLVM, which happens to be written in C++, it would take ages before pure Swift compilers would ever manage to catch up.
However these shortcuts open the door for those not savvy in compiler design to use as ammunition against secure languages.
A compiler is a different matter. GCed languages are very compelling for static compilers. Even gcc uses GC internally.
The claim is that GCed languages make for poor interpreters - and also poor JIT compilers and runtimes.
> If you take Nashorn engine running on Jikes, it is an 100% Java stack running a JavaScript interpreter
Nashorn gets participation points, but it's not competitive with any of the major JS engines, all of which have C++ runtimes.
> Taking Swift as an example bootstraping the language would increase the burden designing it, as they are still far from fully stable design. If they would throw away in man years invested into the LLVM, which happens to be written in C++,
This still confuses the compiler with the runtime. The Swift compiler is indeed written in C++ using LLVM, but it could have easily been written in a GCed language without affecting much of anything.
But the runtime is separate, and it also happens to be written in C++. It's possible to imagine the Swift runtime written in a GCed language, but that is not what Apple chose to do.
Have you ever spent time with Graal, Truffle, PyPy?
30 years ago I used to take the flak for arguing about C++'s suitability for writing programming language tools in comp.compilers instead of C.
Yet here we are praising C++ virtues over other languages for writing interpreters and JITs.
One thing I learned in all those years reading compiler related papers, is that many times the main issues are actually human and not technical.
The majority just want to have something running, and take the shortcut of using whatever works to achieve their goals, instead of taking the effort that might bring the technology forward but would delay getting everything to work.
In practice, the STW mark and sweep phases are in the sub-millisecond range, and the GC runs not nearly as often as 20 times a second, so 10 ms of interruptions per 50 ms is the absolute worst case.
There is an inherent tradeoff between pauses, throughput and extra memory requirements.
If you're interested in the finer details, I'm sure the GC talk at golangUK later this month will discuss them all, and the slides and/or videos will eventually land here on Hacker News.
I've simply never wanted for the things he asks as I've never had them. It's all in the expectations is my point.
Take net package for example, it's not opinionated, it's just completely broken and misdesigned. There is so much mess with even the most basic things, like timeouts and cancellations [1][2] that it's almost impossible not to fuck up somewhere.
This is because the whole net library is synchronous and pushed onto experimental ideas of goroutines and channels. Instead of having an actual event loop underneath with timers, signals and everything and use asynchronous writers and readers they just poll fds and wake goroutines when fds are ready, forcing themselves to deal with typical multithreaded concurrency hell.
[1] https://blog.cloudflare.com/the-complete-guide-to-golang-net... [2] https://github.com/golang/go/issues/16100
Do You think all those ycombinator company posts get to the front page on their own merit? Ha!
Stunning.
I typically only notice YC companies mentioned here when it is a Techcrunch (or similar) article about them.
I'm a nobody (to answer the accusation below) and my submissions of articles that are years old and not recognizably "hot" make it to the front page with only three to five upvotes all the time.
Quick upvotes or comments count for a lot.
It's not great to post comments like this taking a thread so badly off topic, let alone jumping to conclusions that the admins are manipulating what is obviously (once you're familiar with it) baseline HN behavior. Love-hate-Go posts are a drug here; and so are all things Rust, which is why those stories are currently #1 and #2. If we did anything to posts like that it would be to downweight them, but I'm tired, and a good pro-and-con language vent seems like a fairly innocuous thing for HN to do overnight (with apologies for our Pacific-timezone-centricity), so have at it.