Live data from Hacker News

Go 2, here we come

blog.golang.org

351–360 of 534 posts

Re: Go 2, here we come

#351
post #343
post #197

Earlier quoted context omitted.

don't most people compute the mean iteratively when they need to do this? Sure, it goes unseen, but programmers on systems like this are expected to understand the math model and write tests.

Systems like what? My expectation is no, most people make mistakes.

I mean, in C and other low-level languages unlike python, it's generally assumed you have a basic understanding of the machine model and the consequences of arithmetic in limited types.

If most people make mistakes, they should self-select to languages which have properties that protect them from their ignorance. for example, I mostly program in Python using longs so I don't have to worry about overflow.

Re: Go 2, here we come

#352
post #347

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…

Increasing language surface area will generally increase the complexity of all api surfaces written in the language. This has obvious costs.

It’s true genetics will shrink some specific APIs, where they are a good fit.

But they will also be used opportunistically by developers excited to push their boundaries.

Of course you can say “just don’t do that” which works if you have a tightly controlled codebase. But most code is not that, and will be handed off to novices over and over for fixes.

So, it’s a question of whether you cater to the advanced developer who can capably handle a vast toolset, or do you commit as a community to more rudimentary tools, in order to reap the rewards of systemic simplicity.

There is no right answer.

I believe in the future all languages will fork into a simpler novice subset for general use and an expansive language for infrastructure. These will both be valid in the same parser, but the subset will be quarantined at the package management level.

Go, EZ-Go, C, EZ-C, etc

I am writing all of my code in EZ-JS

Re: Go 2, here we come

#353

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

"As for all the folks claiming they'll leave Go if it gets generics"

Baffled at this claim I searched and found one person who really seemed to be saying "if Go changes dramatically...".

This recurring notion that Go fans are anti-generic is not rooted in reality. Instead they simply didn't buy the "either it's there or the language is useless -- generics or bust!" argument that pops up in every Go discussion. It's a fine, if imperfect, language without generics. It's a better language with them.

Re: Go 2, here we come

#355

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

What are generics?0

Re: Go 2, here we come

#356
post #178

Earlier quoted context omitted.

"int" in Go the native index type for arrays. I consider it an error to use it for anything else, and since I've adopted that policy, I've had no particular problem with ints. Probably a good linter idea in there somewhere.

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 the program that will drive the uint "negative", wrapping over to a huge number. Unfortunately, since you get no warning when that happens, it tends to take longer to show up, and without a clear cutoff to say "ah, this is clearly invalid" it can be hard to even program detection code, whereas checking for "less than 0" can be unambiguous.

I'd loooove it if I could easily, cheaply, and universally (i.e., not just in Go, but across all my programming languages) turn on a behavior that says "if this int or uint under or overflows, throw an exception instead of trying to do whatever stupid thing you're going to do". I get the sense this is heading down the road where in 20 or 30 years, this is just going to be common sense. However, we are very early on the road yet from what I can see. Whenever I bring it up, even today, even in this sort of context, it still is generally negatively received. (But not uniformly. A few other people agree. I think momentum is with me. I'm not sure my programming career will live long enough to see it, though.)

Re: Go 2, here we come

#357
post #347

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…

It's people that have seen the abuses of C++ templates. They're very powerful and therefore people tend to want to use them for really complicated things.

Look up things like SFINAE and compile time metaprogramming. Templates were not intended for those things. When they work they're ok, but if they go wrong good luck following the 10 line error message.

Here's an example from Rust:

https://www.reddit.com/r/rust/comments/5nifpm/they_said_rust...

That's what people don't want.

Re: Go 2, here we come

#358
post #178

Earlier quoted context omitted.

"int" in Go the native index type for arrays. I consider it an error to use it for anything else, and since I've adopted that policy, I've had no particular problem with ints. Probably a good linter idea in there somewhere.

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

In general it is nicer to use signed numbers for indices. The actual index can't be negative, true, but differences between them can, and it means you don't have so many dubious sign conversions.

Re: Go 2, here we come

#360

Earlier quoted context omitted.

> they're as un-risky as anything labelled "experimental" could be. Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.

I don't understand what you mean, sorry

For some people and organizations "as un-risky as anything labelled "experimental" could be" is risky enough to be automatically being disqualified from even being considered. There's the label 'experimental', so it can't be used anywhere touching the production codebase regardless of any other arguments.
Post reply on HN