23 ms·
From the book: "But it has comparatively few features and is unlikely to add more. For instance, it has no implicit numeric conversions, no constructors or des
by realrocker 11y ago
From the book:
"But it has comparatively few features and is unlikely to add
more. For instance, it has no implicit numeric conversions, no constructors or destructors, no
operator overloading, no default parameter values, no inheritance, no generics, no exceptions,
no macros, no function annotations, and no thread-local storage."
- Isamu 11y agoFrom the preface: "achieving maximum effect with minimum means." Sort of the anti-Perl? I say this as someone who likes both Perl and Go. Go is very contrarian, and I applaud this.
- masklinn 11y ago> From the preface: "achieving maximum effect with minimum means." Wouldn't be out of place at a marketing agency, with about the same level of truth too. > Sort of the anti-Perl? In what sense? The one thing you can say about Perl is that it's a huge language, so the anti-perl would be a very small language. Go isn't a very small language (like Forth), it isn't even a small one (like Smalltalk or Self) it's about the same size/complexity as an early Java. Somewhat bigger in some ways (more magical builtins and constructs) somewhat smaller in others (simpler visibility rules, no synchronised methods/blocks), but in the best case it's a wash. > Go is very contrarian, and I applaud this. Perl is also very contrarian.
- rudolf0 11y agoI think it's fair to call Go an anti-Perl. Perl is very liberal. There's always more than one way to do things. Go is very conservative, in comparison. I'd agree that both are contrarian, but for very different reasons.
- masklinn 11y ago> I think it's fair to call Go an anti-Perl. Then again, pretty much anything can fairly be called an anti-Perl, possibly even Perl.
- seiji 11y agoGo is very contrarian, and I applaud this. It takes more than reversing the order of parameters and using known-braindead ideas like codified tabs-are-good syntax to make contrarian ideas valuable. Just because you change green lights to mean stop and red lights to mean continue doesn't make contrarian suddenly better than the way things were.
- rudolf0 11y agoWhile I think your comment is unconstructive, I do have to say that I don't quite understand why Go decided to force hard tabs. Even more confusingly to me, I really don't understand why they seem to standardize on tabs expanding to 8 spaces rather than 4. The 2 spaces (of soft or hard tabs) favored by some Ruby and CoffeeScript programmers is too little, but 8 spaces is way too much.
- trevorstrohman 11y agoA significant fraction of the Go core engineers use proportional fonts when programming. On their screens, hard tabs are the only tabs that work. Spaces on proportional fonts are too tiny to be useful for moving code around.
- seiji 11y agoWhat? Really? Who in the world would do that?
- trevorstrohman 11y agoUsers of Acme, written by Rob Pike. See screenshots on this page and note that the font used is not monospaced. http://acme.cat-v.org/ http://acme.cat-v.org/
- pconner 11y agoIs there a reason why Acme doesn't use a monospace font? I couldn't find any justification on that site.
- norswap 11y agoAre they actually proud of having no generics? :o
- dekhn 11y agoNo, the authors specifically said that they would like to have generic features but couldn't figure out a way to implement it without unacceptable performance problems. I'm pretty sure the feature will show up in the next few minor version increments.
- MichaelGG 11y agoBasically they dismissed every implemented approach, despite generics obviously working in other systems. (And it's hardly a "new" feature unless we're counting in multiples of decades.)
- AnimalMuppet 11y ago> Basically they dismissed every implemented approach, despite generics obviously working in other systems. But working at a price. And Go isn't willing to pay the price (especially in terms of compile time). If Go ever adds generics, it will be with a new approach that doesn't blow up compile times.
- 15155 11y agoI wonder how much developer time is spent due to a lack of generics. Developer time costs more than compiler time.
- xrstf 11y agoWhich is why Go is advocating using "go generate" to generate code. See projects such as https://clipperhouse.github.io/gen/ https://clipperhouse.github.io/gen/
- 11y ago
- yokohummer7 11y ago> no default parameter values Hearing this leaves a bad taste in my mouth, because one of the (mis)features I've found in Go is its implicit default value in struct initialization. In Go, you don't get a compile error when you miss some fields while initializing a struct. e.g. type T struct { a int b string c float64 } t := T{c: 1.5} will happily set `t.a` to 0 and `t.b` to an empty string. While this is useful for maintaining backward compatibility (adding more fields to a struct doesn't break upstream code), it also hinders discovering genuine mistakes at compile time. So typical Go programs end up using 0 or an empty string as a sentinel value. This is probably what made me feel Go's dynamic nature the most. It really is pretty close to a dynamic language.
- deleted 11y ago[deleted]
- fixermark 11y agoIt's one of those features that seems mad until and unless one runs into the situation that justifies it. Go provides default values to avoid the C error-factory of random undefined behavior resulting from re-use of whatever is in a memory address; that much is clear. But the reason Go lets you partially instantiate an object (and separates out construction from state) is to make it easier to write unit tests, where the common case is that you want to circumvent the "main line" object construction pathways.
- bradtgmurray 11y agoThat looks a lot like C to me, which I wouldn't call a dynamic language. typedef struct Foo { int a; int b; } Foo; Foo f = (Foo) { .a = 1 }; // This will initialize b to zero.
- hactually 11y agoIsn't it funny how C has so many ways to accomplish the same thing. Why did you use a typedef with a tag? typedef struct { int a; int b; } Foo; Foo f = { .a = 1 };
- jgalt212 11y ago> no default parameter values This would seriously bum me out as I find the easiest to extend the functionality of an existing Python function is to add a new parameter with a default value. This way, regardless of whether the existing code base the calls the new or old version of the function, it performs the same way as it always has.
- bkeroack 11y agoSince Go is statically-typed and compiled, it's much easier to refactor a function compared to Python. Change it and fix everywhere the compiler complains.
- jgalt212 11y agotrue, forgot to think about that. But still potentially a lot of changes to fix, even if you are explicitly told what needs adjusting.
- logic 11y agoAnd this is where Go's tooling shines: https://golang.org/cmd/gofmt/ https://golang.org/cmd/gofmt/ (Refactor automatically, not by hand.)
- TillE 11y agoThat's fine for internal functions, but a big problem when publishing any kind of interface. It's really nice to be able to extend an interface without breaking stuff or adding cruft.
- pconner 11y agoYou can use variadic arguments with an interface type or a single struct parameter to get similar behavior.
- LBarret 11y agocompare this with python, which has carefully evolved into a better language.
- Artemis2 11y agoMore like into two languages that will keep on existing for the next decade.