Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From zero to Go: launching on the Google homepage in 24 hours

blog.golang.org

Post reply on HN
Print view View original

71–78 of 78 posts

Re: From zero to Go: launching on the Google homepage in 24 hours

#71

Post by technomancy »

sirclueless wrote: post #38
technomancy wrote: post #32

Earlier quoted context omitted.

I see that claim everywhere as well, and I don't understand it. Does it just mean "it has a type system that you won't hate"? There are still plenty of type declarations in that code, whereas if you ported it to OCaml they'd all be inferred.

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…

The problem with "it feels like a dynamic language" meaning "you probably won't hate it" is that it's somewhat insulting to existing statically-typed languages that are actually pleasant. It sounds all right if you've only ever been exposed to Java or C, but it's not like Go is the first language to have a good type system. It's especially odd considering Go's inference isn't able to handle all the types in even such a short sample.

Re: From zero to Go: launching on the Google homepage in 24 hours

#72

Post by Dylan16807 »

BarkMore wrote: post #40
comex wrote: post #39

Earlier quoted context omitted.

How so? If the character is any value less than '0' (say, '!'), p will be set to a negative value.

'0' has the decimal value 48, not zero. '!' has the decimal value 33. Here's a demo program that you can run from your browser: http://play.golang.org/p/qAKG9j5E4V All characters have values greater than or equal to zero.

comex said less than '0'. 33 minus 48 is negative.

Re: From zero to Go: launching on the Google homepage in 24 hours

#73

Post by masklinn »

4ad wrote: post #70
masklinn wrote: post #59

Earlier quoted context omitted.

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

> just like that, out of thin air.

Oh I can expand on that if you want, though I expect you don't and you'll just handwave it away as is usually done of criticisms of Go.

* Go uses a special syntax for multiple return values, this is a restriction on the more general concept of tuples. Go could simply provide tuples instead of having MRVs be a syntactic special case. This makes the language smaller and simpler: instead of `,` being a magical syntactic feature of the language, it's just an operator for building tuples.

* Go has generic types, but only for blessed types implemented directly in the interpreter (map and channel, for instance). All user-defined types are second-class citizens at best. That's elevating special syntax to new heights.

* Go has two different initializers in `new` and `make`, `new` is garbage as it only allocates and can't be used to initialize and `make` only works with (again) a restricted number of types living directly in the runtime, which get to have special treatment for the only reason that new is insufficient.

* Talking about things only builtin types get, only builtin types get to be indexed via an operator, this is special syntax dedicated solely to builtin types.

* `defer` and `go`. They feature special magical evaluation order (they have to be a complete expression, all inner expressions are evaluated immediately and the outer one and that one only is not evaluated) which leads to weirdness like creating an anonymous function and calling it immediately, and they're not actually needed due to Go having anonymous function in the first place, both could be builtin function taking a callable instead of being special forms and they'd work just as well (better in fact, since their evaluation model would be the same as everywhere else in the language). These special cases are even weirder when you realize that `recover`, which needs to hook deep into the interpreter and do actual strange stuff to stop the stack unwinding in place, is a builtin function rather than a special form.

That should be a good start, 4 clear-cut examples of special syntax (either unnecessary or which could/should be general) and one of a special case.

Re: From zero to Go: launching on the Google homepage in 24 hours

#74

Post by enneff »

shadowmint wrote: post #54
nickik wrote: post #11

Maybe its just me but all blogpost about go read like they where checked by a marketing guru after the have been written. The always enforce the same basic points, it always sound the same. If I somebody says "go" my mind alwasys jumps to "feels like a interpreted language".

Well, when you're looking at posts by someone who loves a language about that language, its not really that surprising to see positive feedback in it; and that feedback is often about the expressive syntax being nice (edit ...but that said, I wouldn't mind some impartial coverage. Its stuck me several times how defensive and no-I'm-right the go crowd gets when anyone dislikes it. Try jumping on the google group somet…

There have been many, many blog posts critical of Go in the past couple of years. They're not hard to find. If you're looking for impartiality, the blog of the people who created Go is not the place to look. I am going to keep pointing out how great Go is, because I use it every day and I haven't ever had so much fun programming. That's the truth.

You mischaracterise the blog post about the C++/Java/Scala/Go paper. It was written by Russ Cox, and he used it as an opportunity to demonstrate our profiling tools and how they can help you write fast Go code. (that it refutes the claims of the paper is just gravy ;-)

It begins: "At Scala Days 2011 a few weeks ago, Robert Hundt presented a paper titled “Loop Recognition in C++/Java/Go/Scala.” The paper implemented a specific loop finding algorithm, such as you might use in a flow analysis pass of a compiler, in C++, Go, Java, Scala, and then used those programs to draw conclusions about typical performance concerns in these languages. The Go program presented in that paper runs quite slowly, making it an excellent opportunity to demonstrate how to use Go's profiling tools to take a slow program and make it faster."

http://blog.golang.org/2011/06/profiling-go-programs.html

Re: From zero to Go: launching on the Google homepage in 24 hours

#75

Post by yesbabyyes »

yesbabyyes wrote: post #22
ariwilson wrote: post #20

Earlier quoted context omitted.

AppEngine instances, unless they're running in a special backend instance, exist in a special containerized machine. These machines are very slow and don't have much RAM - 600 MHz and 128 MB. Based on the source that was posted on the blog, this app was running on a normal instance, as the source did not contain a backends.yaml file. So it makes sense that a Core 2 Duo running at 2.13 GHz and slow CoffeeScript would…

I can't argue with that, though I'm running this on just one core (single process). If I was better with the v8 profiler I would check to see how much time it spends in JS land vs C, since node-canvas is all C, as well as the http parser.

I have added the v8 profiler output to the gist. It seems to spend most of it's time in zlib.

Re: From zero to Go: launching on the Google homepage in 24 hours

#76

Post by masklinn »

4ad wrote: post #68
masklinn wrote: post #57

Earlier quoted context omitted.

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

> Multiple return values are not tuples

Multiple return values are a special case of tuples. Hence the "conceptually" part.

> Go doesn't have tuples in the type system.

Could you explain how you managed to completely miss the part where I say exactly that?

Re: From zero to Go: launching on the Google homepage in 24 hours

#77

Post by danssig »

4ad wrote: post #69
danssig wrote: post #46

Earlier quoted context omitted.

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!

Do you know how to read? I explained why in the rest of the comment and even provided an article that expanded on it!

Re: From zero to Go: launching on the Google homepage in 24 hours

#78

Post by sirclueless »

masklinn wrote: post #73
4ad wrote: post #70

Earlier quoted context omitted.

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

> just like that, out of thin air. Oh I can expand on that if you want, though I expect you don't and you'll just handwave it away as is usually done of criticisms of Go. * Go uses a special syntax for multiple return values, this is a restriction on the more general concept of tuples. Go could simply provide tuples instead of having MRVs be a syntactic special case. This makes the language smaller and simpler: inste…

Here's some kneejerk devil's-advocate responses to some of your points. As an idealist I generally agree with you, but I can see practical arguments against many of your nitpicks:

* Having first-class multiple-return as part of the specification allows compilers to generate stack/register allocated return values. If the comma operator were a tuple-constructor, then every multivariate return would be a heap-allocated structure, which might have significant performance implications. (I don't know if the Go compiler actually takes advantage of this on any architectures, but the possibility is there.)

* Agreed. Go's way is perhaps simpler, but definitely limiting.

* Here I think Go does things entirely wrong. I actually like that `new` only allocates, because it lends itself to designing very minimalistic and elegant data structures, something that I feel gets out of hand in many large programs in other languages. Being a GC'ed language, I'm OK with the idea of just exporting and documenting some static initialization functions along with the type. But that begs the question of why `make` exists, since it is basically a first-class syntax feature for initialization of the magic builtins that need it. Consistency, please.

* This is pretty silly, I agree.

* I can see definite reasons why the evaluation order of `defer` and `go` should be as they are. Here's an example use case: I want to defer a statement to print the current value of a local variable. If defer took a callable, then the only way I can see to do that with Go's current syntax would be to (1) define a function that closes around my variable and returns (2) an anonymous function that calls fmt.Print(myvar), and (3) evaluate the original function with the local I want to close around. If you allow more syntax alterations, I suppose you could properly generalize to something like C++11's lambdas where you explicitly state those variables that you want in the closure so that you only need to write one anonymous function, but that is complicated as all hell. The 90% use-case here is `defer Close(abc)`, so even needing the syntax for one anonymous function feels more crufty than the occasional `defer func() { ... }()`. I much prefer Go's way of just saying "We will close around all of the parameters to the outermost function" because it is wayyyyyy simpler.

Post reply on HN