HN Theater @HNTheaterMonth

The best talks and videos of Hacker News.

Hacker News Comments on
ECC - Fun Writing Compilers

Joe Armstrong · InfoQ · 2 HN points · 3 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention Joe Armstrong's video "ECC - Fun Writing Compilers".
Watch on InfoQ [↗]
InfoQ Summary
Joe Armstrong presents ECC, an optimizing compiler running on LLVM for writing C compilers for unusual architectures, for implementing DSLs and for experiments with JIT compilation.
HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
A must watch talk, on joearms thinking and humour. talk is about on writing C compiler.

http://www.infoq.com/presentations/ECC-Fun-Writing-Compilers

Jul 07, 2011 · 2 points, 0 comments · submitted by DanielRibeiro
Jun 12, 2011 · kjksf on OpenPGP support in Go
How come you're not bothered by C's numerous deficiencies, like being the one language responsible for majority of security issues, ease of corrupting memory, tediousness of manually managing memory and the fact that half of professional programmers can't decipher C type declarations of medium complexity (http://www.infoq.com/presentations/ECC-Fun-Writing-Compilers).

If safety is your goal, Go certainly gives you more of it than C.

If "freedom to directly manipulate" things is your goal, Go gives you more of it than all other languages. Go has unsafe package which gives you exactly the same freedom to manipulate random bits in memory as C. And if that's not enough, Go natively supports assembly.

Go is interesting because on a spectrum of efficiency and easy of programming, it gives you both very good ease of programming and a good efficiency. C gives you efficiency but no ease of programming. Python and Ruby give ease of programming but no efficiency.

If you looked at Go, it must have been from a very, very far away.

aaronblohowiak
> How come you're not bothered by C's numerous deficiencies, like being the one language responsible for majority of security issues, ease of corrupting memory, tediousness of manually managing memory and the fact that half of professional programmers can't decipher C type declarations of medium complexity (http://www.infoq.com/presentations/ECC-Fun-Writing-Compilers).

Every language choice has trade-offs. To address your specific request, I am not bothered by the issues you raise because there are strategies to ameliorate them. Security issues and corrupting memory largely come from unbounded data. C has fantastic tooling to profile and analyze applications. Unlike Go, there is always something you can do to achieve your desired behavior. YES there are warts and problems a-plenty, but they are well-known and there is a vast collection of people and articles about dealing with them.

I never meant to imply that C was more safe than Go. Erlang is, which I meant to imply with the comment about immutable message passing concurrency. Immutable message passing concurrency is amazingly safe and free from classes of errors that Go programmers still have to deal with (race conditions!) In Go, the canonical style is to pass pointers through channels (and pass ownership along with it.) Two goroutines can still mutate the same object out from under each other, leading to all of the potential issues you run into with multithreading in C.

The Go garbage collector sucks, currently (check out the recent mailing list threads with trivial applications that trip it up.) They know this and it is on the roadmap for development, but it isn't there yet; stopping the world to do your work (and taking a LONG time to do so in perverse cases) is not something I want to deal with. When using a "systems" language, I want to have repeatable and knowable performance.

Using the unsafe package defeats all of the benefits of using Go while maintaining all of its shortcomings. Additionally, there is great difficulty with incorporating existing C libraries (yes, cgo is an option but it does not work with gccgo and it is poorly documented -- for instance, how do you make the Go garbage collector aware of C struct lifetimes?) Even if you stay within the language, you have to choose lightweight go-routines or optimized code generation (gc vs gccgo.)

Another irritating thing is that Go maps cannot have binary data as keys, only certain types (numbers and strings, basically.) Discovering this was not easy, and the suggested answer is to coerce an array of bytes to a string (making a copy) for storage and every time the key should be accessed.

> If you looked at Go, it must have been from a very, very far away.

Just because I have come to different conclusions than you have, please do not assume my view lacks research or analysis.

HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.