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

Four days of Go

evanmiller.org

Post reply on HN
Print view View original

131–140 of 187 posts

Re: Four days of Go

#131

Post by pcwalton »

EugeneOZ wrote: post #125
heinrich5991 wrote: post #111

Earlier quoted context omitted.

A web server can easily be implemented as a library, generics are a language feature.

And library can be easily abandoned or just be broken after breaking changes in next version of language, and you will have to wait couple of months, while this issue will be solved. Or just fix all the things yourself.

> after breaking changes in next version of language

In practice Rust doesn't make breaking changes anymore. (It hasn't since beta, and in a month or so 1.0 will be declared officially stable and it will become forbidden to make them.)

Re: Four days of Go

#132

Post by pcwalton »

EugeneOZ wrote: post #124
steveklabnik wrote: post #109

Earlier quoted context omitted.

> I suspect will get resolved much more quickly and cleanly It's pretty easy. You just add this line to your Cargo.toml: hyper = "0.3.14" And the next time you build, Cargo handles everything. You can now use hyper like any other library that's included with Rust, no biggie. This is one reason we've chosen minimalism for the standard library: It's really easy to use external libraries, and once things land in the sta…

no. there is a HUGE difference between std lib and third-party libs. Std lib is like a contract - maintainers of language have to keep all parts up to date and working. Maintainers of third-party library can write "Farewell Rust" blogpost and all projects, based on that library will be in trouble. And as http is a very important thing for web-programs, it's much better to see support of http in std lib.

> Std lib is like a contract - maintainers of language have to keep all parts up to date and working.

Rust has language stability (in practice right now, and officially once we hit 1.0 in a month), so we in fact do guarantee this.

> Maintainers of third-party library can write "Farewell Rust" blogpost and all projects, based on that library will be in trouble.

Languages can do that too, in which case the entire language and its ecosystem is in trouble. Anything can be abandoned. The crucial thing is that if a piece of infrastructure is in the standard library, then it's much harder and slower to iterate on it. HTTP is a fast-moving standard (see HTTP 2, for example), and so it's very important to be able to iterate quickly to support new features.

> And as http is a very important thing for web-programs, it's much better to see support of http in std lib.

I disagree. Web applications need HTTP, but many applications aren't Web applications. As a example on the far opposite end of the spectrum, your OS kernel doesn't have an HTTP stack in it (unless you happen to be running something like khttpd), and Rust is designed to be usable for OS kernels. Large standalone standard libraries reduce flexibility, and Rust is designed to be flexible.

Re: Four days of Go

#133

Post by 0xdeadbeefbabe »

jgrahamc wrote: post #2

In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…

> we programmers like to discuss everything, and argue

I doubt that, for the sake of truth and not just to argue with you. Most programmers do not want to argue or discuss things. Most programmers leverage knowledge and understanding to make the computer do interesting things. Some find go more understandable and useful than others.

Re: Four days of Go

#134

Post by MichaelGG »

nemothekid wrote: post #83
adrusi wrote: post #66

Earlier quoted context omitted.

In before "but adding generics does not make team projects harder, look at language ..." Your (and many other people's) insistence on dismissing discussion regarding generics as some kind of a joke is anti-intellectual. You're rejecting valid criticism of your arguments on the basis that the critic's argument is unworthy of attention for some reason external to the discussion at hand. I agree that pro-generics argume…

I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. Then people bring Rust, which has only had a stable grammar for last couple months and a standard library nowhere near Gos. Would it be wise to complain that the Rust stdlib doesn't contain a HTTP server implementation?

> I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics.

I don't use Go so I don't really care about their generics or lack thereof. What I found ... odd ... is how the Go team has apparently said they can't go generics because there's no good way to implement them. Seems like a strange thing to say when many languages are happily using them.

Re: Four days of Go

#135

Post by kristianp »

From what I can gather on the mailing list threads, the language designers are against polymorphism, as well as adding letters to function names, so unlike the standard C library which operates on float, double, and long double, as well as int and long where appropriate (e.g. absolute value), the Go standard math library operates only on float64.

This is criticism of go I haven't heard before.

Re: Four days of Go

#136

Post by barosl »

MichaelGG wrote: post #134
nemothekid wrote: post #83

Earlier quoted context omitted.

I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. Then people bring Rust, which has only had a stable grammar for last couple months and a standard library nowhere near Gos. Would it be wise to complain that the Rust stdlib doesn't contain a HTTP server implementation?

> I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. I don't use Go so I don't really care about their generics or lack thereof. What I found ... odd ... is how the Go team has apparently said they can't go generics because there's no good way to implement them. Seems li…

After hacking Rust, I got the feeling that generics are hard. They are so hard that a language should consider them from the beginning to fully take advantage of them. That might be the reason why the Go team says generics are hard to implement in the current Go type system. They can also choose either C++-like code generation based on templates, or external code generating tools, but both are not perfect in my opinion.

Re: Four days of Go

#137

Post by barosl »

PopsiclePete wrote: post #127
adrusi wrote: post #66

Earlier quoted context omitted.

In before "but adding generics does not make team projects harder, look at language ..." Your (and many other people's) insistence on dismissing discussion regarding generics as some kind of a joke is anti-intellectual. You're rejecting valid criticism of your arguments on the basis that the critic's argument is unworthy of attention for some reason external to the discussion at hand. I agree that pro-generics argume…

Various core Go team members seem to have a different philosophy regarding generics. They actually don't have a united front on this. It seems Russ Cox and Rob Pike are either anti-generics or in the you-dont-really-need-them camp, but Ian Thompson and Brad Fitzpatrick have seemed very open to the idea - what they can't, however, agree on, is exactly how to implement them so that they make sense in Go. That's it. If…

I think adding generics to a stable language is actually a hard thing to do. There's more than "that's it". Rust has had many major and minor changes regarding generics solely, which has broken backward compatibility each time.

The Go team may find a brilliant way to accomplish this, but I think the only viable way left is, as you said, using code generation. Either C++-way, which is a special syntax but still a form of code generation, or an external tool. But neither of them is elegant, because you cannot fully utilize the convenience that the type system give. These might be the concerns that the Go team has.

Re: Four days of Go

#138

Post by amaranth »

PopsiclePete wrote: post #127
adrusi wrote: post #66

Earlier quoted context omitted.

In before "but adding generics does not make team projects harder, look at language ..." Your (and many other people's) insistence on dismissing discussion regarding generics as some kind of a joke is anti-intellectual. You're rejecting valid criticism of your arguments on the basis that the critic's argument is unworthy of attention for some reason external to the discussion at hand. I agree that pro-generics argume…

Various core Go team members seem to have a different philosophy regarding generics. They actually don't have a united front on this. It seems Russ Cox and Rob Pike are either anti-generics or in the you-dont-really-need-them camp, but Ian Thompson and Brad Fitzpatrick have seemed very open to the idea - what they can't, however, agree on, is exactly how to implement them so that they make sense in Go. That's it. If…

This is already a thing, no? https://blog.golang.org/generate

Re: Four days of Go

#139

Post by ecnahc515 »

MichaelGG wrote: post #134
nemothekid wrote: post #83

Earlier quoted context omitted.

I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. Then people bring Rust, which has only had a stable grammar for last couple months and a standard library nowhere near Gos. Would it be wise to complain that the Rust stdlib doesn't contain a HTTP server implementation?

> I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. I don't use Go so I don't really care about their generics or lack thereof. What I found ... odd ... is how the Go team has apparently said they can't go generics because there's no good way to implement them. Seems li…

Implicit interfaces make generics a lot less trivial to implement. They also don't want to simply add an existing approach with bad trade-offs (see C++ templates). Likewise, adding a runtime based multi-dispatch based generic system is not much better than what we already have.

Lot's of languages have generics, but they have trade-offs, so they aren't free, even if they can implement them using existing generics implementations. Picking what they're willing to sacrifice can be hard, even if it's something like slower compile times.

Anything backwards compatible has to be in Go 2 or later, because generics are hard to make backwards compatible, we'll have to wait.

Re: Four days of Go

#140

Post by the_af »

serve_yay wrote: post #64
jlebrech wrote: post #8

no ternary is a smart move tho. makes code more readable for all skill levels.

It's just syntactic sugar for if-else though, so it's right in the sweet spot of "doesn't make a big difference either way" and "is subject to preference" that makes it a prime target for bikeshedding. Personally I don't like the ternaries either, typically the syntax is ugly, but the if-else seems only slightly better to me.

It's not syntactic sugar.

The ternary operator usually appears in imperative languages (or should I say, languages which are not expression-oriented) where the if-then-else construct statement is NOT an expression, and possibly has side-effects. Therefore, you need an alternative construct that really is an expression and evaluates to something.

The syntax itself is irrelevant. If you can say the following in your favorite language:

    x = if (condition) { something } else { something else }
then you don't need a "ternary operator".
Post reply on HN