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

221–230 of 534 posts

Re: Go 2, here we come

#221

Post by nerdwaller »

gauravphoenix wrote: post #150
nerdwaller wrote: post #125

Earlier quoted context omitted.

Have you tried go modules since 1.11? It's significantly simpler now than it was before.

I haven't yet. I hope a good eco-system develops around them. My biggest gripe is that there are just too many approaches in Golang when it comes to the dependency management.

Definitely true, the hands-off approach they took seemed strange to me - as others make that one of the core tenants of the community early on. Since I have been in the ecosystem it's been `go get`, `vendor` directory, the various community ones, and now modules.

Re: Go 2, here we come

#222

Post by ChrisCinelli »

asien wrote: post #26

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. Haven’t tried it since. Hope lots of this change to make the language more welcoming for Newcomers to the language.

I agree with the package management system and $GOPATH. I would add that is awkward that most of the libraries are not thread safe when go routines are core to the language.

Re: Go 2, here we come

#223

Post by quickthrower2 »

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.

I get you point. I'd probably go float/double precision for that task.

Re: Go 2, here we come

#224

Post by viraptor »

coder543 wrote: post #218
13415 wrote: post #86

Earlier quoted context omitted.

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…

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

Re: Go 2, here we come

#225

Post by throwaway34241 »

toyg wrote: post #216
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…

The subset of Go users who deploy on 32bit hardware in 2018 and care about performance at that level, is likely to be vanishingly small.

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 future 32 bit systems become totally irrelevant for Go users, maybe a release of Go could drop support for it altogether and make int an alias for int64, and save people some type casts. 32 bit systems probably aren't at that point yet though.

Re: Go 2, here we come

#226

Post by AnimalMuppet »

bsaul wrote: post #97
icholy wrote: post #8

> Go 2 will be much more community-driven. Please no ...

There must be some very angry people downvoting on this comment section today. Go is very opinionated and it's quite obvious that its original design being so radical (no class, no inheritance, no generics, no macro) was only possible because it was designed by a few very experimented people with a very specific goal in mind. I'm also worried about how being "community driven" will change the philosophy of the langua…

I think "community driven" means less than you fear. I think it means that community feedback is used to push the language in directions that scratch some of the major community itches. That seems perfectly reasonable to me - more reasonable than making changes in a vacuum, in fact.

But I don't think that they're going to let the community run wild and completely change the character of Go. I think they're looking for wins that matter to users, but wins that are possible within the framework of what Go is.

Re: Go 2, here we come

#227

Post by wishinghand »

13415 wrote: post #102
freedomben wrote: post #37

Earlier quoted context omitted.

I apologize for asking a question that will likely lead to a flame war regardless of your answer, but which is better? I've used Go for a while for certain apps, but as a primarily functional programmer I find my way of thinking often clashes with the language (and I also don't like the verbosity). So, do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than G…

This 'question' is bound to go up in flamewars, but here is an honest and unbiased answer by someone who has taken a look at nearly every language on the planet (a hobby) and thinks that both languages are a bit crappy from a general programming language perspective but quite usable in practice. Go is good to get things done quickly. It has a vast ecosystem and super-fast compilation. It's like a modern BASIC, but mo…

> It's fast enough for most everyday tasks except for real-time audio processing and high end gaming

Have any new languages popped up in either of those spaces or does C++ still reign supreme?

Re: Go 2, here we come

#228

Post by littlestymaar »

copperx wrote: post #96
stcredzero wrote: post #46

Earlier quoted context omitted.

It won't get interesting until they start selecting breaking proposals. From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?

That's a good question because they ostensibly do it to get more users aboard, but in most cases, the result is the opposite (e.g., the Python 2/3 disaster).

The Python 2/3 switch was indeed a disaster, but in term of user gained and lost not so much: the number of Python users skyrocketed since 2007 despite the breakage nightmare.

Re: Go 2, here we come

#229

Post by the_clarence »

adrianmonk wrote: post #156
the_clarence wrote: post #104

Earlier quoted context omitted.

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

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…

You’re trading off security here. Users are going to shoot themselves in the foot assuming that int is this size or this size.

Re: Go 2, here we come

#230

Post by thanatos_dem »

floatboth wrote: post #214
asien wrote: post #26

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. Haven’t tried it since. Hope lots of this change to make the language more welcoming for Newcomers to the language.

hah. GOPATH is the only thing I like about Go. I have all (non-Go) repositories cloned as URL-style paths e.g. ~/src/github.com/user/repo. I strongly dislike the non-standard internals (horrendous custom assembler, direct usage of syscalls instead of libc) and the "developers are too stupid to use this" attitude towards modern language features.

> direct usage of syscalls instead of libc

But go isn’t built on top of C? Why would they add more dependencies that complicate and slow down the compilation process and hurt portability?

Post reply on HN