3 ms·

> Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. It is not about the s

by arsv 12y ago

> Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. It is not about the size of hello world executable, that is just a symptom. A code smell if you like. There is something badly broken in the dead code (or dead data) elimination area. And I hope that code is in fact dead, because if it is not, add code generation to the list of smelly things. What I suspect I see here is a kind of C++ vtable problem built deep into the language design somewhere. And the reaction is, let's talk about large executables so that it would kinda become not so visible. Or maybe let's take a look at glibc, because glibc is definitely a paragon of clear design befitting a new language. > fmt.Print does use reflection There are two problems with this. The lesser one is why does it need reflection to print a string. The bigger one is why do I see about 600 reflect.* entries in the resulting ELF instead of a single one for the string type.

mholt 12y ago
> The lesser one is why does it need reflection to print a string. It doesn't print just strings. It can print anything. http://golang.org/src/fmt/print.go?s=6420:6467#L221 http://golang.org/src/fmt/print.go?s=6420:6467#L221 After doing your research, you're welcome to submit a magical CL and PR that brings down the binary sizes, then you won't need to argue anymore.
- arsv 12y ago
  > After doing your research, you're welcome to submit a magical CL and PR that brings down the binary sizes, then you won't need to argue anymore. The original link is titled "The State of Go". The first thing I want to know about a state of a new language is whether it works. Then how well it works. Then, maybe, how to fix it and which VCS to use. There is an issue I think is within the range of these two questions, but it is not even mentioned there. So to make life a bit easier for people who like me expect that issue to be discussed first, I posted a comment summarizing (in my opinion) the state of Go. My thoughts on how to fix it are hardly relevant to the current state of Go. > It doesn't print just strings. It can print anything. The fact it is just a string should be statically (build-time) inferable in a strongly-typed language. Reflection, at least as I understand it, implies run-time type information. So the question does make sense. Yes, I understand why it may be needed for a particular implementation of printf, this is why I called it a lesser issue.
  - enneff 12y ago
    > I posted a comment summarizing (in my opinion) the state of Go. Not trying to be rude, but your uninformed opinion is less valuable than you think.
    - frowaway001 12y ago
      Wow, Googlers being Googlers.
enneff 12y ago
> The bigger one is why do I see about 600 reflect. entries in the resulting ELF instead of a single one for the string type.* There is definitely work that can be done to improve dead code elimination in the Go tool chain. The transition to Go will make this easier to achieve. > What I suspect I see here is a kind of C++ vtable problem built deep into the language design somewhere. Don't suspect. Dig into the problem and make some informed commentary. Idly speculating on HN is just spreading FUD, and benefits no-one. You should read about Go's implementation of interfaces. It's not the same as C++'s vtable issue. http://research.swtch.com/interfaces http://research.swtch.com/interfaces

by arsv 12y ago

mholt 12y ago

> The lesser one is why does it need reflection to print a string. It doesn't print just strings. It can print anything. http://golang.org/src/fmt/print.go?s=6420:6467#L221 http://golang.org/src/fmt/print.go?s=6420:6467#L221 After doing your research, you're welcome to submit a magical CL and PR that brings down the binary sizes, then you won't need to argue anymore.

arsv 12y ago
> After doing your research, you're welcome to submit a magical CL and PR that brings down the binary sizes, then you won't need to argue anymore. The original link is titled "The State of Go". The first thing I want to know about a state of a new language is whether it works. Then how well it works. Then, maybe, how to fix it and which VCS to use. There is an issue I think is within the range of these two questions, but it is not even mentioned there. So to make life a bit easier for people who like me expect that issue to be discussed first, I posted a comment summarizing (in my opinion) the state of Go. My thoughts on how to fix it are hardly relevant to the current state of Go. > It doesn't print just strings. It can print anything. The fact it is just a string should be statically (build-time) inferable in a strongly-typed language. Reflection, at least as I understand it, implies run-time type information. So the question does make sense. Yes, I understand why it may be needed for a particular implementation of printf, this is why I called it a lesser issue.
- enneff 12y ago
  > I posted a comment summarizing (in my opinion) the state of Go. Not trying to be rude, but your uninformed opinion is less valuable than you think.
  - frowaway001 12y ago
    Wow, Googlers being Googlers.

enneff 12y ago

> The bigger one is why do I see about 600 reflect. entries in the resulting ELF instead of a single one for the string type.* There is definitely work that can be done to improve dead code elimination in the Go tool chain. The transition to Go will make this easier to achieve. > What I suspect I see here is a kind of C++ vtable problem built deep into the language design somewhere. Don't suspect. Dig into the problem and make some informed commentary. Idly speculating on HN is just spreading FUD, and benefits no-one. You should read about Go's implementation of interfaces. It's not the same as C++'s vtable issue. http://research.swtch.com/interfaces http://research.swtch.com/interfaces