Live data from Hacker News

Tor in a safer language: Network team update from Amsterdam

lists.torproject.org

61–70 of 254 posts

Re: Tor in a safer language: Network team update from Amsterdam

#61
post #35

Earlier quoted context omitted.

To be honest, you can probably also pick up Lisp in a weekend, experienced programmer or not. The syntax is also simpler.

But all those parentheses! I know it sounds like a lame reason to dislike a language, but I've always found staring at Lisp to be so much more difficult and distracting than C-style syntax.

There was an attempt to deal with that:

https://en.wikipedia.org/wiki/Dylan_(programming_language)

Also, Julia was syntactic and/or semantic sugar on top of femtolisp. Got converted to it in first pass with LISP's power doing the rest. Here's Stefan Karpinski on that:

"So ultimately the reasons for Femtolisp are:

1. Scheme is excellent for writing parsers since trees (aka S-expressions) are its forte.

2. Femtolisp is a small, simple, highly embeddable and remarkably fast Scheme.

3. We control it (and by "we" I mean Jeff) and can fix any bugs we encounter."

Yep, No 1 are those godawful parentheses and s-expressions making the job easier. ;)

Re: Tor in a safer language: Network team update from Amsterdam

#62

As a mere average user of computer languages, every time I play around with Go I start wondering how a language like this became so popular. It feels like it was invented in a universe where Haskell, OCaml, Erlang, Smalltalk, Lisp and so many more languages and research in languages never happened.

If you're used to dynamic languages, it gives you type safety and performance for little effort.

I love Python but always wished for a simple, type-safe language; Go gives me that. It's not worse than Python IMHO.

Re: Tor in a safer language: Network team update from Amsterdam

#63

Earlier quoted context omitted.

They were not advised against Go but against cgo. Part of what they want is incremental conversion and cgo is at the same time not-go[0], costly[1] and complex[2], and then you still need to manage the Go runtime (GC & al) from within your C system. That makes integrating the two difficult, especially when you want to replace the existing system piecemeal. A pure-Go rewrite might be an option (in fact Tor seems prett…

go -> C calls have gotten way way cheaper in newer versions of Go. There's still overhead but it's not as bad as it used to be.

It's still absolutely terrible in terms of ergonomics. You're forced to perform manual memory management, etc. I've done it a few times and I absolutely don't recommend it.

Re: Tor in a safer language: Network team update from Amsterdam

#64

Not sure why Ada is not taking off these days. It is mature and has all the safety and concurrency bells and whistles: http://www.adacore.com/uploads_gems/07_safe_secure_ada_2005_... https://en.wikibooks.org/wiki/Ada_Programming/Tasking http://courses.cs.vt.edu/cs5204/sp99/Overheads/6UP/6UPCSPand...

1) Two words: "begin" and "end"; 2) Unix, C is so fundamental to building software, that I think any language that doesn't share syntax with it is doomed. Having a common syntax helps in learning new languages, IMO, and can also be a launching point for differing semantics...

"End" didn't stop Ruby from taking off... admittedly a different crowd.

Re: Tor in a safer language: Network team update from Amsterdam

#65

Not sure why Ada is not taking off these days. It is mature and has all the safety and concurrency bells and whistles: http://www.adacore.com/uploads_gems/07_safe_secure_ada_2005_... https://en.wikibooks.org/wiki/Ada_Programming/Tasking http://courses.cs.vt.edu/cs5204/sp99/Overheads/6UP/6UPCSPand...

1) Two words: "begin" and "end"; 2) Unix, C is so fundamental to building software, that I think any language that doesn't share syntax with it is doomed. Having a common syntax helps in learning new languages, IMO, and can also be a launching point for differing semantics...

I'll give you it's overly verbose even though quite a bit of it was justifiable. The theory of Ada's designers was that people read software more than write it. So, the syntax should be designed to facilitate catching errors in maintenance mode, during extensions, or during integrations. It's done phenomenal at that per industrial, case studies despite having been invented in the 80's when lots of language decisions were still being debated.

EDIT: I keep thinking a different language that acts as a front end w/ a better syntax might be a good idea. It outputs Ada that integrates with the tooling ecosystem. Also, a seemless FFI for C libraries like Julia's.

Re: Tor in a safer language: Network team update from Amsterdam

#66

As a mere average user of computer languages, every time I play around with Go I start wondering how a language like this became so popular. It feels like it was invented in a universe where Haskell, OCaml, Erlang, Smalltalk, Lisp and so many more languages and research in languages never happened.

it was also invented in a universe where haskell, ocaml, erlang, smalltalk, lisp and so many more languages never achieved mainstream adoption. go will never be all things to all people, but it's clearly popular in the niche it's targeting.

Re: Tor in a safer language: Network team update from Amsterdam

#67
post #52

Not sure why Ada is not taking off these days. It is mature and has all the safety and concurrency bells and whistles: http://www.adacore.com/uploads_gems/07_safe_secure_ada_2005_... https://en.wikibooks.org/wiki/Ada_Programming/Tasking http://courses.cs.vt.edu/cs5204/sp99/Overheads/6UP/6UPCSPand...

+1 for Ada. Rust is basically hipster-compatible Ada, which explains why Rust will be adopted and Ada will not.

Repeating this nonsense won't make it any more correct.

Re: Tor in a safer language: Network team update from Amsterdam

#68

Not sure why Ada is not taking off these days. It is mature and has all the safety and concurrency bells and whistles: http://www.adacore.com/uploads_gems/07_safe_secure_ada_2005_... https://en.wikibooks.org/wiki/Ada_Programming/Tasking http://courses.cs.vt.edu/cs5204/sp99/Overheads/6UP/6UPCSPand...

I mean, isn't SPARK basically meant for high assurance things (like Tor should be)?

Case in point:

http://ironsides.martincarlisle.com/

http://www.adacore.com/uploads/technical-papers/SPARKSkein_S...

http://www.anthonyhall.org/c_by_c_secure_system.pdf

Re: Tor in a safer language: Network team update from Amsterdam

#69

Since bitexploder asked, I'll add what I wrote on this on other forums. If it's about secrets or anonymity, make sure you always use a safe language that supports careful control and reasoning about both memory and CPU time. The reason is that this enables covert, channel analysis for vulnerabilities that leak secrets through storage and timing. It's why I wanted Freenet to ditch Java aside from the obvious reasons.…

G'day Nick!

Java is getting an AOT compiler in July (Graal, http://openjdk.java.net/jeps/295) that will let you AOT compile parts, or all, of your program, including the JVM modules themselves. This would seem to leave the GC as the main source of side channel vulnerabilities. The GC itself will become more pluggable as well, with a pure Java implementation. What requirements would you put on a GC for side channel safety? (Ignoring the obvious just allocate a large heap and never GC anything, eventually just restarting the process when it runs out of heap). What if we had a fully concurrent, pauseless GC (e.g. Azul), would that change things?

What other issues would remain in your opinion?

Post reply on HN