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

641–650 of 670 posts

Re: Toward Go 2

#641

Post by baq »

tome wrote: post #637
rbehrends wrote: post #307

Earlier quoted context omitted.

No, there's more to it. There's been some research in recent years on the actual benefits of types and the results are less straightforward than some people think. An important aspect of type annotations, for example, seems to be that they help document the API of a module, regardless of whether they're statically checked. This is especially relevant with respect to maintenance tasks. Conversely, the benefits of stat…

> There seems to be a cost associated with static types and that is that it takes longer to write code Perhaps. As someone who has used Python and Haskell for roughly equal amounts of time in my professional career I definitely find Haskell faster to write in.

mypy is getting good (from haskell's perspective that would be 'barely passable', still a great improvement from what it used to be), been using it actively for the last year and advocating it for 6 months and seeing nice ROI even considering it's warts.

Re: Toward Go 2

#642

Post by slavapestov »

dbaupp wrote: post #345
slavapestov wrote: post #294

Earlier quoted context omitted.

I think the main difference is that the Swift approach ends up being more memory-efficient, eg consider Swift's Array is stored as an array of integer values compared to a Java's ArrayList where each element is boxed. Also the Swift optimizer can clone and specialize generic functions within a module, eliminating the overhead of indirection through reified metadata.

Yes, there's some pitfalls of Java that Swift avoids, like compulsory allocation, but it fundamentally has the same style of indirection (often pointers to stack memory rather than heap, but still pointers), type erasure and pervasive virtual calls, and brings with it even more virtual calls due to needing to go through the value witness table to touch any value (which might be optimised out... or might not, especall…

Oh, hi Huon.

Re: Toward Go 2

#643

Post by slavapestov »

dbaupp wrote: post #337
slavapestov wrote: post #289

Earlier quoted context omitted.

"Dictionary passing" is a good term for this implementation strategy, I haven't heard it named before. Do you know of any other languages that take a similar approach?

Haskell and Ocaml, e.g. http://okmij.org/ftp/Computation/typeclass.html .

I thought Ocaml still boxed values, so there's no equivalent of value witness tables?

Re: Toward Go 2

#644

Post by Sean1708 »

vram22 wrote: post #632
Sean1708 wrote: post #604

Earlier quoted context omitted.

Would you mind going into a bit more depth about Eiffel's generics? It's not obvious to me from Wikipedia how they differ from normal parametric polymorphism.

Did you read this, which is linked to from my earlier link? https://en.wikipedia.org/wiki/Generic_programming#Genericity... I may not be able to throw more light on it than that, sorry, since I'm not an expert on these areas, just interested.

Thanks, I completely missed that "Basic/Unconstrained genericity" was a subsection of "Genericity in Eiffel" when I first saw that page.

Re: Toward Go 2

#645

Post by vram22 »

Sean1708 wrote: post #644
vram22 wrote: post #632

Earlier quoted context omitted.

Did you read this, which is linked to from my earlier link? https://en.wikipedia.org/wiki/Generic_programming#Genericity... I may not be able to throw more light on it than that, sorry, since I'm not an expert on these areas, just interested.

Thanks, I completely missed that "Basic/Unconstrained genericity" was a subsection of "Genericity in Eiffel" when I first saw that page.

NP.

Re: Toward Go 2

#646

Post by TheDong »

JepZ wrote: post #299
masklinn wrote: post #23

Earlier quoted context omitted.

> I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go. That's inane and insane. Java generics do almost nothing, they don't even exist at runtime in a language with (much like Go) heavy runtime semantics. Here's what Java's generics do: get typechecked, and insert implicit casts. > Yes, I am sure there are more container formats First, you f…

> What does that mean? It is not easy enough what? To write containers? To have generics? Actually, I meant it is not easy enough to build container formats (maybe due to the lack of generics). Btw. I will not continue this conversation as I am tired of getting insulted (inane and insane), getting downvoted for merely asking questions and you editing your post without labeling it. Just saying.

> I will not continue this conversation ... getting downvoted for merely asking questions

You didn't ask a question. You didn't include a single question mark.

What you said was a jumble of misleading and wrong words.

Re: Toward Go 2

#647

Post by e3b0c »

dgacmu wrote: post #442

I should send this to rsc, but it's fairly easy to find examples where the lack of generics caused an opportunity cost. (1) I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago. I quit. You can probably guess why from the comments at the top of the file about boxing things with interface{}. It just got slow and gross, to the point where libcuckoo-go was slower and more bloate…

Sounds like https://github.com/golang/go/issues/19335

I guess the performance issue has something to do with some missing optimizations. Hopefully it will get better.

Edit: Also https://github.com/golang/go/issues/19361

Re: Toward Go 2

#648

Post by adrianratnapala »

mathw wrote: post #512
adrianratnapala wrote: post #489

Earlier quoted context omitted.

Even if you don't care about binary bloat (and I do care), it can introduce some of the same problems as dynamic typing. If I am debugging some C++, and I find myself looking at templated function, then I can't easily see what types the template parameters are. Also it becomes hard to navigate to method calls etc. C++ is a particularly bad example, because template metaprogramming is essentially typeless. But any for…

Since C++ monomorphises every single template instantiation in a program, your debugger certainly should be able to tell you what the type parameters for that instance were!

In my line of work I am very rarerly actully looking at a running executable with an interactive degger.

More often I am navigating through source code comparing it to logs, stack traces and other evidence that I can grab of what went wrong in production.

The source-level is important, because although I said "debugging" in my comment, what that very often comes to is first figuring out the intent of some other engineers from the thing they wrote -- and what they wrote is the source code, not the program state.

Re: Toward Go 2

#649

Post by michaelcampbell »

tschellenbach wrote: post #112

The beauty of Go is that you get developer productivity pretty close to Ruby/Python levels with performance that is similar to Java/C++ Improvements to package management is probably the highest item on my wishlist for Go 2.

> The beauty of Go is that you get developer productivity pretty close to Ruby/Python levels ...

I'm curious as to what metric you use for "developer productivity", and the values of said metric you can cite for the 3 languages you list.

Re: Toward Go 2

#650

Post by frik »

sethammons wrote: post #576
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

I use one GOPATH and work on dozens of projects. I would hate it if I had to change GOPATH often. In Go, if you find yourself fighting the system, chances are you are doing it wrong. 'go get github/user/project && cd $GOPATH/github/user/project'. And to avoid dependency issues, I use one of the many vendoring tools. Currently 'govend'.

You are limited to one repository. So all your Go projects have to live in one repo.

That's the issue, and it's a big design flaw - do away with this GOPATH

Post reply on HN