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

71–80 of 534 posts

Re: Go 2, here we come

#71

Post by weberc2 »

jpgvm wrote: post #64
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…

Both are fundamentally different, neither is "better". They are both good at slightly different things. If your desire is to accept bytes over the network and spit back bytes over network Go is going to be a pretty solid choice because that was very much the focus of it's design. However if you want to build an application for a hard realtime environment and you either lack the space for runtime or can't handle GC pa…

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.

Re: Go 2, here we come

#72

Post by christophilus »

prevedmedved wrote: post #55
a_c_s wrote: post #34

Earlier quoted context omitted.

This was one thing COBOL got right: built in support for a DECIMAL data type.

Don't be stupid. A "decimal" type is a floating-point number, just with a different base. It solves none of the underlying problems. (Which is why, incidentally, nothing made in this millennium supports it.)

It’s been a while since I COBOLed, but if I recall, the COBOL decimal is similar to Currency types in languages like C#. (Maybe I’m misremembering.) If I’m right, though, it’s not a floating point number. It’s currency properly handled via integer math under the hood.

Re: Go 2, here we come

#73

Post by pstuart »

igravious wrote: post #43
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…

That would be quite a fundamental change. At the moment _int_ and _uint_ have certain semantics that, if changed, would surely break many applications and libraries that rely on the current semantics. I am finding it hard to think of a more sweeping and drastic change to the core of a language. Having said that, I'm by no means a Golang expert – this is the comment of an outsider looking in. I get that the proposer i…

If these are new datatypes then they would break nothing (ignoring the "int" default part).

> so what is it I am missing?

The Go team has been adamant about avoiding any changes that break existing code. The whole point of Go 2 is that at some point that might have to happen and they're trying to minimize that pain.

Re: Go 2, here we come

#74

Post by DougBTX »

dunpeal wrote: post #53

> We are constrained by the fact that we now have millions of Go programmers and a large body of Go code Are there really "millions" (plural) of Go programmers? Sounds like a bit of an overestimate, no?

Vague estimate is that there are 18 million programmers in the world[1] and that 4% of them use Go[2], so 0.7 million would be a starting point guess as the total number.

Note that these were the first two Google search results I found for "number of programmers in the world" and "percentage of programmers in different languages" so... being off by a factor of 10 or more is likely.

[1] https://www.computerworld.com/article/2483690/it-careers/ind... [2] https://www.statista.com/statistics/793628/worldwide-develop...

Re: Go 2, here we come

#75

Post by meddlepal »

AsyncAwait wrote: post #59
meddlepal wrote: post #41

Earlier quoted context omitted.

Honestly that would be great if it took the momentum out of Go and killed the language. I loathe working in Go.

Then don't, but actively wanting to see something gone that other enjoy is beyond tasteless.

I would love to completely avoid it, and I do when I can, but it has started to creep into every job out there now and especially in areas I spend a lot of time. So just avoiding it is not possible.

I maintain it has been shoved down the industries throat for no good reason other than Google. It does nothing better than any of the existing mainstream languages and in many cases is a large step backwards.

So no, I will not stop railing on Go and my hope it goes away sooner rather than later. Nor will I stop railing on how I think macOS is a cancer in the Unix ecosystem and also needs to die, how JavaScript deserves to be relegated to the trash heap, how Android has fucked the Java-ecosystem, and how Chrome has ruined the internet.

Re: Go 2, here we come

#76

Post by dmoy »

weberc2 wrote: post #54
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.

Actually, the issues you mention are already fixed by Go modules. EDIT: Removed a parenthetical that was based on a misreading of the parent.

No oxford comma:

the performance, the community around it, and vendors support

Re: Go 2, here we come

#77

Post by Zenst »

gnarbarian wrote: post #2

Go 2 Considered Harmful: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...

When I started work in the early 80's as a COBOL analyst programmer, I encountered ideology vs reality of GOTO. When I learned COBOL, I was taught Jackson Structured Programming. No use of GOTO at all, even exception handling. Fast forward in my first week into work and having done a nice JSP program for the task at hand a senior came over with my code and had a chat. Then took me to the system developers who did all the dirty low level assembler code (for sorts and other area's in which speedup was huge over COBOL). Was shown how my approach was far more wasteful of CPU resources and why others would not be able to maintain such code as all the rest used GOTO's. I will admit, it was nicely explained and this is in a time in which mainframes offered the only computer solutions for business of this scale and not cheap.

I will say GOTO's work well for exception handerling, but still doable without. But for speed, though less of a factor today, it still translates as faster code at the low level of CPU runs.

But then, things move on and you will always have that wave of what students are taught being cutting edge compared to what is actualy in use in work. A friction many would have encountered in one form or another, even today. Be it style, design or language/tools choice. What is the best today, may well be outdated tomorrow, but you have to maintain that legacy investment and it is often too costly/risky to rewrite that legacy for something that itself could be legacy the next day.

So as for harmful, well they can spagetti up code if used badly, yet that comes to many approaches and if they are that bad, why do CPU's still have JUMP instructions you could counter-argue.

Oh and well played on the humour.

Re: Go 2, here we come

#78

Post by Symmetry »

christophilus wrote: post #72
prevedmedved wrote: post #55

Earlier quoted context omitted.

Don't be stupid. A "decimal" type is a floating-point number, just with a different base. It solves none of the underlying problems. (Which is why, incidentally, nothing made in this millennium supports it.)

It’s been a while since I COBOLed, but if I recall, the COBOL decimal is similar to Currency types in languages like C#. (Maybe I’m misremembering.) If I’m right, though, it’s not a floating point number. It’s currency properly handled via integer math under the hood.

Decimal floating point is actually an established thing and part of the current IEEE 754 spec. I'm not too familiar with COBOL but pretty much any modern language will offer it through a library or compiler extension. Recent IBM Power processors even have hardware support.

https://en.wikipedia.org/wiki/Decimal_floating_point

Re: Go 2, here we come

#79

Post by tormeh »

meddlepal wrote: post #41
rjplatte wrote: post #6

I'll be very sad if this goes the way of Perl 6

Honestly that would be great if it took the momentum out of Go and killed the language. I loathe working in Go.

Why? It seems like a language that has a more or less stated purpose that it is fit for.

If it's used somewhere where other qualities are more important, well, that's not the language's fault.

Re: Go 2, here we come

#80

Post by geezerjay »

smudgymcscmudge wrote: post #28
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.

If $GOPATH was your biggest complaint, now may be a good time to give it another look. As of 1.11, there's an experimental feature called go modules that lets you avoid using GOPATH. I believe it's going to be non-experimental starting in 1.12.

> there's an experimental feature

That's not a feature but a fix for a design problem, and currently the only fix is an experimental one.

For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.

Post reply on HN