It's not just that, it also doesn't have automatic destruction of objects, so any local array or structure containing a pointer needs to be laboriously freed by hand.

And in other words, nobody should be writing anything in C. Ever. The need to be compatible with programs written in C violates my rule against writing anything in C and is therefore not a valid reason to write crypto stacks in C.

> And in other words, nobody should be writing anything in C. Ever.

And in other words, nobody should be listening to thrownaway2424. Ever.

Pure C does not have automatic destruction of objects, but gcc has an extension to do it. Take a look at systemd's source code to see it in action. It's very similar to C++'s RAII, and can also do things like closing file descriptors.

You realize that most lower things are written in or base on C, right.

Yes I am fully aware of the sad state of our industry.

I'm curious, what do you propose the industry use?

Would love to hear the answer to this as well. For the types of thing C is used for, I do not know of another language that can _practically_ be used for the same thing, while maintaining the same level of performance. Rust looks promising but is not mature yet.

You've never heard of C++?

Like BeOS!

C++11? (runs away...)

Isn't Go designed to fill this niche? It's supposed to be a low-level systems language, but with "friendlier" features than C, and built-in concurrency support.

They kind of recanted that statement and said they meant it for "web servers" and stuff like that. However I know there has been at least a window manager made in Go.

I don't think it's the best fit, but it's a lot better than many current solutions. I personally prefer Haskell for anything others would write in Go, however many may find Ocaml or Erlang to fit them better.

However I'm biased and believe that functional programming is a better fit, more bug-free, easier, and simpler for most use cases than imperative programming.

Go is advertised as a systems language but certain things like the lack of manual memory management say otherwise.

Before there was C, there was Pascal. You didn't have malloc in Pascal. At ETH Zurich the standard OS was written in Oberon: it ran directly on the hardware with a garbage collector collecting everything.

Go also has a very highly quality crypto implementation. It has all of the good-code features that gnutls lacks: comments that make sense, unit tests, automatic memory management (of course), useful types, etc.

Compare http://golang.org/src/pkg/crypto/x509/x509.go to https://www.gitorious.org/gnutls/gnutls/source/6aa26f78150cc...

Here is the Haskell version (I think): http://hackage.haskell.org/package/x509-1.4.10/docs/src/Data... http://hackage.haskell.org/package/x509-1.4.10/docs/src/Data...

Other imports/files can be seen at: http://hackage.haskell.org/package/x509-1.4.10/docs/src

It's amusing but I never thought of exceptions as gotos. But that's what they in essence.

How are exceptions like gotos? I don't see any similarity. If by "essence" you mean they jump to a specific line of code, then lots of things can do that - switch/case , if/else, do/while, function calls/returns, etc.