This is quite offtopic, but if even programmers are using jpeg when they should use png, what hope is there for anyone else? The images this generates have mostly flat areas of all one color - it should have been a png.
[deleted]
From zero to Go: launching on the Google homepage in 24 hours
61–70 of 78 posts
Re: From zero to Go: launching on the Google homepage in 24 hours
#62This is quite offtopic, but if even programmers are using jpeg when they should use png, what hope is there for anyone else? The images this generates have mostly flat areas of all one color - it should have been a png.
I'm working on a game with highly-stylized art that includes a lot of blobs of single colour. It surprised me at first, but the artists have had real gains using JPG instead of PNG. Also, strangely the artifacts give the art a kind of "texturized" finish that's actually kind of pleasant on tablet screens.
Re: From zero to Go: launching on the Google homepage in 24 hours
#63This is quite offtopic, but if even programmers are using jpeg when they should use png, what hope is there for anyone else? The images this generates have mostly flat areas of all one color - it should have been a png.
Maybe it's for performance reasons. I have a web server in go that generate (big) png on the fly and most of the time is spent in the png encoding (mostly the compression). PNG encoding is a heavy task.
Here's (from my blog) a pprof profile of my server : http://canop.org/pub/pprof4353.0.svg so that you can see the burden.
(I didn't make comparisons with other languages so I don't know if Go's png encoder is fast or not, I suspect it isn't)
Re: From zero to Go: launching on the Google homepage in 24 hours
#64Re: From zero to Go: launching on the Google homepage in 24 hours
#65the link is broken. something wrong with golang blog?
Great Firewall?
Re: From zero to Go: launching on the Google homepage in 24 hours
#66Nice try, Pike.
Re: From zero to Go: launching on the Google homepage in 24 hours
#67Earlier quoted context omitted.
Go runs on a single core unless you start using channels and/or threading libraries. So it should be apples-to-apples.
Go runs on a single core if you use channels anyway unless you specify an environment variable (something like GO_MAX_PROCS). Not sure about threading libraries since I haven't really considered using them in Go. I'm actually curious what people are using them for in Go - maybe games?
GOMAXPROCS it is :-).
It's a quick fixup, the runtime will eventually schedule on multiple threads without needing the user to specify anything.
Re: From zero to Go: launching on the Google homepage in 24 hours
#68Earlier quoted context omitted.
You can distinguish between nulls which are errors and nulls that are just the actual return value. That is what err is for . The entire reason Go has multiple return values for functions (such as paths and err in this case) is to avoid having to encode errors in the "real" function result. Now I agree, that this is less nice as say pattern matching and real sum types, but if you know how to appreciate those just swi…
> The entire reason Go has multiple return values for functions (such as paths and err in this case) is to avoid having to encode errors in the "real" function result. That's nonsense, MRVs are tuples (conceptually, Go implemented them with special syntax because... well, it's Go so it could not go with the general principle now could it?), so Go very specifically encodes errors in the function result. And using a su…
Multiple return values are not tuples, Go doesn't have tuples in the type system.
Re: From zero to Go: launching on the Google homepage in 24 hours
#69I can't help but cringe whenever I read Go code because the following: paths, err := filepath.Glob(dir + "/*.png") if err != nil { panic(err) } is repeated over and over again. Didn't we learn in the 90's that exceptions are far, far superior to return codes?
A lot of people in this sub-thread don't buy that return codes are inferior, but they really are. The issue is that the low level code can detect the error and knows some strategies that could be done about it but it's only the high level code that knows what's best (here's the best possible approach [1]). If your library is used by a batch job running on some network-detached headless server it will probably have to…
> A lot of people in this sub-thread don't buy that return codes are inferior, but they really are.
What a great argument, I know better!
Re: From zero to Go: launching on the Google homepage in 24 hours
#70Earlier quoted context omitted.
Yes, basically. As far as I can tell Go is entirely about getting rid of unnecessary cruft and boilerplate and making a practical language you won't hate working in. Inasmuch as most interpreted languages are intended to be practical languages you won't hate working in, they are similar to Go. As far as the actual type system, the reason they feel similar is probably because interpreted languages tend to be duck-type…
> As far as the actual type system, the reason they feel similar is probably because interpreted languages tend to be duck-typed, and so is Go. When you code in an interpreted languages you expect arguments to functions to be of a certain type, where type just means "responds appropriately to methods I call on it". The person you respond to talked about OCaml. From this I infer he at least has some basic knowledge of…
> Your whole second paragraph is unnecessary (and unwarrantedly condescending)
Your whole post is unnecessary and unwarrantedly condescending since all you do is state "truths" like:
> Go is chock-full of special syntax and cases, and Go code is full of cruft
just like that, out of thin air.