Less is exponentially more (2012)

67 点作者 tpaschalis大约 5 年前

20 条评论

nshepperd大约 5 年前

> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.> ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']...> If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition.How do you get all the way through designing a programming language without realizing how incredibly wrong-headed this is? "Inheritance hierarchies are bad", so... you exclude generics (which are compositional, and have nothing to do with inheritance), and only support subtyping polymorphism via 'interfaces' (ie. inheritance)? That is the exact opposite of his claimed principles!(And then as a minor concession to programming usability, he adds generics anyway, but only for built in types (maps and arrays), so advanced data structures are still an exercise in void* wrangling.)

评论 #23155627 未加载

评论 #23157531 未加载

评论 #23155607 未加载

hyperman1大约 5 年前

A few years ago I started to play with go. First impression was great. But a month or so in I started to having more and more doubts. As a Java/C++ programmer I was missing especially the generic collections. Slice and map are a good start, but not enough.Then one day I had to implement the swap operation for sorting. Again. And I thought that even C's qsort was better, and WTF am I wasting my time on this half-assed language. I dumped it, tried rust, and even with its slow compile times I couldn't be happier.Now a few releases later, they fixed sort so I can only implement compare. Sorry, it's not nearly enough. Essential parts are simply missing. Exhibit A is source code generation, a clear indication go isn't enough on its own. I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again.It was a near miss, though. SOme things are clearly correct. I want to look again when they finally have generics, and some basic collections. I hope that day comes and I can give it a new chance. But until then, less was simply not enough .

评论 #23154817 未加载

评论 #23154503 未加载

评论 #23160841 未加载

评论 #23154539 未加载

nobleach大约 5 年前

While this philosophy has a lot of value, it just isn't for me. I did a few apps in Go, and fought my way to a decent level of proficiency. I got to a point where I could solve some problems without constantly consulting the docs. But in the end, I wasn't enjoying the experience. The speed was great, the compilation was great. All the selling points were true. But it was missing so many things that I enjoyed using from other languages. (Mostly methods for dealing with collections of data - everything in Go is a for loop). I did another project in Kotlin shortly after and wow, that language has everything AND the kitchen sink! But, I truly enjoyed myself more while working with it. So, this is not me saying Go is "bad". It's actually quite good. It's just not something I enjoy.

评论 #23154589 未加载

评论 #23154592 未加载

评论 #23154870 未加载

free_rms大约 5 年前

Pike's take is pretty unfair to C++11, given how ideas like 'rvalue references' held up REALLY well.Yes, they were introducing even more complexity to a complex language, but how else are they supposed to incorporate better ways of doing things while maintaining backwards compatibility?I suppose one could always just build a new language that doesn't have the historical cruft, but in this case that's Rust and not Go.

ses1984大约 5 年前

>Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive.Whoa, hold it there... inheritance and subclassing are OOP, types is a different subject, right?

评论 #23154309 未加载

评论 #23154889 未加载

评论 #23154524 未加载

acarl005大约 5 年前

Whenever the topic of generics comes up, especially in Go, things seem to devolve into a ragefest about inheritance and OOP. Why? I don't want the mess of inheritance any more than the next chap. I just want generics for algebraic types—a single definition for a List, Set, Map. I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. Algebraic types alone (without inheritance) make things an order of magnitude more expressive.

评论 #23155328 未加载

MereInterest大约 5 年前

For any new language that I learn, my go-to thing to try is to implement 4th-order Runge-Kutta solving of an ODE. This implementation must be usable for both built-in types and user-defined types, and must have reasonable performance for the language.* C++, easily doable with templates.* Python, easily doable with duck typing.* Rust, doable, though with some restrictions. I needed to require the derivative function to return the same type as its input, rather than returning something that can be scalar multiplied and added to the same type as the input.* Java, not possible. Adding/multiplying of built-in types can be done with + and * , but user-defined types require .add() and .multiply()* Go, not possible. Go doesn't support generics, and I'm certainly not going to copy/paste a numeric method once for every system that I examine. Also, same issue as Java with no operator overloading.Complexity has to go somewhere. By aiming for a simple language, Go forces the complexity to be in the developer side instead.

FpUser大约 5 年前

"People who are excited about C++11's new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more."I find Go too limiting and definitely not offering "so much more". The author is probably right mentioning "big teams". Sure if I have whole shebang of programmers each nibbling at small particular task and appropriate budget it will work. But comparing the amount of work per developer per time I can have with more sophisticated "traditional" languages does not put Go in any good standing in my opinion.

greendave大约 5 年前

> What you're given is a set of powerful but easy to understand, easy to use building blocks from which you can assemble—compose—a solution to your problem. It might not end up quite as fast or as sophisticated or as ideologically motivated as the solution you'd write in some of those other languages, but it'll almost certainly be easier to write, easier to read, easier to understand, easier to maintain, and maybe safer.I really like go, and I daresay it makes many things easy to implement and understand, but I do find the flexibility/lack of sophistication allows one to end up writing what amounts to improved C. Great for smaller projects, but surprisingly difficult to manage as it grows.

pot8n大约 5 年前

Golang didn't succeed because it is simple or powerful or any of the, I apologize, nonsense your hear from the Gophers. Golang succeeded because it was the only available relevant option and alternative to the aging Python and Java when the cloud took off in the early 2010s.

评论 #23155183 未加载

评论 #23154862 未加载

评论 #23155436 未加载

评论 #23154629 未加载

oftenwrong大约 5 年前

This does a poor job of justifying the claim that golang is more expressive despite having fewer features than similar languages. I agree to a certain extent that golang's simplicity is an advantage. However, its simplicity does actually make it less expressive.For example, in Java one can trivially create a class like `Maybe<T>` with a method `Maybe<R> map(Function<T, R> mapper)`. This can be used with any classes filling in the parameters. I believe golang is unable to express this.

smoorman1024大约 5 年前

I've been working in golang professionally for about a year now coming from a long career in C++. Although there is some simplicity to golang that can be appreciated things like this below make me think that the premise of less is more is fundamentally incorrect if you cannot accomplish everything that is necessary.<a href="https://github.com/protocolbuffers/protobuf-go/blob/master/internal/pragma/pragma.go#L29" rel="nofollow">https://github.com/protocolbuffers/protobuf-go/blob/master/i...</a>Specifically the last one of embedding an empty array of mutexes into a struct prevents that struct from being copied. This is something that is easily and explicitly accomplished in C++ by making the constructors private.

api大约 5 年前

I love Go for this reason. It minimizes it's own cognitive load, freeing the mind to spend more time thinking about being clever solving the problem rather than being clever with the language.I also adore goroutines and miss them in any other language. They are really fibers and let you do light concurrency without fiddling with async constructions. Async programming is just an ad hoc way of implementing fibers, and it imposes more cognitive load because now you have two different approaches to every problem in the same language (one async, one not).IMHO minimizing language-imposed cognitive load should be a core goal of any programming language. Human brains are finite, and programmers should spend the majority of their mental energy thinking about the problem being solved not the language.

评论 #23159655 未加载

vorpalhex大约 5 年前

I code in Javascript/Node, and I also code in Go. They're both very useful tools and they're useful in different ways. I find Go to be a good tool when I know what I'm writing and I have clear forms in each step.

jasode大约 5 年前

Previous discussion since the HN "past" link doesn't bring up the prior thread because tld was ".de" instead of ".com" : <a href="https://news.ycombinator.com/item?id=6417319" rel="nofollow">https://news.ycombinator.com/item?id=6417319</a>

DLA大约 5 年前

I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world--in-house hosted and cloud.I have immensely enjoyed the "less is exponentially more" philosophy with Go. In Go there is one or a small number of way to do something. Contrast that with C++ where there are any number of ways to do something and at least as many styles of coding. Too much choice results in complexity.IMO the generics debate is overblown. The systems I've build with go tend toward heavy data processing (ETL, correlation, extraction and the like) and service (JSON APIs supporting front-ends; event some front ends with Go Templates). Never once was I like "my life sucks because I don't have generics." Fair and balanced: Processing JSON in Go takes some getting used to, especially when the JSON structure changes. However, there are some good libs to help. It's just a friction point given the typed nature of Go.The operational simplicity of Go cannot be overstated. Go's production of a deployable binary with zero dependencies is a blessing. There's an amazing deploy tool you can use called: cp. Compare that to the library version hell that is C++ (and I'm also a C fan and very experienced dev). No. Thank. You.The cross compilation of Go code works beautifully. Just 2 weeks ago I had to demonstrate a tool to a customer and due to COVID it was virtual. We had problems with MS Teams connecting to our dev platform so literally 15 minutes before the demo I cross-compiled to a Win binary and moved it to the machine hosting the Teams call. Victory.Because of go fmt, all Go code looks the same. That's a massive advantage to read/understand/use OPC (other people's code). Ditto for the automatic documentation generation -- it looks the same and behaves the same across Go projects.I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. It's my opinion, so not up for debate. If Java works for you, by all means have at it. Robust solid technology for sure. Not hating here; just choosing.So, my Go journey has been and continues to be fantastic. It is my preferred platform for pragmatic reasons--the same sort of reasons it was developed by Google in the first place. My team and I can get stuff done quickly. We can scale it. We can leverage all the CPUs on a box running big data processing flows. We can have automatic code-linked documentation and formatted code and can leverage the same from others. We have build in testing. We can make high performance services and servers with ease. We don't have to deal with ridiculous configuration nonsense. We get instant compilations. We get great tool support (vscode + Go for the win). We get a batteries very much included stdlib.And most of all we get a platform that understands and managed complexity in a favorable way.$0.02. Ok, maybe $0.05 (inflation).

评论 #23156520 未加载

westicecoast32大约 5 年前

I'm writing a language. I was wondering what you all suggest it have before you would seriously try it out? I don't think most people cares about syntax; does it need to be attached to a large project?The beta of the last language I wrote had maybe half a dozen fans. I threw away the compiler/language because I didn't really know how to write a compiler back then. I'm writing a new one now

dang大约 5 年前

See also:<a href="https://news.ycombinator.com/item?id=16548684" rel="nofollow">https://news.ycombinator.com/item?id=16548684</a> (2018)<a href="https://news.ycombinator.com/item?id=6417319" rel="nofollow">https://news.ycombinator.com/item?id=6417319</a> (2013)Discussed at the time: <a href="https://news.ycombinator.com/item?id=4158865" rel="nofollow">https://news.ycombinator.com/item?id=4158865</a>