Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Less is exponentially more

commandcenter.blogspot.com

Post reply on HN
Print view View original

81–90 of 124 posts

Re: Less is exponentially more

#81

Post by eta_carinae »

> What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types.

Rob Pike seems to be doing a kind of programming unlike what most developers do. I fill, empty, filter and analyze values in containers all the time, and I suspect I'm not the only one.

> C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way. > The issue, then, is that Go's success would contradict their world view

I'm disappointed that the only justification that he can find to explain why C++ programmers are not embracing Go is "C++ programmers don't get it".

Re: Less is exponentially more

#82

Post by eta_carinae »

zaphar wrote: post #56
pufuwozu wrote: post #33

Earlier quoted context omitted.

Atlassian is on that list but I know that last year we rewrote our Go code to Python after our main Go developer left.

I've never understood this kind of action. Go is so small you could hold the spec in your hand and it's going to be faster and more efficient than python as well as safer to modify thanks to type safety. If it were haskell, or a similarly difficult language to wrap your head around, I could see wanting to rewrite to something easier to understand. But Go has none of those problems. What could possibly motivate a rewr…

> Go is so small you could hold the spec in your hand and it's going to be faster and more efficient than python as well as safer to modify thanks to type safety.

I think it's very naive to think that the value of a language in a corporation is limited to its syntax or compilation speed.

Re: Less is exponentially more

#83

Post by salimmadjd »

I was at the GoSF meetup. It was great seeing Rob talk and I think many of you are taking this blog post a bit out of context. The gist of his talk was about the philosophy and history behind creating Go.

For me the talk made me more convinced to switch over to Go. I'm a believer that makings things simple is a lot hard than making things complex and I really appreciate the deliberate approach of the Go team regarding adding features. I really hope they stay true to Rob's philosophy of less is more for years to come.

Re: Less is exponentially more

#84

Post by eta_carinae »

enneff wrote: post #36
rogerbinns wrote: post #32

I'm still of the opinion they made a mistake by not having exceptions. When programming in Python exceptions are wonderful because they let me put error handling code in the appropriate place without having to litter all the intermediary code to where errors happen with error flags. (Panic is not the same thing.) The usual complaint about exceptions is "expense", but the same claims can be made about gc. The Go FAQ i…

The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about. In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief. In short, we didn't include exceptions becaus…

> In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief.

I'm sorry but you are on the wrong side of history on this question (and I happen to think you're also wrong in your characterization of exceptions).

Forcing callers to deal with error numbers right here right now only gives you the illusion of clarity and robustness but it gives you neither.

Every Go program I read is littered with "err,ok := Foo(); if err {}" every ten lines or so. It's brutally verbose and hides the intent of the code.

And it also forces callers to handle error codes that they might not be able to, while a caller a few stack frames above would do a much better job at it.

We learned all these lessons in the 90's, pity Go chose to ignore them.

Re: Less is exponentially more

#85

Post by eta_carinae »

enneff wrote: post #66
rogerbinns wrote: post #54

Earlier quoted context omitted.

True, but so what. The code I like the best is the code I don't even have to write. Having to write all the intermediary code between where an exception happens and where I'd like to handle it is annoying. And the "understanding" argument applies to other things, such as using a compiled language instead of assembly or GC instead of manual memory allocation.

That's funny. I don't mind writing code. The code I like the best is the code I don't have to debug .

> I don't mind writing code.

You should mind writing code that the compiler can write for you, which is exactly what you do when you don't have exceptions (you simulate bubbling up the error manually).

Re: Less is exponentially more

#86

Post by ericbb »

jbellis wrote: post #70
enneff wrote: post #65

Earlier quoted context omitted.

You don't need to pick one of those three. Maps and arrays cover most cases. The rest of the time you can implement capabilities on your types (touched on in the article) and do some type assertions. The really odd thing about the original statement is that this guy "can't imagine" working without generics. That is a remark that could only be made by someone who is fixated on modeling all problems in terms of type sy…

It's not an unreasonable way to view the world, though. "Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious." -ESR, paraphrasing Fred Brooks

data structure != type

Re: Less is exponentially more

#87

Post by franzus »

munificent wrote: post #19

I think as working programmers, we end up torn between two opposing perspectives with our tools (i.e. programming languages, editors, language features): On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing…

> Simplicity is a virtue worth striving for

I think simplicity is a virtue you should strive for in your designs. How complex, messy, dirty your tools are which you use to create those simple designs doesn't really matter.

In the end you don't see the 2 dozen different kinds of tools a master craftsman used to create the beautiful desk. Nothing dirty and blue collar about that.

Re: Less is exponentially more

#88

Post by batista »

pessimist wrote: post #59

Go has some really great features, I've written a few thousand lines in it and enjoyed it, but there are some strange hangups that the go designers have that in the end make me think its going to go nowhere. 1. Rob Pike is immensely proud that the language has no generics, but this means that in the last 2 years, there isnt a proper implementation of a linked list that can hold an arbitrary type, or a min-heap, an or…

That.

It's nice for languages to have a "benevolent dictator", but Go insists in a lot of arbitrary but not that good choices like the above.

I would add the bizarro build system (go build et al), that if you want to use you have to follow some rather silly conventions (a little flexibility would go a long way).

The GC also leaves a lot to be desired --they will implement something better eventually, but why wasn't that a top priority in 2012 for a "server systems" language? On 32 bits you are mostly toast with OOM errors, but even on 64 bit the GC is simplistic compared to most modern languages. YouTube, for example, had to jump through several hoops with memory issues to use Go in front of MySQL.

And, while the results are faster than Python/Ruby, they are not that competitive with C/C++ or even Java. The "20% slower than C" claim that you'll read is mostly BS. YMMV.

It doesn't help that if anybody brings up those issues, the general sentiment from the Go community (lists, etc) is also: "you're doing it wrong, reverse course, Go is perfect".

That said, I like Go, if it improves a bit with a 2.0 version, it can go places...

Re: Less is exponentially more

#89

Post by msz-g-w »

jbellis wrote: post #73
enneff wrote: post #36

Earlier quoted context omitted.

The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about. In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief. In short, we didn't include exceptions becaus…

I'm with the grandparent. Every language that I've used that was created after C has included exceptions, and never once have I missed checking errno. I can understand why, coming from a C++ context, you'd want to avoid them like the plague, but other languages (Python, Java, Smalltalk, ...) do a good job of making them a first-class citizen in the language, which saves a LOT of boilerplate typing. Seeing call stacks…

Did you miss the part where he says: "We weren't trying to design a better C++, or even a better C. It was to be a better language overall for the kind of software we cared about."

Re: Less is exponentially more

#90

Post by batista »

enneff wrote: post #62
pessimist wrote: post #59

Go has some really great features, I've written a few thousand lines in it and enjoyed it, but there are some strange hangups that the go designers have that in the end make me think its going to go nowhere. 1. Rob Pike is immensely proud that the language has no generics, but this means that in the last 2 years, there isnt a proper implementation of a linked list that can hold an arbitrary type, or a min-heap, an or…

Allow me to respond to your points. 1. Your characterization of Rob's position on generics is not at all accurate. The Go team's view, in a nutshell, is that generics would offer some exciting possibilities for Go (particularly when combined with its concurrency model) but that it is also extremely hard to do generics well. We have put a huge amount of work into defining and refining Go, and we don't want to break it…

>There are plenty of "proper implementations" of these collection classes. Your only criticism of them seems to be that they are not type safe. But it is trivial to implement a type safe wrapper around such containers, if you desire it. So the situation is perhaps a little cumbersome, but no worse than C.

"no worse than C" doesn't sound particularly enticing.

>The Go language and libraries, by contrast, are amazingly regular. This is not just my opinion, but the feedback that I receive consistently from Go programmers around the world.

Selection bias?

Post reply on HN