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

Go in Go

talks.golang.org

Post reply on HN
Print view View original

141–150 of 156 posts

Re: Go in Go

#141

Post by the_why_of_y »

boomlinde wrote: post #135
the_why_of_y wrote: post #128

Earlier quoted context omitted.

Because C is a very low level language, it imposes very little architectural decisions on higher levels that could cause impedance mismatches. For example, you wouldn't want to implement a garbage collector in a garbage collected language; C won't get in your way. This is also why there are loads of C libraries out there: they can be used with bindings from essentially any other language, which is generally not true…

> Because C is a very low level language, it imposes very little architectural decisions on higher levels that could cause impedance mismatches. Remember that it also enforces the idea of types, scopes, blocks, functions, the heap and the data stack quite strictly. It might be a very low level language compared to something like Java, but in terms of being unassuming of architectural intent, I can't say that I agree…

Indeed it enforces some function calling convention, which may be an issue if you want to compile a high level language via C, particularly since C does not guarantee tail call optimization.

Also there's no fast way to check arithmetic overflow from portable C, which limits bignum performance.

Due to these limitations better portable assembly languages like C-- have been designed; these days LLVM bitcode is an option as well (which is not actually portable IIRC...).

Re: Go in Go

#142

Post by kinghajj »

haberman wrote: post #119
Zikes wrote: post #107

Earlier quoted context omitted.

Slide #9 mentions they use the unsafe package in the GC to deal with pointers as raw bits.

But does the GC run on the GC's own runtime data? Can the GC be interrupted by itself if it takes too long or uses too much memory? It seems like there are several things about the GC that would need to be special-cased, since the GC is implicitly invoked by the runtime.

I would assume not. GCs are typically invoked by requesting allocation. Since the GC (presumably) uses lower-level OS facilities to allocate memory, it wouldn't need to recursively invoke itself.

Re: Go in Go

#145

Post by ufo »

rsc wrote: post #113
jballanc wrote: post #57

Earlier quoted context omitted.

Right, but if someone surreptitiously deleted all Go compiler binaries from the world, then we'd have to go back to compiling the C source of 1.4... Of course, that's the nature of bootstrapping! If someone managed to erase all the software from all the computers in the world, we'd have to go back and find an "Old world" Mac and use the on-die Forth compiler to write a C compiler so we could start compiling things ag…

Yes, and thanks to version control that would take, what, maybe a few minutes?

Not if all the binaries for the version control systems also go missing :)

Re: Go in Go

#146

Post by pacifist »

boomlinde wrote: post #109
jballanc wrote: post #75

Earlier quoted context omitted.

Well, C is essentially "portable assembly", so it's to be expected...

I never understood this sentiment. C isn't assembly exactly because there isn't necessarily a direct correlation between the instructions the programmer writes and the resulting machine code. To me, this is as contrived as the idea that Javascript is "LISP in Java's clothing" In what possible sense can it be described as an assembler?

Maybe not a direct correlation but:

"By design, C provides constructs that map efficiently to typical machine instructions"[1]

I believe this is what the op was getting at. This is why C is called a "mid level" language.

[1] http://en.wikipedia.org/wiki/C_%28programming_language%29

Re: Go in Go

#147

Post by hobarrera »

comex wrote: post #129
klapinat0r wrote: post #117

Sorry for the noob question, but could someone help me understand how this is (conceptual) possible? I get that you can write a program which compiles language X to machine code, e.g. how python interpreting Go to write the assembly necessary would be technically possible. My question is, how is the compiler generated? If it's written in c, gcc -o compiler, but what is the piece I'm missing when it comes to Go compil…

On a related note, while Go at least has Go 1.4 available to allow bootstrapping from a C compiler for the near future (see [1] for more detail), many languages have no easy way to do so. For example, Rust's compiler was originally written in OCaml, and Nim's in Object Pascal, but both compilers were migrated to be written in the respective languages themselves, and AFAIK both languages have since evolved alongside t…

What also intrigues me is how one would port to a new architecture.

You've got no go1.4 there to boostrap you (new architecture), and you can't get the binary because you're trying to build the first one.

Re: Go in Go

#148

Post by comex »

hobarrera wrote: post #147
comex wrote: post #129

Earlier quoted context omitted.

On a related note, while Go at least has Go 1.4 available to allow bootstrapping from a C compiler for the near future (see [1] for more detail), many languages have no easy way to do so. For example, Rust's compiler was originally written in OCaml, and Nim's in Object Pascal, but both compilers were migrated to be written in the respective languages themselves, and AFAIK both languages have since evolved alongside t…

What also intrigues me is how one would port to a new architecture. You've got no go1.4 there to boostrap you (new architecture), and you can't get the binary because you're trying to build the first one.

Easy, you cross compile from Go on a different architecture. Go apparently has a good cross compilation story, though I don't have experience with it; honestly IMO the whole perception that cross compiling is an unusual or difficult thing comes from poorly designed Unix build systems. Though I suppose this would make a fully automated bootstrapping system a bit messier. (Do the first build in an emulator?)

Re: Go in Go

#149

Post by baby »

comboy wrote: post #6

Oh, I was hoping for some go (aka baduk or weiqi) playing program written in go. These are a bit tricky to google ;)

Me too. It is messing up with golang as well:

> [14:54:36] Topic is Go, the game (not the silly language) ! (the language see #go-nuts

Re: Go in Go

#150

Post by munificent »

boomlinde wrote: post #109
jballanc wrote: post #75

Earlier quoted context omitted.

Well, C is essentially "portable assembly", so it's to be expected...

I never understood this sentiment. C isn't assembly exactly because there isn't necessarily a direct correlation between the instructions the programmer writes and the resulting machine code. To me, this is as contrived as the idea that Javascript is "LISP in Java's clothing" In what possible sense can it be described as an assembler?

I think these days the term "portable assembly" misses the mark. A term that better captures the flavor of C with today's CPUs is "programmable RAM".

C is one of the few languages today that still gives you very precise control over how you use memory. That can be a powerful tool, especially given how important effective cache usage is on chips.

Post reply on HN