slimsag

84 ms·

931.
by slimsag 12y ago
Using a plain-old mutex in Go isn't encouraged. As you said, the memory model is _share by communicating_. Sometimes, yes, using a mutex makes more sense -- and that does introduce the possibility of a data race. If you follow effectiv
932.
by slimsag 12y ago
Background: I have been developing in Go for ~5 years, and Rust for probably less than 2 months. - Both Go and Rust use bounds checking on arrays/slices (which means out-of-bounds accesses are not allowed). - Go is garbage collected, s
933.
by slimsag 12y ago
That's silly. Can I then say that the Cocoa GUI from OSX is therefore the "Unix GUI" ?
934.
by slimsag 12y ago
First off -- this is really impressive! Is the author present here? I wonder: - How is the performance? - Is a GC implemented separately or is the Go one directly used (awesome!)? - How do calls to native JNI things operate (through CGO)? D
935.
by slimsag 12y ago
Is making so much use of macros for code generation really suggested practice in C? It seems like it would be difficult to debug.
936.
by slimsag 12y ago
crawshaw isn't wrong -- and he's also the guy working on Android support. Go's GC scans pointers in the heap. - A 10GB heap with one single heap-allocated []byte will have short <1ms pauses. - A 512MB heap with 500k heap-a
937.
by slimsag 12y ago
As a distant follower of SpaceX it's not obvious to me if the Falcon 9 will attempt a landing this time?
938.
by slimsag 12y ago
It might be possible to interpret Go using exp/ssa; otherwise you'd probaly want to wait till the compiler is converted to Go in v1.5.
939.
by slimsag 12y ago
> Not quite the case (brew install glew glfw3 on OSX) Sure, for OS X and Linux distros. What about Windows? No external dependencies is better all around. > but the problem is more that it requires cgo at all. You'll always be us
940.
by slimsag 12y ago
It's explained pretty well in the doc -- but basically for consistency and ease of use for newcomers. No point in having a bunch of "DONT USE THIS CODE" repositories everywhere. Its confusing. Instead, we have a way going for
941.
by slimsag 12y ago
Basically: to make OpenGL apps in Go you used to have to install a bunch of headers and libraries, and it was a real pain. We fixed it a long time ago, but people used the old version so much we didn't want to break anything. We'r
942.
Go-gl: Massive Overhaul(docs.google.com)
53 points by slimsag 12y ago|11 comments
943.
by slimsag 12y ago
It is solved -- just not widely employed. There is no official stance on package versions, because the core Go development doesn't really need/use it. The Go 1 compatibility guarantees no backwards incompat changes to stdlib. Expe
944.
by slimsag 12y ago
I agree with you: package versioning in Go is solved already. I think the thing that conflicts people most often is that there is truly no "official" opinion on the subject aside from what you mentioned: use a different import pat
945.
by slimsag 12y ago
I don't think it's _always an_ inferiority complex. I've personally run into many situations in which porting a lib to Go is easier -- and more efficient -- than my brain's context switching between multiple languages in
946.
by slimsag 12y ago
godep isn't really meant to be for versioning dependencies. It's meant to freeze source code so that you can reproduce builds 100%. With that being said, I'd recommend http://gopkg.in , or if you prefer hosting you
947.
by slimsag 12y ago
I don't know, but just from your description it sounds like a case of NIH[1]. [1] http://en.wikipedia.org/wiki/Not_invented_here
948.
by slimsag 12y ago
I don't know about "lasting the test of time", but I recently used Hugo (Jekyll clone written in Go) and found it impressive. http://gohugo.io/
949.
by slimsag 12y ago
True, you need to install some things. But these are just: - OS X: Just Go, Git, and XCode (this project doesn't use freetype). - Windows: Just Go, Git, and MinGW. - Linux: Apt can install all dependencies (installation instructions li
950.
by slimsag 12y ago
(I don't know about performance differences) > I've seen a golang informal chat where one of the golang team member advertized using mutex instead of having a huge select, but i wonder if anyone has real experience of the two h
951.
by slimsag 12y ago
Newer Go versions (1.2 I think?) use preemptive scheduling so you don't have to do anything special: that's my point entirely. Goroutines by specification have the potential to run all at the same time, in the exact way that OS-le
952.
by slimsag 12y ago
Very neat! > Go calls its threads goroutines as a pun on coroutines, to indicate that they're lighter than real operating-system threads. A pun? Maybe. But the point of calling them go-routines instead of co-routines is that they _a
953.
by slimsag 12y ago
I don't really understand how they differentiated either. My assumption would be that they somehow determined if a song or album came from another media service through, for example: - Some file metadata (somehow). - Or perhaps by look
954.
by slimsag 12y ago
> And because everything is statically compiled, go binaries tend to be very large. Are you sure it's because they are statically compiled? Not because each binary has DWARF debug symbols in it so that there are useful stack traces?
955.
Azul3D: gfx/window: version 2(azul3d.org)
1 points by slimsag 12y ago|0 comments
956.
Go/Azul3D: Mac OS X Support(azul3d.org)
1 points by slimsag 12y ago|0 comments
957.
Go/Azul3D: Yin and Yang: Using Glow and GLFW(azul3d.org)
2 points by slimsag 12y ago|0 comments
958.
by slimsag 12y ago
Hi, author here. I wanted to let you know that I agree .v0 is strange. I see that now and it was an oversight. We're changing it from v0 to dev now instead: import "azul3d.org/audio.dev" No worries though, v0 will contin
959.
by slimsag 12y ago
This. (BTW, I'm the author, sorry.) Although the renderer is GL 2.X based -- it supports OpenGL 3+ features using extensions. It was written against OpenGL 2.X so that the lowest OpenGL 3 hardware could be targeted.
960.
by slimsag 12y ago
Ew, don't do it by hand. You can use tools like govers to rewrite the import paths to newer versions. It's not hard to manage at all IMHO.

More ›