Live data from Hacker News

Go 2, here we come

blog.golang.org

451–460 of 534 posts

Re: Go 2, here we come

#452
post #8

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

That made me remember part of an interview done to Dennis Ritchie back in 2000:

  When I read commentary about suggestions for where C should go, 
  I often think back and give thanks that it wasn't developed 
  under the advice of a worldwide crowd. C is peculiar in a lot 
  of ways, but it, like many other successful things, has a 
  certain unity of approach that stems from development in a 
  small group.

Re: Go 2, here we come

#453

Earlier quoted context omitted.

I am misunderstanding or really go is using the ‘int’ type that can be 32 or 64 bit depending on the system that it runs on??? If this is the case I think that is crazy and I can’t think of any useful use case for it. If it’s not the case then please explain me what that proposal is really about...

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…

I would use int and long like in C# for example, with no magic int that can be 32 or 64 bit depending on the platform to avoid any confusion.

Re: Go 2, here we come

#454
post #103

Earlier quoted context omitted.

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

Elixir's IEx.pry/0 function, that opens a REPL at a particular point of execution, is probably the stdlib function I call the most while developing. In a compiled language, to boot.

Wow, that's cool. Wonder how it works. Does it spawn an instance of the REPL with your app and its current state?

Re: Go 2, here we come

#455

Earlier quoted context omitted.

It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. I’d much rather a novice interact with generics, where the compiler is a safety net, than with void * and interface{}.

>> It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. That's not the case anymore. We have C++ which has generics and "fixed" C's lack of complexity for sure...Now for some 'weird' reasons some people still use C. Wonder why ?

It is not the case since 1993, when CFront was dropped.

In certain domains like UNIX like OSes, I don't see C ever going away, due to the infrastructure, symbiotic relation with the OS that gave it birth, and the culture.

Re: Go 2, here we come

#456
post #351
post #343

Earlier quoted context omitted.

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.

What kind of "long" are you referring to? Most programmers would think of a C long, int64, not a Python long, bigint.

Maybe people ought to self-select, but that would mean they'd need the training or experience to recognize what they don't know. It's often the most ignorant people that believe they have the most expertise.

Re: Go 2, here we come

#457
post #81

Earlier quoted context omitted.

I wonder how many people got the joke without reading the link. Good one, boss.

I did because I'm a native speaker of English, am familiar with "goto considered harmful", and I noticed Dijkstra in the link.

>I noticed Dijkstra in the link.

That's how I figured out the joke too - that plus the start of the comment :)

Re: Go 2, here we come

#459
post #371

Earlier quoted context omitted.

I don’t know about threatening to leave Go, but I’ve definitely seen a lot of posts claiming Go is better without generics.

The more nuanced and better side of that is that any language is better without badly designed and badly implemented generics.

Maybe the even more nuanced side is that a language that can't conjure a safe and well designed generic has a badly designed type system in the first place

Re: Go 2, here we come

#460
post #266

Earlier quoted context omitted.

Is there a definitive source for the "average" programmers target? I'd always considered it a tongue-in-cheek response to architecture astronauts who sneer at Go's simplicity.

“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” -- Rob Pike From…

Have you checked that he actually says this in the talk that you're linking to? I've seen this quotation repeated all over the place, but I've never been able to source it. It sounds more like a hostile paraphrase than a word-for-word transcription.
Post reply on HN