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

251–260 of 670 posts

Re: Toward Go 2

#251

Post by dbaupp »

tomovo wrote: post #129
twblalock wrote: post #64

Earlier quoted context omitted.

The craziness is preferable to passing void* or Object or Interface{} everywhere. At that point, you might as well use a language without strong typing, for all the safety you're going to get. You can end up with just as much craziness with void* and Object and Interface{}. The Go team needs to stop trying to control what people do with their language. If people come up with crazy implementations, it's their own prob…

"If people come up with crazy implementations, it's their own problem." Some people are turned away from C++ after seeing random bits of crazy language/template misuse, although when used sanely C++ could've served them nicely for their job. Same thing is going to happen to Swift very soon. https://engineering.kitchenstories.io/comfortable-api-reques... Those function signatures are definitely not... self-documenting…

Those signatures seem complicated to me because there's a pile of arguments and some of them are functions with extra annotations, not because there's generics involved. The equivalent signatures using interface{} (or maybe something more precise) would be likely just as noisy, if not more so.

Re: Toward Go 2

#252

Post by masklinn »

seanmcdirmid wrote: post #123
masklinn wrote: post #105

Earlier quoted context omitted.

That's not exactly surprising, the C# community has been doing that since the beginning of the language, anything not in the language is pointless academic wankery, and as soon as Microsoft announces it it's the best innovation in computing history since Microsoft was created. Source: got to interact with the community between the C# 1.0 and 4.0 releases (2.0 added generics, 3.0 added lambdas, neither feature was con…

> That's not exactly surprising, the C# community has been doing that since the beginning of the language, anything not in the language is pointless academic wankery, and as soon as Microsoft announces it it's the best innovation in computing history since Microsoft was created. That isn't true inside Microsoft. Many of the people who work on C# are the same academic wanks that work on Scala or F#. C# has a different…

> That isn't true inside Microsoft.

No, that was not intended as included in "the C# community". Hell, SPJ used to work at Microsoft (he may still do, but he used to).

> the people who work on C# are the same academic wanks that work on Scala or F#

I'm sure you mean wonks, but I liked the typo.

> C# has a different user base from those languages though, so they still have to be careful what they add to the language, and many language features are planned 3 or 4 versions in advance.

I have no issue with the evolution of C# rate or otherwise, only with a number of its users.

Re: Toward Go 2

#253

Post by herrschnapps »

seanmcdirmid wrote: post #117
JBReefer wrote: post #90

Earlier quoted context omitted.

C# is adding pattern matching in the upcoming release, and to your point, people are acting like it's the new hotness.

It is new to C#, which is slowly catching up to Scala and F# in that regards. Mads Torgesen is good friends with Martin Odersky, in fact, when I first met Mads back in 2006 or so, they were talking about adding pattern matching to C#. C# is a much more conservative language, and it makes sense it would take a while to add. There are good reasons to use C#, so when it gets a new feature that other languages have had f…

It's just become a Stage 0 proposal: https://github.com/tc39/proposal-pattern-matching

Re: Toward Go 2

#254

Post by weberc2 »

steveklabnik wrote: post #227
weberc2 wrote: post #95

Earlier quoted context omitted.

Why does an ORM need generics? I ask because I've built something very like an ORM in Go and I didn't have any problem without generics. ADTs on the other hand...

The strongest typed ORM I've ever used is http://diesel.rs/ This code (okay I made the use line up because it's not on the website and I'm lazy, you do need one though): use some::stuff::for::the::dsl; let versions = Version::belonging_to(krate) .select(id) .order(num.desc()) .limit(5); let downloads = version_downloads .filter(date.gt(now - 90.days())) .filter(version_id.eq(any(versions))) .order(date) .load:: (&con…

Ah, I think the bit where generics is useful is in making sure the value types are consistent (i.e., that you're not building a query that subtracts an int from a string or compares a date to a bool). This still doesn't guarantee that the types will match with the database columns, but it is a step up from the non-generic alternative.

Re: Toward Go 2

#255

Post by imsofuture »

acdha wrote: post #119
imsofuture wrote: post #44

Earlier quoted context omitted.

Go's errors are really nice (if a bit repetitive) in my opinion. Type signatures enforce that you accept and acknowledge an error returned from an invocation, but leave it up to you to handle, pass along, or silently swallow.

Does that mean it now throws an error if you use the common punt like `foo, _ := …` and never check `_`?

No, but that's what I mean as intentionally ignoring.

Re: Toward Go 2

#256

Post by slavapestov »

pcwalton wrote: post #70
endymi0n wrote: post #39

Earlier quoted context omitted.

Guess what: they did. https://news.ycombinator.com/item?id=8756683 They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Whether that's a good outcome, I'm not fully sure - but there's definitely a lot of research in that area.

The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). The problem with saying "well, this is a tradeoff and both sides have downsides, so we won't do anything" is that the tradeoff still exists —it's just something that manually has to be done by the programmer instead of something that the compiler can do. In Go, the monomorphization approach is done with code duplication (…

> The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}).

There is also the approach taken by Swift, where values of generic type are unboxed in memory, and reified type metadata is passed out of band. There's no mandatory monomorphization.

Re: Toward Go 2

#257

Post by growse »

acdha wrote: post #119
imsofuture wrote: post #44

Earlier quoted context omitted.

Go's errors are really nice (if a bit repetitive) in my opinion. Type signatures enforce that you accept and acknowledge an error returned from an invocation, but leave it up to you to handle, pass along, or silently swallow.

Does that mean it now throws an error if you use the common punt like `foo, _ := …` and never check `_`?

No, because using `foo, _` you're explicitly saying that you don't care about the error.

Re: Toward Go 2

#258

Post by secure »

zackmorris wrote: post #214

Go doesn't have const structs, maps or other objects: https://stackoverflow.com/questions/43368604/constant-struct... https://stackoverflow.com/questions/18342195/how-to-declare-... This is a remarkable oversight which makes it impossible to write purely-functional code with Go. We also see this same problem in most other imperative languages, with organizations going to great lengths to emulate const data: https://f…

There doesn’t need to be a philosophy behind leaving it out. Go was started by selecting only features which were deemed necessary. I think it’s fair to assume the creators of Go didn’t design it for writing purely-functional code, so that’s why it’s not in (yet?)

Re: Toward Go 2

#259

Post by steveklabnik »

weberc2 wrote: post #254
steveklabnik wrote: post #227

Earlier quoted context omitted.

The strongest typed ORM I've ever used is http://diesel.rs/ This code (okay I made the use line up because it's not on the website and I'm lazy, you do need one though): use some::stuff::for::the::dsl; let versions = Version::belonging_to(krate) .select(id) .order(num.desc()) .limit(5); let downloads = version_downloads .filter(date.gt(now - 90.days())) .filter(version_id.eq(any(versions))) .order(date) .load:: (&con…

Ah, I think the bit where generics is useful is in making sure the value types are consistent (i.e., that you're not building a query that subtracts an int from a string or compares a date to a bool). This still doesn't guarantee that the types will match with the database columns, but it is a step up from the non-generic alternative.

It can check that they match with the columns, yeah.

It also heavily relies on generic types to ensure that everything is well-formed, and to provide zero overhead.

Re: Toward Go 2

#260

Post by Thaxll »

pmarreck wrote: post #141
camus2 wrote: post #127

Earlier quoted context omitted.

> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead…

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

Still better that try / except: pass from other languages.
Post reply on HN