enneff

50 ms·

781.
by enneff 11y ago
Some machines run many other jobs, some machines run few. It depends on the resource allocation.
782.
by enneff 11y ago
No.
783.
by enneff 11y ago
And it did and does, provided you have a workload suited to many CPUs. It's just that with the ancient scheduler, setting GOMAXPROCS>1 with a concurrent but not inherently parallel workload would often be slower. It got a lot better
784.
by enneff 11y ago
Prior to Go 1.5 the default of 1 made sense for most typical Go programs, but I know of many users who set the variable differently for better performance. Data point: Inside Google we have been setting GOMAXPROCS=runtime.NumCPU for many ye
785.
by enneff 11y ago
When having a technical discussion we should interpret technical terms with their precise meaning. Rob Pike gave a good talk about this: http://blog.golang.org/concurrency-is-not-parallelism
786.
Go 1.5 max procs default(golang.org)
187 points by enneff 11y ago|140 comments
787.
by enneff 11y ago
I find your perspective a little bizarre. For instance, if we look on a galactic time scale, Lisp and Go were created at pretty much the same instant! It's not fair to Rust to compare it to Go, as if they are at the same stage of their
788.
by enneff 11y ago
The Go project makes stable releases every 6 months. They are extensively tested and fully compatible with all previous major releases. But we do introduce new tools, libraries, and minor language features. Developers almost always want to
789.
by enneff 11y ago
> something everybody would be comfortable with Not possible.
790.
by enneff 11y ago
Of course, as with whenever you change something fundamental like this, some programs will get slower while others get faster. That's the nature of trade offs. It's not really suspect. The benchmarks reflect execution speed. The n
791.
by enneff 11y ago
This event just finished: http://www.meetup.com/golangsf/events/170421402/
792.
by enneff 11y ago
They're not just slides. Some of the slides have code that you can click to run: http://talks.golang.org/2012/concurrency.slide
793.
by enneff 11y ago
Computers are close to two orders of magnitude faster than they were 20 years ago. It would be shocking if the stuff you mention wasn't possible. But it's a silly complaint that some web apps can't keep up with my typing? Ple
794.
by enneff 11y ago
I didn't say that it was slapdash our thoughtless; don't put those words into my mouth. It is truly admirable the great effort that people at Mozilla, Google, and Microsoft have put into improving the web. What I'm saying is
795.
by enneff 11y ago
The web apps I'm talking about are best-of-breed; not just some random crap on a web site somewhere. They're still slower than what I was using on Windows 95. I also disagree that app development was harder back then. Back then we
796.
by enneff 11y ago
I don't care about application development personally (although I'm sad that the dominant programming environments are much worse than they were 20 years ago), but I do care about the performance of the applications that I use eve
797.
by enneff 11y ago
> By contrast, the DOM may have any number of properties twiddled at any time, and the layout engine is forced to deal with that. A random float or something could cause hundreds and thousands of nodes to reflow. So the problem is that D
798.
by enneff 11y ago
Have you listened to any recently released records? They're loud as hell.
799.
by enneff 11y ago
"Loudness wars" has everything to do with mastering and very little to do with the actual medium. Yes, the onset of the loudness wars coincided with the rise of digital distribution, but you can master a record to be just as loud
800.
by enneff 11y ago
What's the difference between "///" and "//go:"? The latter is Go's official convention, it's just that unfortunately some of our older mechanisms predate the convention.
801.
by enneff 11y ago
> Go generate is just sweeping issues under the carpet and say to developers "it has been dealt with", which is ,at the minimum, insulting. Nobody expects a language to be perfect, but sometimes I feel the Go team takes devs fo
802.
by enneff 11y ago
(You left out "// +build", which predates Go 1.4.) We made the decision that "//go:" is the syntax for comment directives. The old ones stay around for compatibility reasons. Previous discussion: htt
803.
by enneff 11y ago
No, they are not ignored. Comments were disabled because we are well aware of the problem space, so further discussion was not adding anything. The garbage collector has been rewritten for 1.5 and work continues on that front. Once the tree
804.
by enneff 11y ago
We have decided. Don't store pointers to Go objects. https://github.com/golang/go/issues/8310
805.
by enneff 11y ago
Looking better, but since the 'go get' step compiles your main.go and puts it in $GOPATH/bin/go-bootstrap, the instructions could be simpler still: go get github.com/go-bootstrap/go-bootstrap $GOPATH&
806.
by enneff 11y ago
I'm a bit confused as to why the initial step is a "git clone". Why not "go get"?
807.
by enneff 11y ago
> Freedom is knowing that we are not bound by our class, our race, our religion, Just as long as you're of Chinese ancestry, of course.
808.
by enneff 12y ago
Relax. They sound just fine.
809.
by enneff 12y ago
The GP's point was that the origins of single-dash single-character flags is the original Unix, not Plan 9 as the GGP had claimed.
810.
by enneff 12y ago
If you joined Google's Glass Explorer program (twice?!) expecting anything but a beta-level device with a short shelf life then more fool you. I don't think they could have been any more explicit about the goals of their program.

More ›