De C a Go, la evolución de los compiladores de Go

Extracto de la transcripción automática del vídeo realizada por YouTube.

so I'm Russ Cox and I work on the go compiler and today the go compiler is 80,000 lines of C code and that's a big problem for us one way to look at the problem is that programming and go is fun and programming and C is not and I don't mean fine

as in just you know fine praval ad programming and go is fun because it's a more productive language than C there's great built-in support for CPU profiling and memory profiling there's a garbage collector so you don't have to track down self-inflicted

memory corruption there's good support for writing tests there's good support for writing code coverage analysis and all of this is missing from see at least in the standard environments that we have to use for portability and it makes writing the

compiler more difficult than it needs to be another view of the problem is the one of expertise writing a go compiler requires a certain amount of go expertise because you have to understand go in order to compile it but then writing any program in C requires

a certain amount of C expertise so that you don't plant a memory corruption bug that you have to track down six months later and so writing the go compiler in C means that the only people who can work on the compiler or have need expertise in both go and

C and the go constrain is fundamental but the C constraint is not and so the solution to both these problems as you've probably guessed is to write the go compiler and go and so then the first obvious question after that is why didn't we do this from

the start well if the start go didn't exist and it's easier to write compilers and languages that do exist although people have people have done it and second once it go did exist it was unstable we would change things when we realized that something

was wrong and it was much easier to make the changes when we didn't have to think about the dependency cycles caused by the compiler still needing you know gonna compile itself and then finally an important point is that go was not intended for writing

or sorry go was intended for writing networked and distributed system software and not for compilers and the programming languages are shaped by the you know examples you have in mind in your building while you you create the language and avoiding the compiler

meant that we could focus on the real target and not make decisions that would just make the compiler easier okay well given all that why should we do it today and well go exists so that's good that's why we're all here with the goal one point

X releases go is stable and although our initial focus was building servers go has turned out to be this very nice general-purpose language and there's lots of big programs now there's no danger that the compiler will be the only big program I'll

have this undue influence on the language design also we're pretty much done with the language designs so that's another reason we're not worried about that so now the question is like well how do we convert it and so one option is just to start

over and if you start over you know there's several main years of effort in the compiler we don't want to repeat them we don't want to not be able to do anything else for the next year or two another is to sit down with the compiler and translate

it line by line by hand and that would be you know tedious and time-consuming and error-prone and so the option we've chosen instead is to make a program do that for us to convert the C code to go code automatically using a tool that we're writing

and once the tool is ready and the deployment story has worked out we run the tool one day and all the C code people working on turns into go code and from that day forward we work on the go version and I should point out that that's not the end of the

story right just having it written in C code but in go syntax is is definitely not the end you know once it's written and go we can actually apply the profiler and see like where it's spending its time whereas it spending its memory cleaning up and

have actual package boundaries within it and all that sort of stuff but that's not what I'm gonna focus on today so the focus on today is just this conversion from C to go and if you remember the go fix tool that we used when we did you know before

go one point X when we make API changes this is sort of like one big go fix and so you know this talk is about converting C to go and so the first thing I have to do is actually explain to you what C is because not ever in the audience actually knows C and

so I'm just going to review some of the details so C started at Bell Labs in the early 1970s and the first real big creative burst that produced what we recognize as C today happened around 1972 and if you're interested in the history of C Dennis Ritchie

wrote this a paper called the development of the C language sorry development of C language at the history of program language conference in 1993 and in it he wrote that C is quirky flawed and enormous success and then he went on to write while accidents of

history surely helped it evidently satisfied a need for a system system implementation language efficient enough to displace assembly yet sufficiently abstract and fluent to describe algorithms and interactions in a wide variety of environments it's the

end of the quote and it's exactly these quirks and flaws that make this conversion from C to go interesting so first of all the data model C was implemented on a pdp-11 with 24 kilobytes of memory and in that context every byte counted and because the

early users of C were coming from assembly the programmer was placed very firmly in charge of the memory and in that same paper Denis wrote that you know off stack dynamically allocated storage is provided only by a library routine and the burden of managing

is placed on the programmer if you've written C you're used to having to remember when to call free and when not to call free you know C is hostile to automatic garbage collection and you know it goes the opposite the language in the runtime is clearly

in charge of memory there's no pointer address arithmetic and will free things for you and then there's C types these were a big advancement of C over its predecessors but they're really only a convenience to the programmer there was no intent

to provide safety they're there for convenience and unions are a good example of that will see unions in a little bed and another interesting thing about the types is that C conflates this idea of a pointer to one element and a pointer to an array of elements

[ ... ]

Nota: se han omitido las otras 3.352 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.