Readit News logoReadit News
fizixer · 11 years ago
Fun fact: what's common between Rob Pike, Bjarne Stroustrup, Larry Wall, Guido van Rossum, and so many other language inventors?

They're all C programmers!

pjmlp · 11 years ago
Working on UNIX operating systems means there isn't much of a choice in terms of system programming languages.

Why to you think all of them created languages to replace C on their daily work?

There are many reasons to use a specific programming languages besides "I like it".

For example I will never use C on personal projects, but will use it without any complaints if that is what my customers ask for.

jballanc · 11 years ago
Well, C is essentially "portable assembly", so it's to be expected...
boomlinde · 11 years ago
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?

tlrobinson · 11 years ago
Reminds me of the "programming language inventor or serial killer" quiz (warning: Flash + sound): http://www.malevole.com/mv/misc/killerquiz/
microtonal · 11 years ago
Bjarne Stroustrup

Wasn't CFront written in C++?[1] (Of course, the initial version of C with classes was probably written in C.)

[1] https://en.wikipedia.org/wiki/Cfront

pjmlp · 11 years ago
What to expect from an AT&T employee?

Which languages do you think guys at Microsoft, Apple and Google get to choose?

Those developed by their employers or others?

ExpiredLink · 11 years ago
Probably the only C++ program he ever wrote.
ihaveajob · 11 years ago
They have a beard?
yla92 · 11 years ago
Matz (Yukihiro Matsumoto) too!

Deleted Comment

Kurtz79 · 11 years ago
Unless I missed it, it is surprising the lack of benchmarks or mentioning how compile speed compares with the previous iteration.

I'm not saying it would be necessary slower than a compiler written in C, if they wrote the more critical parts in assembler, but you would think compiling speed would be one of the outstanding discussion points, after a major rewrite.

shurcooL · 11 years ago
There were a few slides with numbers and detailed performance graphs in Andrew's preceding talk. See http://talks.golang.org/2015/state-of-go-may.slide#10 and nearby slides.
Kurtz79 · 11 years ago
If I'm not mistaken, these graphs refer to the speed of the code generated with the compiler, not of the compiler itself.
insertnickname · 11 years ago
There was some discussion about it on golang-dev:

https://groups.google.com/forum/#!msg/golang-dev/6obxRcm-rqc...

bojo · 11 years ago
Does the speed it takes to compile the compiler really matter?

Edit: Of course, faster speeds would be interesting to hear about, so great question.

gsnedders · 11 years ago
"We believe it's worth trying again with a new language, a concurrent, garbage-collected language with fast compilation."

Fast compilation is an explicit goal of Go, so they certainly think it matters.

Deleted Comment

Deleted Comment

andrewchambers · 11 years ago
I am most excited for the new SSA backend in go. I have been following commits to it here:

https://github.com/golang/go/tree/dev.ssa

No idea how long it will take to mature, but I hope there are some decent performance improvements once it is fully functional.

bgaluszka · 11 years ago
Just for those who are wondering what SSA is: https://en.wikipedia.org/wiki/Static_single_assignment_form
e12e · 11 years ago
I was exited by this:

> Generate machine descriptions from PDFs (or maybe XML).

> Will have a purely machine-generated instruction definition:

> "Read in PDF, write out an assembler configuration".

> Already deployed for the disassemblers.

(my emphasis)

That coupled with a whole tool chain in a friendly language like go, makes be exited for how this might be used by other language designers. While "compile to go" might not be as attractive as "compile to c" -- it's not half-bad. More importantly it kind of smells like part of this tool chain should make it quite easy to generate machine code quite easily.

Nothing against llvm, rpython/pypy, graal etc - but the more the merrier!

Spiritus · 11 years ago
SSA?
andrewchambers · 11 years ago
Internal graph representation the compiler uses for programs. llvm uses SSA form of programs as its main low level representation. The benefits of SSA is that it enables some analysis and optimization techniques.
comboy · 11 years ago
Oh, I was hoping for some go (aka baduk or weiqi) playing program written in go. These are a bit tricky to google ;)
FlailFast · 11 years ago
Finally, my moment! I submit my own library, which is really meant for two players and scoring...and like much of what I do, was purely pun-driven. Maybe one day I'll add AI:

https://github.com/acityinohio/baduk

erikb · 11 years ago
Have a look at the Go Text Protocol [1] and SGF [2]. If you add these then the strongest existing AIs can already play on your board.

All that said you can of course write your own bots, but Copmputer Go isn't as easy as one might think. In fact it's still considered a much harder problem than Computer Chess.

[1] http://www.lysator.liu.se/~gunnar/gtp/

[2] http://en.wikipedia.org/wiki/Smart_Game_Format

shocks · 11 years ago
Cool! Thanks for sharing.
skybrian · 11 years ago
I wrote one a long time ago. (It does not play well; it's just a port of a Java benchmark.)

https://github.com/skybrian/Gongo

baby · 11 years ago
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

pjmlp · 11 years ago
> Getting rid of C was a huge advance for the project.

> Code is cleaner, testable, profilable, easier to work on.

This is just great!

krzrak · 11 years ago
Looking at the title, my first thought was that somebody is making fun of all those posts "[something] in Go" ;)
haberman · 11 years ago
There is no slide about writing the GC in Go.

How do you write a GC in a GC'd language?

the_why_of_y · 11 years ago
The usual way to do it is to define a restricted subset of the language that has explicit memory management and is statically typed, and implement GC with that.

For example, Pre-Scheme and RPython.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.40...

https://en.wikipedia.org/wiki/PyPy#RPython

Zikes · 11 years ago
Slide #9 mentions they use the unsafe package in the GC to deal with pointers as raw bits.
haberman · 11 years ago
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.

bottled_poe · 11 years ago
Can we trust the go compiler?

edit: This is the link I meant - https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

scscsc · 11 years ago
i.e. can a bug that existed early in the toolchain history propagate in the binaries but not the sources?

c_i is the i'th version of the compiler.

    c1 c2 // c1 compiles c2

    c2 c3 // c2 compiles c3
Source code of c1 has bug, source code of c2 and c3 is fixed. Bug in c1 causes binary of c2 to have bug. Binary bug in c2 causes binary bug in c3.

Laremere · 11 years ago
You can still, if you really want to, build the Go 1.4 from its C source, then compile the go compiler with that result.