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

231–240 of 534 posts

Re: Go 2, here we come

#231

Post by the_clarence »

dcow wrote: post #180
adrianmonk wrote: post #156

Earlier quoted context omitted.

It's a perfectly reasonable niche use case for achieving maximum performance. My main issues with it are: 1. Like many other performance optimizations, it is a trade-off. You may be sacrificing easy maintenance or even introducing breakage (if the person using it doesn't understand the limitations and implications). So IMHO you should only do it if you can show through profiling, etc. that the gain is real and worth…

Even Swift who’s mantra is do nothing unexpected or implicit has a machine dependent (word sized) Int type.

That’s insane

Re: Go 2, here we come

#233

Post by dmurray »

13415 wrote: post #86
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…

Makes no sense to me to redefine existing integer types. Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? As a long-time Racket and Scheme user, I'd say that arbitrary precision numbers as default bring more disadvantages than advantages. As an option with syntax support Yes, but not as a default. it just makes it harder to port all kinds of code that relies on modulo arithme…

> Why not introduce a primitive type "num" for arbitrary precision rational numbers instead?

Rationals aren't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it. Adding them to the base language just because some people would find it convenient would clash with Go's explicit minimalist philosophy.

Re: Go 2, here we come

#234

Post by coder543 »

viraptor wrote: post #224
coder543 wrote: post #218

Earlier quoted context omitted.

> it just makes it harder to port all kinds of code that relies on modulo arithmetics. If you're relying on modulo arithmetic, you should be using a fixed size integer anyways, not one that varies based on the architecture. Go has fixed size integer types available, and modulo arithmetic should be using those, not "int".

I'm not sure how these two are related. Why would you mix modulo operations and fixed size? Modulo on an arbitrary bigint is perfectly valid and useful.

Modulo arithmetic refers to the property of fixed-size integers where they will predictably wraparound in expected ways if you overflow or underflow them. This wraparound is "free", so it used to be commonly used for cyclic high performance code. An arbitrary bigint is computationally more expensive, and it will never experience this effect, so it's a double whammy of irrelevance for bigints. You can manually do a modulo operation on a bigint, but that just makes them even more computationally expensive than a fixed size int, requires more code, and would be considered an unnecessary inconvenience by most people who care about modulo arithmetic.

Re: Go 2, here we come

#235

Post by acdha »

rootbear wrote: post #92
acdha wrote: post #68

Earlier quoted context omitted.

> It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I see the appeal but there are two problems with this: “solvable” is not the same as “easy”, and that similarly also wants fonts which make × more distinct from x. In both cases that's something which is perhaps approachable for dedicated developers but it seems likely to turn newco…

Prior to some programming languages adopting it, I don't think there was precedent for using underscore as a thousands separator, so I don't consider it a strong precedent. The first language I recall using it was Ada. But I understand that using apostrophe has problems that would likely make its adoption impossible for an existing language. I was actually surprised when C++ adopted it. Interestingly, there is a loca…

Yeah, wikipedia cites some unspecified maritime usage of _ but it's definitely not common. It seems like most of the standards outside of programming languages have been moving towards spaces. Unfortunately there doesn't seem to be an easy way to search e.g. https://lh.2xlibre.net/values/thousands_sep/ but some lazy JavaScript shows no underscores and several flavors of whitespace:

    new Set($(".value").map((idx, elem) => elem.textContent))
    Set(8) [ "", ",", ".", "         ", " ", "'", " ", "٬" ]

Re: Go 2, here we come

#238

Post by throwaway34241 »

the_clarence wrote: post #104
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…

Why oh why do people want a value to have different bounds depending on which system it is used? This is a source of huge confusion and why people stick to uint8 and other precise types

On 64 bit systems you can have large arrays that are bigger than a 32 bit int. For example, it's nice to be able to load a >2GB file into a byte array.

For comparison, Java's int type is 32 bits on 64 bit systems, but then this limits the array size. It seems like a lesser evil to have a platform-native int type than to limit the size of arrays (especially since servers can be expected to increase their max memory going forward).

Of course, standardizing on 64 bit ints instead would require emulating them on 32 bit systems, when they can't support that much memory anyway (you could argue that 32 bit systems don't matter much anymore, but if you really don't care about ever running on them, then you can just treat 'int' as 64 bits and not variable size).

Re: Go 2, here we come

#239

Post by infogulch »

infogulch wrote: post #23

I really really hope Go 2 can do something about `context`. Context is the biggest hidden wart of Go. We need the capabilities of context in different packaging.

Because I think discussing actual solutions is better that just complaining, this is my current favorite design document to address context:

Go Context Scoping [1] by Eyal Posener. It even has a working PoC implementation [2] which is pretty ergonomic and could become even moreso with language integration.

I think this concept solves most of the problems we currently face with context. As a consequence of making context available per goroutine it basically becomes an implementation of gouroutine-local storage. But this is more because context.WithValues exists in the first place than because of this proposal. In fact context has effectively become the de-facto GLS anyway, except it makes everyone's code ugly to do it.

[1]: https://posener.github.io/context-scoping/

[2]: https://github.com/posener/context

Re: Go 2, here we come

#240

Post by sjellis »

vram22 wrote: post #103
treis wrote: post #48

Earlier quoted context omitted.

>I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those…

> 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).

Post reply on HN