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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

471–480 of 670 posts

Re: Toward Go 2

#471

Post by concede_pluto »

pcwalton wrote: post #462
spyspy wrote: post #426

Earlier quoted context omitted.

It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.

If that's the case, then the Go community is wrong. For loops do not get the job done easily enough. I've lost count of the number of times I've had to do contortions in order to count backwards inclusive down to zero with an unsigned int. With a proper iterator API, it's trivial. Furthermore, for loops are a pain to optimize. They encourage use of indices everywhere, which results in heroic efforts needed to elimina…

It's also strange that a language that wants to encourage parallelism requires for loops, and specifies that they always run sequentially. Java 8 can put map/reduce with a thread pool in the standard library precisely because it doesn't use a for loop; imagine how tedious and repetitive the Go version would be: https://docs.oracle.com/javase/tutorial/collections/streams/...

Re: Toward Go 2

#473

Post by rmrfrmrf »

Sorry, but if "a major cloud platform suffers a production outage at midnight" is the bar for effecting change in Go, then I want no part of it.

Re: Toward Go 2

#474

Post by concede_pluto »

baq wrote: post #314
hdhzy wrote: post #154

Earlier quoted context omitted.

So... Just like checked exceptions in Java?

yeah but better because you don't break the world if you add a new exception to a public method.

Declaring that every method throws Exception doesn't break the world any more than every Go function returning an argument of type error. You're intentionally saying pretty much anything could go wrong and nobody can plan ways to recover.

Re: Toward Go 2

#476

Post by frik »

cdelsolar wrote: post #298
Spiritus wrote: post #296

Earlier quoted context omitted.

Except you have to set it every time you open a shell. You can’t put it into your .bashrc either unless you only ever work on one project. This workflow sucks: $ cd projects/foo $ export GOPATH=$PWD $ cd src/github.com/company/foo $ go build

OP was talking about getting started. I also don't understand why you can't use the same GOPATH across multiple projects, especially with godeps?

Multiple unrelated Go projects in different GIT/SVN repositories. GOPATH experience is painful.

Re: Toward Go 2

#477

Post by epoch1970 »

artursapek wrote: post #63
frik wrote: post #41

Earlier quoted context omitted.

++ Now we have at least vendor. But this alien-style fixed paths is really annoying - no other language forces such GOPATH crap. Please remove this limitation from Go 2!

What exactly is wrong with GOPATH? I find it much easier to reason about than imports in say Ruby or Python, which are global names with no hierarchy and are resolved in much less obvious ways.

The thing I dislike is how such languages try to abstract away the filesystem representation of packages/modules/libraries/etc.

The conventions and resolution approaches that are needed to accomplish this often end up being opaque, less flexible, and harder to work with.

I much prefer the approach of C, C++, and even PHP to some extent, where the interaction with the filesystem isn't hidden.

When using C or C++, it's trivial to reference a globally-installed library, such as the standard libraries of such languages. It's also simple to reference third-party libraries, or even to include local copies of third-party libraries within one's own source tree. Relative or even absolute paths can easily be specified when referencing external code.

This also gives so much more flexibility with regards to how a project is laid out, and how it pulls in other code or libraries it depends on. I can follow an approach that works for me, for my project, for my team, for my version control system, for my development environment, for my deployment environment, and so on.

I want the language to conform to my needs. I don't want to have to modify my behavior and my environments to conform with what the language's developers deem to be the "right way" of doing things, especially when this isn't compatible with my needs.

Maybe this means there's slightly less consistency with how libraries and dependencies are handled across projects and libraries, but that's a cost that I'm willing to pay, and in practice it actually isn't that much of an issue when using languages like C and C++.

I'd much rather spend a few seconds specifying "-I" and "-L" and "-l" options when compiling or linking than trying to remember a bunch of conventions or how the high level package names end up mapping to the installed modules or libraries.

I'm not saying that the C approach is perfect, or that I'd want other languages to use a C preprocessor like approach of actually combining separate source files just prior to compilation or even execution.

But I would really like it if modern languages didn't try to hide the existence of files and directories so much, and didn't try to force conventions on me. I'd rather deal with the very small cost of explicitly telling the compiler where to find dependencies rather than relying on conventions or opaque resolution processes.

Re: Toward Go 2

#478

Post by rsc »

pjmlp wrote: post #67
crawshaw wrote: post #5

Earlier quoted context omitted.

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.

Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.

FWIW I have Liskov and Guttag (1986) on my desk. I haven't forgotten. I also explicitly address the "several since those days" in https://research.swtch.com/go2017#generics.

Re: Toward Go 2

#479

Post by rsc »

spyspy wrote: post #426
vec wrote: post #291

Earlier quoted context omitted.

I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn ` instead of half a dozen variations on `sq…

It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.

> It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused.

There is a germ of truth here - sometimes list comprehensions make code harder to understand than if you just wrote an if statement or a loop - but you've overgeneralized. I don't think anyone on the core Go team seriously thinks that map and reduce are bad ideas when Google relies so heavily on MapReduce (and its successors).

Re: Toward Go 2

#480

Post by jnwatson »

spyspy wrote: post #426
vec wrote: post #291

Earlier quoted context omitted.

I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn ` instead of half a dozen variations on `sq…

It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.

"Ability to abuse" isn't a good criteria for language design. I've seen plenty of abuse of Go channels, but I'm not going to make the argument you should remove them.

Python's comprehensions are among the most powerful, easy to use, concise capabilities of any language I've used. You can address the abuse issue with coding guidelines: no more than 2 deep. Done.

Post reply on HN