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

511–520 of 534 posts

Re: Go 2, here we come

#511

Post by int_19h »

Groxx wrote: post #404
int_19h wrote: post #373

Earlier quoted context omitted.

The main advantage of the async/await model is that it's just syntactic sugar on top of CPS, so you can bolt it onto any language that is capable of handling callbacks (even C!). For a good example of that, consider WinRT - you can write an async method there in C#, the task that it returns can pass through a bunch of C++ frames, and land up in JS code that can then await it - and all that is handled via a common ABI…

it's true that it's "just syntactic sugar", but in most languages it has call-site contracts that are either part of the signature (`await x()` to unpack the future/coroutine) or implicit (`x()` in an event loop host). and to change something deep in the stack means changing every call site everywhere. that's a huge burden on a library (and thus the entire language ecosystem). it splits the world. to avoid that, you…

Right. You can have callee's parallelism be invisible - but only by adding it to your language (can't be done as a library) and making it be similarly invisibly parallel. And even that only works so long as everybody adopts the same system - goroutines don't play well with Ruby fibers, for example.

With the async/await model, you can immediately use it with any language that has callbacks, and then the languages can gradually add async/await on their own schedules.

I would dare say that the async/await model has proven far more successful in practice. It came to the table later than green threads etc (if you consider syntactic sugar a part of it - CPS itself was around for much longer, of course). And yet it was picked up surprisingly fast - and I think the way in which you can bolt it onto the existing language is precisely why. Conversely, every language and VM that has some form of green threads, seems to insist on doing their own that aren't compatible with anything else out there - and then you get insular ecosystems and FFI hell.

Maybe if some OS offered green threads as a primitive, it would have been different. But then again, Win32 has had fibers since mid-90s, and nobody picked that up.

Re: Go 2, here we come

#512

Post by vram22 »

sjellis wrote: post #240
vram22 wrote: post #103

Earlier quoted context omitted.

> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :) Just saying that Rails (R…

There's gomacro, which is a Go REPL with debugging: https://github.com/cosmos72/gomacro It would be awesome to have a REPL in the standard Go distribution, and I definitely feel the lack: even Java now provides one (JShell).

>There's gomacro, which is a Go REPL with debugging: https://github.com/cosmos72/gomacro

Will check it out, thanks. Had just been thinking whether there is any Go interpreter some time ago. I remember C having at least one, back in the day.

>It would be awesome to have a REPL in the standard Go distribution, and I definitely feel the lack

Agreed. And it should be more like IPython (command-line version) than like the stock Python shell.

>even Java now provides one (JShell).

Good to know.

Re: Go 2, here we come

#513

Post by int_19h »

amelius wrote: post #462
int_19h wrote: post #369

Earlier quoted context omitted.

Of course, if you're comparing with Go, you need to compare apples to apples - since Go doesn't have ownership tracking, the equivalent Rust would necessarily have to be unsafe.

Yeah but Go has garbage collection. Rust's ownership model makes up for not having GC.

I think that heap-allocating everything and using Rc and Weak would be a closer comparison to what Go does, than using idiomatic Rust with borrow-checked locals etc.

Re: Go 2, here we come

#514

Post by icedchai »

geezerjay wrote: post #506
usrusr wrote: post #272

Earlier quoted context omitted.

Ignoring the basic int type and using a zoo of preprocessor defines instead is what has worked for C all that time. But I still think that native types have their place. It can often be quite reasonable to accept serious limitations on narrow machines where the performance gains won by the trade-off are desperately needed, lift those limitations on wider machines and grant an enormous safety margin on the widest arch…

> Ignoring the basic int type and using a zoo of preprocessor defines My C is a bit rusty but why should #defines be used in this scenario? A typedef set in a config.h.in is more than enough to meet the requirements of this usecase.

Why do you need your own typedef? stdint.h is available, if you're using a compiler from the past couple of decades at least.

Re: Go 2, here we come

#515

Post by monocularvision »

jerf wrote: post #356
kbirkeland wrote: post #301

Earlier quoted context omitted.

I'm curious what the motivation was to use int instead of uint considering indexes cannot be negative in Go.

Despite most of my professional programming being in Go nowadays, I am extremely sympathetic to the Haskell/FP way of thinking about things, and trying to make invalid state unrepresentable. However, having made the mistake a few times now of trying to use "unsigned ints" for things that I want to assert are never negative, I've learned the hard way not to do that. The problem is, there's always some bug you have in…

Swift does this with the default operators. There are alternative operators if you want to get the more classical C-style treatment.

Re: Go 2, here we come

#516

Post by throwaway34241 »

coldtea wrote: post #482
throwaway34241 wrote: post #225

Earlier quoted context omitted.

Even if it's OK to degrade the performance of a small minority of users, is there a big benefit to emulating 64 bit ints everywhere on 32 bit hardware? (I'm not saying there isn't a benefit, just that it's not clear to me what it is). I don't know how many users are still on 32bit. Maybe low power network devices? Older mobile phones (Go isn't usually run on mobile, but it's possible...). If at some point in the futu…

> I don't know how many users are still on 32bit. Maybe low power network devices? Older mobile phones (Go isn't usually run on mobile, but it's possible...). Well, 16 bit would also be possible if someone took the effort. Perhaps it just shouldn't be encouraged.

By 'possible' I meant that it's currently supported by the Go toolchain.

Re: Go 2, here we come

#517

Post by throwaway34241 »

tigershark wrote: post #453
throwaway34241 wrote: post #207

Earlier quoted context omitted.

Which would you choose instead? To default to 32 bits (even on 64 bit systems) or to default to 64 bits (even on 32 bit systems). Defaulting to 64 bit math on 32 bit systems will have a huge performance penalty on generally the slowest/oldest systems where this penalty is least desirable. It's not clear to me what the benefit to this would be for most programs. Running 32 bit ints on 64 bit systems will cause problem…

I would use int and long like in C# for example, with no magic int that can be 32 or 64 bit depending on the platform to avoid any confusion.

And as a result of this, you can't have a 3GB byte array in C#. I think there needs to be a big benefit to make hard-coding a restriction like that into the language worth it.

Unfortunately I've read every comment in this HN thread (so far) and I haven't found any specific one mentioned, just people calling it "crazy" and "confusing" over and over.

Go is a language that has explicit pointers! And of course those can be 32 or 64 bits and change struct sizes, field offsets etc. There are certainly things about Go that are confusing but I've never thought this was one of them.

Just FYI Go has int8, int16, int32, int64, and int types. Only the 'int' type is the machine-native one. It's always been obvious to me that 'int' is the one without a fixed size, but I think this would be less obvious if the naming convention was different using short, int, long etc.

Re: Go 2, here we come

#518

Post by Vendan »

scott_s wrote: post #501
Vendan wrote: post #255

Earlier quoted context omitted.

I feel you, but, that's uintptr. int is more useful as the "native type" for array/slice length/cap/indexing

I actually agree. I was responding to someone who dismissed the entire concept.

no, I get that, but int is not for pointerinteger conversions. That is very specifically a separate type:

    uintptr  an unsigned integer large enough to store the uninterpreted bits of a pointer value
https://golang.org/ref/spec#Numeric_types

Re: Go 2, here we come

#519

Post by scott_s »

Vendan wrote: post #518
scott_s wrote: post #501

Earlier quoted context omitted.

I actually agree. I was responding to someone who dismissed the entire concept.

no, I get that, but int is not for pointer integer conversions. That is very specifically a separate type: uintptr an unsigned integer large enough to store the uninterpreted bits of a pointer value https://golang.org/ref/spec#Numeric_types

Sure, but did I imply it was? I’m genuinely confused.
Post reply on HN