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

561–570 of 670 posts

Re: Toward Go 2

#561

Post by majewsky »

oblio wrote: post #277
trishume wrote: post #244

Earlier quoted context omitted.

Multicore OCaml is in the works and is looking amazing, but is indeed a ways away. They're taking their time and doing it properly so things are fast and safe.

The thing is, until it's shipped, it's still vaporware for most people, especially if they want to use it in a commercial setting. KDE 4 was released in 2008 and it was supposed to be ported to Windows. We're in 2017 and KDE 5 is still far from being considered stable on Windows. And I'm sure you can also think of many examples of programs promised and never delivered or underdelivered.

> was supposed to be ported to Windows

It was ported to Windows. I cannot check the remarks about stability because I use Linux, but it sounds plausible. There's only a handful (maybe 2 or 3) developers working on Windows support in their spare-time AFAIK. I would guess that KDE had anticipated more Windows developers joining the project as it progressed towards maturity.

That's always the problem with open-source projects: It's very hard to do planning and forecasting with a bunch of volunteers. Even if they commit to a roadmap, there will always be someone who has to step down because of private issues (new job, new child, etc.). Go is in a much better position since Google has headcount assigned to it (again, AFAIK).

Re: Toward Go 2

#562

Post by pjmlp »

loup-vaillant wrote: post #558
why-el wrote: post #416

Earlier quoted context omitted.

Ok, thanks for the clarification. I wonder if there are situations in big teams in which one team that uses generics can take a look at a large Go codebase within the same company and see what they think? They must have received such feedback at Google, surely?

Most probably. But they might ignore it anyway. There's at least one high profile example: the standard library itself. It must have been obvious by the time they designed the standard library, before the language was out. They had to have feedback then, just look at the trail of rage against the absence of generics. They ignored it then —I have no idea why. I'm not sure they'll listen now.

This was when I kind of lost interest, as it became clear generics would never happen.

In the early days I was enthusiastic enough that I tried to provide support for the os.user implementation on Windows.

Nowadays I just advocate Go for C use cases, where the use of a tracing GC is not an hindrance as a way for us to enjoy safer computing.

Oh, and the code of the new syncmap.Map is full of unsafe.Pointer as workaround for lack of generics, while achieving good performance.

https://github.com/golang/sync/blob/master/syncmap/map.go

Re: Toward Go 2

#563

Post by fmap »

masklinn wrote: post #26
wheaties wrote: post #16

Earlier quoted context omitted.

If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Look, even allowing type aliases to become part of an interface declaration would be a HUGE win. You can't currently write portable arbitrary data structures without reimplementing them with a code generator. Ugh!

> perhaps they can read the literature of the past 30yrs 40, nearing on 45: > Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975)

Nitpick, but the idea is even older, going back at least to Girard (1971) and Reynolds (1974). :)

I don't know exactly what the problem is for Go. There are tradeoffs, e.g., just with the type system: impredicative, stratified or predicative quantification, implicit subtyping or explicit type instantiation, value restrictions, variance handling for mutable inductive types, Hindley-Milner or bidirectional typechecking, etc. There are more tradeoffs with the implementation. Fortunately, these are all well understood by now.

However, it is also true that many mainstream languages famously got generics wrong. What's most infurating about this situation is that a lot of research just gets ignored. If the question is really "should Go have generics whose design is based on C++ templates and/or Java generics" then the only sane answer is a resounding no.

Re: Toward Go 2

#564

Post by pjmlp »

simias wrote: post #303
pebers wrote: post #194

Earlier quoted context omitted.

To what degree are those being used though? Major projects (e.g. Linux, CPython) are still on ANSI C.

C99 took a while to be widely adopted mainly because some compilers where very slow on the uptake (I'm looking at you Visual C++) but now I would never consider using anything less than that for a new project. It's almost 20 years old! Many small quality of life improvements: stdint.h stdbool.h, inline, restrict, allowing variable declaration within the code, snprintf, variadic macros... Most of those were accessible…

> I'm looking at you Visual C++

They decided to ditch clang/c2 integration work, and are planning to actually fully support C99 and not only what is required by ANSI C++.

https://www.reddit.com/r/cpp/comments/6mqd2e/why_is_msvc_usu...

https://www.reddit.com/r/cpp/comments/6mqd2e/why_is_msvc_usu...

Re: Toward Go 2

#565

Post by pjmlp »

masklinn wrote: post #245
I_am_tiberius wrote: post #135

Earlier quoted context omitted.

Thanks for that information. I had thought enums can only be used as named types. Good to know they can hold data as well. I had though of that struct as well (ok, not in that professional way with types as constants and iota:-)) but found it a bit annoying that I have to store a type myself although the type itself should already have the type information somewhere itself - consequently that information is stored re…

> I had thought enums can only be used as named types. Good to know they can hold data as well. That depends on the language, and enums being sum types also depends on the language. * Rust and Swift enums are sum types (they can hold data and every variant can hold different stuff), there is also a ton of (mostly functional) languages with sum types not called enum: Haskell, F#, OCaml, … there are also languages whic…

C++17 has support for sum types via std::variant.

Re: Toward Go 2

#566

Post by swah »

Xeoncross wrote: post #247
notheguyouthink wrote: post #224

Earlier quoted context omitted.

It's weird, I see these complaints so often and I just.. don't.. get it. I'm not sure what I do differently, but I'm just so used to Go's method of non-generic that I don't run into frustration at all. The only time I even notice it is if I have to write a method like `AcceptInt(), AcceptString(), AcceptBool()` and etc. I enjoy generics in Rust, I'm just not sure what I'm doing differently in Go that causes me to not…

It's possible your data (and types) are short lived. When I'm doing text processing for example, I pass the same strings/dicts/hashes through dozens of functions for cleaning, sorting, organising, benchmarking, comparing, etc.. It's not just in->save->out CRUD work.

I'm actually coding a LITTLE project with 7 tables and thinking if Golang was the right choice.. but I picked Golang because there is some async realtime component. My pace of dev is very slow.

Re: Toward Go 2

#567

Post by pmarreck »

grogenaut wrote: post #424
pmarreck wrote: post #352

Earlier quoted context omitted.

Why wouldn't it, if you're pattern-matching correctly? And in any event, it seems far easier to get into that situation in Go (which ignores errors unless you explicitly check for them) than in Erlang (which crashes on every error because restarting is cheap)

My point is... "Pattern matching correctly"... assumes no mistakes on the coder's part. Go back and re-read my comment. Or don't. Downvote me because I dare question your skill in the context of the mighty erlang.

I would never downvote someone simply for disagreeing, and certainly not unless I was 100% sure they were wrong or it was way offtopic. (And you would be surprised how often I admit I was wrong or cede a point!)

You're basically saying "well, it's still subject to logic errors." Well, that's a nonargument, because you can say that about 100% of languages in existence. That is not a criticism you can levy just against BEAM langs. And we were never arguing that BEAM magically takes care of your logic bugs. Just that it seems to handle the "set of all bugs that are not logic bugs" better.

I also apologize for erlang/elixir fans being rabid and insufferable. ;) A lot of us have dealt with many other langs (I spent years on Ruby and other OO langs) and we're enjoying the unexpected (to us) benefits of this new/old world, that's all. Joe Armstrong is basically Einstein AFAIC...

Re: Toward Go 2

#568

Post by insulanian »

> For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve.

Collections?

Re: Toward Go 2

#569

Post by vbezhenar »

I like Go concept: very simple and minimalistic language, yet usable enough for many projects, even at cost of some repetition. Generics are not a concern for me. But error handling is the thing I don't like at all. I think that exceptions are best construct for error handling: they are not invasive and if you didn't handle error, it won't die silently, you have to be explicit about that. In my programs there's very little error handling, usually some generic handling at layer boundaries (unhandled exception leads to transaction rollback; unhandled exception returns as HTTP 500, etc) and very few cases when I want to handle it differently. And this produces correct and reliable program with very little effort. Now with Go I must handle every error. If I'm lazy, I'm handling it with `if err != nil { return err; }`, but this style doesn't preserve stack trace and it might be hard to understand what's going on. If I want to wrap original error, standard library don't even have this pattern, I have to roll my own wrapper or use 3-rd library for such a core concept.

What I'd like is some kind of automatic error propagation, so any unhandled error will return from function wrapped with some special class with enough information to find out what happened.

Re: Toward Go 2

#570

Post by petepete »

tschellenbach wrote: post #106
alexandernst wrote: post #22

How about fixing all the GOPATH crap?

We've worked around it like this and it works pretty well: https://github.com/getstream/vg

Thanks for this. For the first time in my six months using Go the 'peek definition' and 'goto definition' options work correctly!
Post reply on HN