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

191–200 of 534 posts

Re: Go 2, here we come

#191

Post by zapzupnz »

ghthor wrote: post #155
zapzupnz wrote: post #107

Earlier quoted context omitted.

Swift can get away with it because the majority of its users are using Xcode which has excellent tools for migrating between versions of Swift, and also interop with Objective-C code. Plus, the current compiler can target a limited number of older versions’ syntax but allowing use of new APIs for some degree of forwards compatibility in large code bases. Whereas I doubt there’s one canonical Go dev environment common…

The standard go cli toolchain comes with `go fix which was used to do the update code for breaking changes or styles during the time before 1.0 release. If anything, I suspect the swift team was partially inspired by this pattern.

I doubt it. Apple's refactoring tools in Xcode go way back, thanks to the introduction of Carbon; the Intel transition; synthesised properties and automatic reference counting in Objective-C 2; and the extremely regular, breaking changes in UIKit.

Re: Go 2, here we come

#192

Post by jstimpfle »

user5994461 wrote: post #183
Sharlin wrote: post #173

Earlier quoted context omitted.

It may be crazy but it's not exactly without precedent. Neither C nor C++ fix the sizes of the fundamental integer types, although for backward-compatibility reasons popular 64-bit platforms still have 32-bit `int` and even `long`. But yeah, there's a reason eg. Rust has no `int` and friends but `i32` etc. instead.

C only defines char, short, int has having a minimum size of 8, 16 and 32 bits.

no, int is 16 bits minimum

Re: Go 2, here we come

#193

Post by Insanity »

joppy wrote: post #27

I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…

I'd like this because it'd make certain classes of programming problems simpler.

Admittedly, not for things I build in my day-job but mostly for the kind of things you'd get when doing 'project euler' or 'leetcode'. Or more seasonal, the coming "Advent of Code".

Re: Go 2, here we come

#194

Post by nickcw »

I've been reading this proposal

> #19113 Permit signed integers as shift counts: An estimated 38% of all non-constant shifts require an (artificial) uint conversion (see the issue for a more detailed break-down). This proposal will clean up a lot of code, get shift expressions better in sync with index expressions and the built-in functions cap and len. It will mostly have a positive impact on code. The implementation is well understood.

The proposal as far as I can make out says allow signed integers for shifts but panic if they are negative.

This seems like a step backwards to me pushing checking which the compiler made you do to runtime.

Personally I'd expect a negative shift to shift the other way, but that doesn't seem to be a popular option with the team.

Re: Go 2, here we come

#195

Post by WakiMiko »

Sharlin wrote: post #173
tigershark wrote: post #88

Earlier quoted context omitted.

I am misunderstanding or really go is using the ‘int’ type that can be 32 or 64 bit depending on the system that it runs on??? If this is the case I think that is crazy and I can’t think of any useful use case for it. If it’s not the case then please explain me what that proposal is really about...

It may be crazy but it's not exactly without precedent. Neither C nor C++ fix the sizes of the fundamental integer types, although for backward-compatibility reasons popular 64-bit platforms still have 32-bit `int` and even `long`. But yeah, there's a reason eg. Rust has no `int` and friends but `i32` etc. instead.

Rust has a `usize` which is 32 or 64 bits depending on the platform and also serves as the native index type for arrays and such.

Re: Go 2, here we come

#196

Post by cloverich »

bsaul wrote: post #93
ilovecaching wrote: post #9

Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to Go, especially generics and/or try/catch will push me away from the language. If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots. If they bolt on type variables,…

I really don't know why you got downvoted. The fact that go was meant to force "average" programmers produce maintainable code is an extremely important push for the language. I do think that generics are needed if go wants to become more useful in contexts others than network middleware or data plumbing, but i'm also pretty sure that adding them will help cripple a lot of codebase in a very short term.

Is there a definitive source for the "average" programmers target? I'd always considered it a tongue-in-cheek response to architecture astronauts who sneer at Go's simplicity.

Re: Go 2, here we come

#197

Post by dekhn »

adtac wrote: post #186
quickthrower2 wrote: post #181

Earlier quoted context omitted.

Meh I use C# and I rarely need an int bigger than 2147483647, and if I do I use a long which gets me up to 9223372036854775807, and if I need more than THAT then I'll use a math library of some sort.

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.

Re: Go 2, here we come

#198

Post by atombender »

riwsky wrote: post #176
atombender wrote: post #70

Earlier quoted context omitted.

This doesn't seem to be a popular opinion, but I agree. It's such a pervasive functionality in concurrent programs that it really should be a built-in aspect of a goroutine. The problem with context isn't necessarily the interface, it is that it is "viral". If you need context somewhere along a call chain, it infects more than just the place you need it — you almost always have to add it upwards (so the needed site g…

I agree heartily that context is viral in APIs, but would argue that that's essential to the nature of context. Accordingly: implicit association of context with a goroutine would introduce a complementary API virality issue: you now need need to worry about whether anything above or below you starts to delegate their work to separate goroutines.

Not sure what you mean here. How does an implicit context change any semantics? You would still be able to override which context is given to goroutines you spawn. As a developer, you'd have to be aware of the implicitness, that's the only difference.

Re: Go 2, here we come

#199

Post by weberc2 »

zinclozenge wrote: post #164
weberc2 wrote: post #71

Earlier quoted context omitted.

My rule of thumb is use Go by default, but if it makes sense to trade a lot of developer time for extreme performance or extreme type safety, use Rust. As with all rules of thumb, there's a lot more nuance than this, but I think it captures the big idea well enough.

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 things). I suspect that you're an outlier (I may be also, but my point doesn't hinge on that).

^1: Most people report being productive with Go in a day or two

Re: Go 2, here we come

#200

Post by throwaway2048 »

Cyph0n wrote: post #172
llimllib wrote: post #147

Earlier quoted context omitted.

I don't understand what you mean, sorry

Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?

Its not like there is much of a barrier there.
Post reply on HN