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

251–260 of 534 posts

Re: Go 2, here we come

#251

Post by usrusr »

dmurray wrote: post #233
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…

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

It's like building in special handling for a string type, exactly one instead of a catalog of library options.

I'd say that would fit in quite well with the brand of minimalism that Go is representing, keep the language simple and provide builtins where more convenience is needed. The opposite kind of "minimalism" would be providing tools to allow libraries to define what other languages can only support as special builtins. C++ and Scala went down that road, they minimize builtins by empowering libraries to replace them. That's also a form of minimalism, but not the one chosen by Go.

Tangent: now I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type it inherited from Java or if just reimplements those syntax extras in the standard library using implicits.

Re: Go 2, here we come

#252

Post by dolmen »

infogulch wrote: post #144
Teckla wrote: post #69

Earlier quoted context omitted.

Having to manually pass context through so many functions in code bases is definitely not ideal.

It doubles the surface area of every library that deals with anything related to IO, and forces middle libraries that don't and shouldn't care about context to double their surface area just to support connecting their consumers to their upstream providers. "not ideal" is an understatement.

My contextio package might be useful. Check example: https://godoc.org/github.com/dolmen-go/contextio#example-pac...

Re: Go 2, here we come

#253

Post by jimsmart »

zapzupnz wrote: post #107
weberc2 wrote: post #65

Earlier quoted context omitted.

Pretty sure Go hit 1.0 in 2012 and Swift in 2014. In any case, I think the age is not a significant indicator or driver of stability (at least for these young languages), but rather the community's commitment toward stability. The Swift community definitely seems to value stability less than the Go community.

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…

There’s a tool called fix, it’s already part of the standard Go distribution. In the past (mostly pre 1.0, IIRC?), it’s used to apply changes to one’s codebase when migrating between Go releases that introduce incompatible changes.

https://golang.org/cmd/fix/

Re: Go 2, here we come

#254

Post by icedchai »

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.

Weird syntax? Maybe you should try Haskell, OCaml, Erlang, or even Rust instead. Then come back to Go and tell me if it's actually that "weird."

Re: Go 2, here we come

#255

Post by Vendan »

scott_s wrote: post #241
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 rational practice when your language allows casting pointers to integers. Since the size of the pointer itself will vary based on the underlying architecture, you need an integer type which will also vary based on the underlying architecture.

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

Re: Go 2, here we come

#256

Post by SwellJoe »

Waterluvian wrote: post #141

As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go. There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure…

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 least, it has, so far, for me. Cargo is that answer for packages and for building, and it's pretty good, and there's no debate about how to install or build Rust tools and libraries.

I didn't really find that to be the case with Go, so even though Go is a simpler language, I have been more productive, much more quickly, in Rust. Within a couple of hours of starting my project (with only a cursory glance over the docs and tutorial) I had my project daemonized, had options parsing working, had system calls working, got logging working, etc. It was shocking how quickly I was up and running.

I'd been hesitant to try Rust, because it looks big, and I'm kinda tired of big languages. I just don't have enough time/motivation to study a bunch of nuanced syntax and such; I'll never be a great C++ programmer, though I can muddle through and usually understand other people's C++ code. But, so far, Rust is proving to be one of the easier languages I've learned lately, partly due to the holy path being well-defined, and partly due to strong libraries that overlap my particular project perfectly (being a systems language built by very smart people, it has some very good systems libraries).

I don't mean to imply Go is a hard language, it's not. I picked it up pretty quickly, too. Both are easier to learn than, say, JavaScript, because they're much smaller. But, I agree that there isn't a super clear path forward for a beginner with Go, including with installing and building. You just have to acquire more tribal knowledge to work in Go than in some other languages (but, much less than many others...older languages tend to have tons of that kind of thing).

Re: Go 2, here we come

#257

Post by shric »

mrb wrote: post #187
user5994461 wrote: post #183

Earlier quoted context omitted.

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

Actually C defines the minimum size of "int" as 16 bits, because it defines the minimum range it should support as [-32768 .. 32767] See https://en.wikipedia.org/wiki/C_data_types

Nit: [-32767 .. 32767] C permits ones' complement and sign-and-magnitude as well as two's complement.

Re: Go 2, here we come

#258

Post by austeane »

JulienSchmidt wrote: post #157

This blog post doesn't answer likely the biggest of all questions: Will there be breaking changes? If so, how will those be handled? "As a rule of thumb, we should aim to help at least ten times as many developers as we hurt with a given change" sounds like there might be breaking changes, but on the other hand Robert still talks about including new features in the Go 1 compatibility guarantee. I'd love if the compil…

It is very clear that there are breaking changes for Go 2. However, they are testing out their new proposal-review system using non-breaking changes included in Go 1.

Re: Go 2, here we come

#259

Post by pjmlp »

erik_seaberg wrote: post #202
pjmlp wrote: post #165

Earlier quoted context omitted.

In those 15 years never learned about Java AOT compilers to native code?

GCJ was abandoned. Is there an AOT Java compiler that isn't severely proprietary and more expensive than a stack of laptops?

Just because the majority of them are commercial doesn't change the fact that they exist.

They are more expensive than a stack of laptops, because FOSS made the business of selling software tooling only worthwhile when targeting enterprise customers.

Those enterprise customers have developers using these compilers almost since Java exists.

Re: Go 2, here we come

#260

Post by the_clarence »

nickcw wrote: post #194

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 implementatio…

why would someone shift numbers in the first place? I only shift uint8
Post reply on HN