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

Simplicity and the ideas Go left behind

sourcegraph.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Simplicity and the ideas Go left behind

#81

Post by masklinn »

qznc wrote: post #80
kazagistar wrote: post #78

Earlier quoted context omitted.

I dunno about smalltalk, but Scheme and Forth start off simple until a programmer writes tens of thousands of lines of code, at which point it gets harder to read and follow the code exactly.

No matter how much convoluted code your write, it is still a "simple language". Your code however is not necessarily simple or easy.

That tends to be the flip side of the "simple language".

And at least the 3 languages quoted are so simple that they must provide the tools for building new abstractions (which are the tools for building the language in the first place), so you can cut down on code by building a reusable toolbox of abstractions.

Go is complex enough that they can get away without that, and even get praised for pushing the complexity to userland code and providing no way for users to manage that complexity.

Re: Simplicity and the ideas Go left behind

#82

Post by Daishiman »

crawshaw wrote: post #42
Daishiman wrote: post #35

Earlier quoted context omitted.

This is my own personal opinion on core dev's position and no one else's, but to me generics and dependency management have always been the pink elephant in the room. I can wait for features; I'm patient. But the downright refusal of Go's core team to even begin to address this issue is not just a technical problem, but a communications one. This is clearly big for a lot of people, and I have yet to see any serious r…

Several members of the Go team have put a lot of time into studying and prototyping various implementations of generics. If you look through the mailing list archives you will find many emails from Ian Lance Taylor on the topic.

I'll be completely honest: it's one of the most BS reasons I've ever read in a technical discussion.

How can we talk about high performance when:

* The current "generics" mechanism (interface et al) does runtime introspection, which is just about as slow and unwieldy as it gets * There is no option for pervasive, truly high-performance data structures since everything is a map (which comes with its own type parametrization as an exception to everything else), and if you don't like the hashing algorithm, tough luck. * You have a garbage collector running in the background, which is barely tunable compared to the options other runtimes have

Talking about performance when it's convenient as an argument against generics but disregarding the other holes in the language is not reasonable, because I would say that the choice of implementation for native maps is probably far more important for high performance. Yet here we are, no one complaining.

So we can really discard the performance argument, thus there is now an ample, valid set of choices for generic programming, several of which don't go against the goals of fast compilation.

Speaking of fast compilation; pretty much everything is going to be faster than C++ templates, since the entire compilation chain in C++ is slow.

Re: Simplicity and the ideas Go left behind

#83

Post by kmontrose »

rakoo wrote: post #72
kmontrose wrote: post #9

This oversells golang's simplicity I think. Not a lot, but enough to rub me the wrong way a tiny bit. --- > Go programs are built from just their source, which includes all the information needed to fully build the program. Still have to deal with GOPATH, vendor your dependencies, and have everything a `go generate` comment wants to invoke. It's certainly better than makefiles, but it's hardly just the source. > C# i…

> Still have to deal with GOPATH Once , when you install Go. Then for each project, put your stuff where you want and symlink from $GOPATH to where it is. Once per project. There really is minimum hassle to integrate the recommended flow.

You also install runtimes once for other languages.

GOPATH isn't awful, but it's something more than "just source" as claimed in the article; which is my point. Go is simple, but not as simple as claimed.

Re: Simplicity and the ideas Go left behind

#84

Post by crawshaw »

Daishiman wrote: post #82
crawshaw wrote: post #42

Earlier quoted context omitted.

Several members of the Go team have put a lot of time into studying and prototyping various implementations of generics. If you look through the mailing list archives you will find many emails from Ian Lance Taylor on the topic.

I'll be completely honest: it's one of the most BS reasons I've ever read in a technical discussion. How can we talk about high performance when: * The current "generics" mechanism (interface et al) does runtime introspection, which is just about as slow and unwieldy as it gets * There is no option for pervasive, truly high-performance data structures since everything is a map (which comes with its own type parametri…

It would be unreasonable to have designed a generics implementation into Go 1 that did not cover the builtin polymorphic map, slice, and append. A simple set of orthogonal features is an important principle in Go.

For these, performance is most certainly critical.

Re: Simplicity and the ideas Go left behind

#85

Post by steveklabnik »

NateDad wrote: post #76
bsder wrote: post #11

Earlier quoted context omitted.

I like the fact that the Go guys continue to avoid talking in detail about Rust and Clojure. That tells me that the don't think they can win the comparison.

The core goals behind Rust and Clojure are very different from those behind Go. This article/presentation would not be appropriate for those languages. I don't think anyone would say that Rust or Clojure are simple languages, or that simplicity is a core goal for them. Rust's core goals are performance, memory safety, and lack of race conditions (AFAICT). And clojure is a LISP which puts it in its own category, reall…

> Rust's core goals are performance, memory safety, and lack of race conditions (AFAICT)

We usually formulate this as "memory safety without garbage collection," which has secondary implications on speed and concurrency, but yes. (Also, 'data races' rather than 'race conditions,' technically).

Re: Simplicity and the ideas Go left behind

#86

Post by seanmcdirmid »

peterfirefly wrote: post #70
Padding wrote: post #61

Earlier quoted context omitted.

> despite decades of working solutions Which "working" solutions? Has anyone solved creating a type system that offers OO/inheritance, generics, mutability and isn't mind-bogglingly complex? What is your definition for a "working" solution? I don't think any of the current languages we have fit this description, since all of them are capable of producing type errors that are way too complex to comprehend. > with a my…

What would you want OO for? First-class functions + HM + typeclasses work fine.

Unification is not a substitute for semi unification.

Re: Simplicity and the ideas Go left behind

#87

Post by NateDad »

steveklabnik wrote: post #85
NateDad wrote: post #76

Earlier quoted context omitted.

The core goals behind Rust and Clojure are very different from those behind Go. This article/presentation would not be appropriate for those languages. I don't think anyone would say that Rust or Clojure are simple languages, or that simplicity is a core goal for them. Rust's core goals are performance, memory safety, and lack of race conditions (AFAICT). And clojure is a LISP which puts it in its own category, reall…

> Rust's core goals are performance, memory safety, and lack of race conditions (AFAICT) We usually formulate this as "memory safety without garbage collection," which has secondary implications on speed and concurrency, but yes. (Also, 'data races' rather than 'race conditions,' technically).

Thanks for clarifying :) Yes, I should be more careful about specifying data races vs. race conditions :)

Re: Simplicity and the ideas Go left behind

#88

Post by frou_dh »

NateDad wrote: post #76
bsder wrote: post #11

Earlier quoted context omitted.

I like the fact that the Go guys continue to avoid talking in detail about Rust and Clojure. That tells me that the don't think they can win the comparison.

The core goals behind Rust and Clojure are very different from those behind Go. This article/presentation would not be appropriate for those languages. I don't think anyone would say that Rust or Clojure are simple languages, or that simplicity is a core goal for them. Rust's core goals are performance, memory safety, and lack of race conditions (AFAICT). And clojure is a LISP which puts it in its own category, reall…

> I don't think anyone would say that .... Clojure is simple language, or that simplicity is a core goal for it.

Good god you are so wrong.

Watch yourself some of Rich Hickey's trove of excellent presentations, including the one where he breaks down the detailed etymology of the word "simple" and how much he strives for that.

http://www.infoq.com/presentations/Simple-Made-Easy

Re: Simplicity and the ideas Go left behind

#89

Post by 4ad »

SixSigma wrote: post #68
lmm wrote: post #60

Earlier quoted context omitted.

Static binaries are bad design as soon as a library has a security flaw. Remember when there was a double free in zlib and Apple had to release a 1.3GB patch to update everything that linked it in statically - and even that only fixed the problem for Apple-official programs, not for anything the user had installed?

recompiling all of plan9 takes about 15 minutes

Actually recompiling Plan 9 takes about 60 seconds on my current Thinkpad.

Re: Simplicity and the ideas Go left behind

#90

Post by ngrilly »

Daishiman wrote: post #35
davecheney wrote: post #26

Earlier quoted context omitted.

I am not a member of the Go team, just a contributor. I represent only my own opinions, please don't put words into my mouth.

This is my own personal opinion on core dev's position and no one else's, but to me generics and dependency management have always been the pink elephant in the room. I can wait for features; I'm patient. But the downright refusal of Go's core team to even begin to address this issue is not just a technical problem, but a communications one. This is clearly big for a lot of people, and I have yet to see any serious r…

If you haven't found any "serious response", maybe it's because you haven't searched enough.

Here is a "clear, detailed, not demeaning, and constructive" answer of Ian Lance Taylor that addresses your concerns:

https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwG...

I would guess his answer will not suit you, but you can hardly argue the Go team ignores the issue or refuses to talk about it.

Post reply on HN