Rob Pike: Simplicity Is Complicated [video] • Hacker News Board

Re: Rob Pike: Simplicity Is Complicated [video]

#101

Post by kibwen » Thu, Dec 03, 2015, 3:47 PM UTC

Peaker wrote: post #47

chubot wrote: post #8

From reading the abstract, it sounds like this addresses precisely the topic of "Worse is Better" [1]. There are frequent misunderstandings of this essay -- the argument isn't as coarse as "crappy software wins", or "release early and often". The tradeoff is: do you want a simple interface (MIT style) or a simple implementation (NJ style)? If you want a simple interface, you have to hide a bunch of complexity underne…

Go is a simple language, with 1970's features. It is very easy to implement, and leaves a lot of the complexity (null pointers, generics, etc) to the user instead of solving it in the language. This is a classic example of worse-is-better. An MIT-style language would be Rust, which indeed struggled to get to v1.0 and Go vs. Rust plays out quite similarly to what worse-is-better would predict.

"Go vs. Rust" is not a valuable comparison because Go and Rust have wildly divergent goals and intended use cases. By the same token you could argue that Rust is a worse-is-better Haskell.

Re: Rob Pike: Simplicity Is Complicated [video]

#102

Post by kibwen » Thu, Dec 03, 2015, 3:52 PM UTC

Peaker wrote: post #76

catnaroek wrote: post #64

Earlier quoted context omitted.

> This is a classic example of worse-is-better. C won over Lisp, not because “worse is better”, but because the C's advantages over Lisp (performance on cheap machines) were more pronounced than the other way around (“safety” achieved by means of lots of runtime checking - by no means was it possible to statically rule out errors). Lispers fancy their language of choice the pinnacle of computer science, but the falsi…

I agree with everything you said :) I also think Lisp is not truly "better" in the sense "worse-is-better" is ascribing. But if we suspend disbelief - then the Go vs. Rust story matches the one described in "Worse is better". Perhaps Rust will win out in the end and "worse is better" won't prevail. Despite liking the idea of Rust very much, I don't think it will.

This worldview is overly simplistic. There is no indication that languages ever "win out in the end" and there is no reason to suspect that the industry is not large enough to support healthy ecosystems for both Go and Rust, who, again, are not competitors.

Re: Rob Pike: Simplicity Is Complicated [video]

#103

Post by kibwen » Thu, Dec 03, 2015, 3:56 PM UTC

bjwbell wrote: post #58

Peaker wrote: post #47

Earlier quoted context omitted.

Go is a simple language, with 1970's features. It is very easy to implement, and leaves a lot of the complexity (null pointers, generics, etc) to the user instead of solving it in the language. This is a classic example of worse-is-better. An MIT-style language would be Rust, which indeed struggled to get to v1.0 and Go vs. Rust plays out quite similarly to what worse-is-better would predict.

There isn't one language to rule them all. An advantage of Go over Rust is easier tooling due to a simpler language, an advantage of Rust is a richer type system. These are in opposition.

A richer type system is not in opposition to good tooling, quite the opposite. Rust's strong type system enables fantastic static analysis, which, for example, obviates the need for anything like Go's data race detector.

Re: Rob Pike: Simplicity Is Complicated [video]

#104

Post by ngrilly » Thu, Dec 03, 2015, 4:04 PM UTC

kibwen wrote: post #103

bjwbell wrote: post #58

Earlier quoted context omitted.

There isn't one language to rule them all. An advantage of Go over Rust is easier tooling due to a simpler language, an advantage of Rust is a richer type system. These are in opposition.

A richer type system is not in opposition to good tooling, quite the opposite. Rust's strong type system enables fantastic static analysis, which, for example, obviates the need for anything like Go's data race detector.

One thing that can make tooling difficult in Rust are macros.

Re: Rob Pike: Simplicity Is Complicated [video]

#105

Post by zaphar » Thu, Dec 03, 2015, 4:06 PM UTC

lIlIlIlIIlI wrote: post #74

I can't even begin to measure the amount of time I've wasted trying to make go code look as concise as what I can have trivially in C where things like macros and do { } while() are available. Instead of "simplicity" saving me time as Mr. Pike suggests, it leaves me dissatisfied with the results after wasting my time in attempts to prevent my dissatisfaction. This probably isn't an issue for someone new to programmin…

As someone who reads far more C code than I write. Those macros you seem to be missing infuriate me. They hide far too much from me when I'm trying to understand the code I'm reading.

And as far as do and while go, why would you hide part of the state determining when you're loop exits at the end of the loop just to save a few lines at the top. I am going to naturally try to read your code from top to bottom not top to bottom to top. The more you make me skip around the longer it will take me to understand what you are doing. 90% of my job is maintaining code not writing new code. Programmers who write as if that isn't the case just make the long term cost of maintaining the software they write larger.

Re: Rob Pike: Simplicity Is Complicated [video]

#106

Post by throwaway999888 » Thu, Dec 03, 2015, 4:15 PM UTC

eronhp wrote: post #60

pjmlp wrote: post #51

Earlier quoted context omitted.

Which is hilarious given Google´s hiring processes. Any genius that is able to invert binary trees on whiteboards, count the balls on a vending machine, do a C++ compiler course, describe the random code in a magazine, .... Can surely cope with a modern programming language.

I think it was meant as jab on the audience and the general public, more like "Not even google engineers can appreciate a brilliant language, so who the hell you think you are?"

In which case it is even more arrogant.

Re: Rob Pike: Simplicity Is Complicated [video]

#107

Post by bjwbell » Thu, Dec 03, 2015, 4:20 PM UTC

kibwen wrote: post #103

bjwbell wrote: post #58

Earlier quoted context omitted.

There isn't one language to rule them all. An advantage of Go over Rust is easier tooling due to a simpler language, an advantage of Rust is a richer type system. These are in opposition.

A richer type system is not in opposition to good tooling, quite the opposite. Rust's strong type system enables fantastic static analysis, which, for example, obviates the need for anything like Go's data race detector.

Perhaps I should have said it's easier to write tooling. C++ has arguably very good tooling but creating it was difficult.

For Rust and Go the example I'm thinking of is rustfmt and gofmt.

Re: Rob Pike: Simplicity Is Complicated [video]

#108

Post by kibwen » Thu, Dec 03, 2015, 4:35 PM UTC

bjwbell wrote: post #107

kibwen wrote: post #103

Earlier quoted context omitted.

A richer type system is not in opposition to good tooling, quite the opposite. Rust's strong type system enables fantastic static analysis, which, for example, obviates the need for anything like Go's data race detector.

Perhaps I should have said it's easier to write tooling. C++ has arguably very good tooling but creating it was difficult. For Rust and Go the example I'm thinking of is rustfmt and gofmt.

Writing tooling for C++ is difficult because of how entangled all the language's features are (and its wonky grammar certainly doesn't help). In addition C++'s type system is probably even weaker than Go's, having inherited a lot of slop from C.

That said, if you're talking about source code formatters, I'm pretty sure that clang-format predates gofmt (and surely clang-format was not the first automatic source code formatter for C++). The coup for Go was that they got the community at large to standardize upon and champion gofmt, which is not something that C++ has ever matched.

Re: Rob Pike: Simplicity Is Complicated [video]

#109

Post by kibwen » Thu, Dec 03, 2015, 4:36 PM UTC

ngrilly wrote: post #104

kibwen wrote: post #103

Earlier quoted context omitted.

A richer type system is not in opposition to good tooling, quite the opposite. Rust's strong type system enables fantastic static analysis, which, for example, obviates the need for anything like Go's data race detector.

One thing that can make tooling difficult in Rust are macros.

Indeed, though macros are not a feature of the type system. :)

Re: Rob Pike: Simplicity Is Complicated [video]

#110

Post by bjwbell » Thu, Dec 03, 2015, 4:53 PM UTC

kibwen wrote: post #108

bjwbell wrote: post #107

Earlier quoted context omitted.

Perhaps I should have said it's easier to write tooling. C++ has arguably very good tooling but creating it was difficult. For Rust and Go the example I'm thinking of is rustfmt and gofmt.

Writing tooling for C++ is difficult because of how entangled all the language's features are (and its wonky grammar certainly doesn't help). In addition C++'s type system is probably even weaker than Go's, having inherited a lot of slop from C. That said, if you're talking about source code formatters, I'm pretty sure that clang-format predates gofmt (and surely clang-format was not the first automatic source code f…

I'm thinking more of difficulty in writing rustfmt compared to gofmt. There's other examples like go-oracle or goimports which as far as I know don't have Rust equivalents.

How useful the extra tooling is, I don't really know.