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

Go 2, here we come

blog.golang.org

Post reply on HN
Print view View original

341–350 of 534 posts

Re: Go 2, here we come

#341

Post by burtonator »

glangdale wrote: post #339

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

I'm hoping things like generics can just be accepted to be a good idea moving forward and that we can all agree that languages without them are handicapped.

I still fell things are up in the air about exceptions but maybe we can just agree on generics which would make me feel better.

Using go without generics just felt insane to me...

Re: Go 2, here we come

#342

Post by zinclozenge »

weberc2 wrote: post #199
zinclozenge wrote: post #164

Earlier quoted context omitted.

I disagree that using rust means trading a lot of developer time. I'm as comfortable with rust as I am go, and I develop equally fast in either language. I would even say faster in Rust because of the type system.

That's quite a feat. According to the Rust developer survey, it takes many people a month or more to feel productive in Rust^1 at all much less as productive as with Go. I've been picking up Rust occassionally for 4-5 years now and I'm still not particularly productive and far less productive than I am in Go (and I come from a C++ background, so it's not like I'm a stranger to thinking about memory management and thi…

Well it took me longer to get comfortable with Rust than Go, and I also had to learn actix (actor style framework in rust) to do the same high concurrency programming. But once the time investment is put in, I definitely consider Rust to be the more productive language.

Once async/await stabilizes and the rest of the ecosystem catches up and becomes a little bit more ergonomic to use, I would say Rust will be in a good position.

Re: Go 2, here we come

#343

Post by xapata »

dekhn wrote: post #197
adtac wrote: post #186

Earlier quoted context omitted.

The problem with overflow isn't just needing to store numbers larger than 2 billion. Sometimes, intermediate values are larger than that even if the final result isn't. Take averaging as a very simple example. Doing (a + b) / 2 will overflow if a and b are sufficiently large, even if the average will always fit in 32 bits. Things like this go unseen for years.

don't most people compute the mean iteratively when they need to do this? Sure, it goes unseen, but programmers on systems like this are expected to understand the math model and write tests.

Systems like what? My expectation is no, most people make mistakes.

Re: Go 2, here we come

#344

Post by TheDong »

Someone wrote: post #219
drb91 wrote: post #122

Earlier quoted context omitted.

People have traditionally wanted to use the maximum sized type that can fit in a register.

More precisely: they wanted the integer type that was large enough and ran their code fastest. On CPUs with 64-bit and 32-bit registers, that typically is the register-sized integer type. Machines with 16-bit registers are a bit of an edge case, as 16-bit integers may both be a lot faster on them then 32-bit integers and, in many cases, too small) If go chose to use 32-bit integers as default, some users on 64-bit sy…

> Not having generics makes this more of a problem. If go had generics, switching between integer sizes could be a matter of recompilation using a different compiler flag)

Isn't it already the case that you can switch between int sizes with compiler flags?

    var i int
That will be 32 bits if I compile it with GOOS=linux GOARCH=386 and will be 32 bits if I swap in amd64 instead of 386 there.

Is there any language where generics are useful for switching between int sizes? None come to mind offhand, so I don't quite understand what you mean.

Re: Go 2, here we come

#345

Post by Stratoscope »

codegeek wrote: post #210
esrauch wrote: post #168

Earlier quoted context omitted.

Is it really so harmful to have it at the top of the comment thread? I think HN can be focused mainly on serious discourse without being completely humorless.

I think about it all the time. But imagine leaving the page and coming back a few hours later. Now you have to sort through tons of unnecessary comments (even if funny and humorous) while you look for the quality stuff. Quality requires sacrifice and I am willing to sacrifice the humor part for quality unless you throw in a bit of humor with quality content.

A great way to solve this is to use the [-] button to collapse any comment threads that you're not interested in following, like this one. HN remembers which threads you've collapsed, so you won't see them when you come back to the page.

Re: Go 2, here we come

#346

Post by cultus »

burtonator wrote: post #341
glangdale wrote: post #339

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

I'm hoping things like generics can just be accepted to be a good idea moving forward and that we can all agree that languages without them are handicapped. I still fell things are up in the air about exceptions but maybe we can just agree on generics which would make me feel better. Using go without generics just felt insane to me...

Yeah, Go has some really fantastic aspects around tooling and a good concurrency story, but it's otherwise such a huge step backwards. I can't fathom the reason for not having generics. It's such a simple, completely common-sense abstraction.

Things like typeclasses or multimethods offer vastly more abstraction power. These are (a bit) more difficult to understand, but you certainly don't have to be a genius (take it from me). I can kind of get why a language targeted towards "average" programmers might want to omit these.

But here's the thing: The less abstraction power a language has, the more complexity must be handled by the developer. This leads to things like Java Spring, which you do have to be a genius to understand.

Re: Go 2, here we come

#347

Post by ryeguy »

glangdale wrote: post #339

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance.

I suspect a lot of the generics hate is due to a large chunk of the community coming from dynamically typed languages. In which case they're just have a negative reaction to unfamiliarity.

Re: Go 2, here we come

#348

Post by ryeguy »

Thaxll wrote: post #305
SwellJoe wrote: post #256

Earlier quoted context omitted.

I just started learning Rust for a small project, and I found its "one clear path" model very appealing (I don't know if it is a formal goal, or if it's just a happy accident based on a smaller, more focused, community). It doesn't just apply to the package manager, but that's one of the first bits a beginner sees. Rust has a single, easy-to-find, "pretty good" answer for nearly every question a beginner asks, at lea…

Rust easier to learn than JS lol... In Rust you have issues that will or will not overcome easily, nothing like that happen in Go. And seriously getting starting in Go takes less than an hour: - Install Go - Install VSCode + Go plugin - Start working

Coincidentally, here's Rust's getting started workflow:

- Install Rust

- Install VSCode + Rust plugin

- Start working

Re: Go 2, here we come

#349

Post by ramenmeal »

ryeguy wrote: post #347
glangdale wrote: post #339

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…

I think the main fear people have isn't the concept of generics, but the implementation of generics. Go's primary goal is simplicity, and implementing generics isn't simple.

Re: Go 2, here we come

#350

Post by abreis »

bluejekyll wrote: post #296
joobus wrote: post #250

Earlier quoted context omitted.

I feel the same way. By the time Go2 releases, I hope Rust has solidified its async/await syntax, and Rocket can build on stable.

As I understand it, async/await is not going to be too far behind the initial 2018 Edition (which is coming to stable soon).

Latest estimate is 'in 2 release cycles' (iirc), or 12 weeks.
Post reply on HN