Tor in a safer language: Network team update from Amsterdam • Hacker News Board

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

#191

Post by hckr1292 » Sun, Apr 02, 2017, 6:55 AM UTC

steveklabnik wrote: post #34

masklinn wrote: post #10

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.

I love that the Rust core team is defending Go in a thread ostensibly about Rust and Tor.

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

#192

Post by solidsnack9000 » Sun, Apr 02, 2017, 7:07 AM UTC

JepZ wrote: post #100

sfilargi wrote: post #20

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.

When you talk about Go I think you should start with C. One of my professors used to tell us, that C was built by people who wanted to use it and didn't care about academic style. In many ways Go is just the next step of C. C did not have object orientation and even passing functions around was kinda hard. While C++ tried to bring object orientation to C (total failure) Go decided to keep the core values of C and ins…

> I really like Go, because it just feels right.

I think we've seen a few posts like that on HN and now I wonder, what that means exactly. What else falls under the "feels right" umbrella for you?

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

#193

Post by solidsnack9000 » Sun, Apr 02, 2017, 7:08 AM UTC

oddthink wrote: post #167

Filligree wrote: post #148

Earlier quoted context omitted.

I have yet to meet anyone inside Google who actually likes the language. At best they call it a decent replacement for C or C++, which is damning with faint praise. Lots of people are neutral, of course.

I like it. My brain's already pretty full with trying to get a ML pipeline optimized and launchable, and if I need to write something to read a CSV file, make some RPC calls to a service for each row, and dump the results to a file, go just works. Sure, I could use something like Haskell, but then I'd have to worry about whether I'm accumulating a giant stack of thunks that'll blow up. go just works, and less of it w…

I think in areas where there's a lot of math, the absence of generic collections might prove to be a frustration relative to C++ or Java (both allowed languages at Google).

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

#194

Post by hckr1292 » Sun, Apr 02, 2017, 7:11 AM UTC

nickpsecurity wrote: post #15

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.…

What are good resources for learning Ada/SPARK and MISRA-C?

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

#195

Post by solidsnack9000 » Sun, Apr 02, 2017, 7:11 AM UTC

d0vs wrote: post #62

sfilargi wrote: post #20

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.

Colleagues I've spoken with who use both still say, that Python is "20 times" as productive as Go. For some applications this multiplier likely goes down considerably; but Python holds an edge in a lot of areas.

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

#196

Post by vertex-four » Sun, Apr 02, 2017, 7:56 AM UTC

dullgiulio wrote: post #178

vertex-four wrote: post #120

Earlier quoted context omitted.

I've... never had a problem reading Rust code. It's generally well-typed, and makes good use of "automatic" error handling constructs to ensure errors flow upwards without visually polluting the success case. Whereas with Go code, I have to filter out all the error handling (which often takes up 2/3rds of lines of code, even when it's just "if there's an error, return the error" which it almost always is), wade throu…

You are not handling the error, you are just returning it. More correctly, you would decorate the error: foo, err := bar() if err != nil { return nil, fmt.Errorf("failed to do bar: %s", err) }

Sure, in some cases you want to wrap the error type - Rust handles this by essentially having you create a custom error type which is an enum (which can be done via macros like quick-error and error-chain), and implementing From on it which'd create your custom error type from the BarError. This trait is used by both the try!() macro and the ? operator (which do much the same thing, the latter being the updated syntax):

    let foo = bar()?;

If you need to do something custom in converting bar()'s error into your error type - which is rare - you can use .map_err() like this:

    let foo = bar().map_err(|e| MyError::BarError(e, extraContext))?;

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

#197

Post by masklinn » Sun, Apr 02, 2017, 8:09 AM UTC

Gaelan wrote: post #80

kbenson wrote: post #71

Earlier quoted context omitted.

The email was time stamped as being prior to April 1st UTC, so it's actually less an issue of the recap email being poorly times and more an issue of the post to HN being during a confusing time period.

I mean, the post could have been posted on April 1. We don't know that it was posted from a UTC area.

I believe Sebastian is German (or possibly Austrian), I think the CET date change was last week so we're in CEST (UTC+2) which means it was posted at 30 to midnight local, close enough that it could be just in time for April 1st local.

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

#198

Post by eropple » Sun, Apr 02, 2017, 8:12 AM UTC

hamburglar wrote: post #170

eropple wrote: post #137

Earlier quoted context omitted.

> If you don't enjoy programming in Go, don't do it. Ordinarily, I would agree; I don't really care what people do when writing application code. The way it's filtered into devops tooling makes the choices of Go peoplea problem for me, though. If I'm going to be stuck with a language with bad error handling and inexpressive typing, I'd rather it be Python or Ruby so at least I can leverage dynamic typing instead of b…

Well I could make the same complaints about how ruby has "filtered into devops tooling." If I never see another quasi-DSL that's really just a cute set of ill-specified ruby methods I will die happy.

You're talking a taste thing; I'm talking a correctness thing. The inability to create an easily-managed DSL doesn't compensate up for Golang being actively dangerous when it comes to error management. One of these provides structures for ensuring that you catch errors and can do the right thing, and the other demands that you if-check them upon every invocation of a method that can fail.

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

#199

Post by ZephyrP » Sun, Apr 02, 2017, 8:20 AM UTC

im_down_w_otp wrote: post #82

doktrin wrote: post #79

Earlier quoted context omitted.

> So was Erlang. The language, the runtime, and the standard library were all purpose-built together to solve a real world problem... to build fault-tolerant, distributed network applications. I'm probably outing myself as the lord regent of all impostor plebs, but Erlang is not IMO an approachable language regardless of its origins. Put differently : it looks completely nuts. I'm sure there's a method to the madness…

Erlang is a very simple language. It doesn't look like C, but it has a very basic syntax and a narrow set of core constructs. Elixir by comparison is significantly more complicated, but the fact that it looks tacitly like Ruby is apparently very attractive. I suspect I could sit down with you for an hour and remove all the weirdest seeming bits which feel alien. Such that the rest of it would just feel like any other…

Like you, I am also down with OTP (yeah u kno me) and thats why I have to come to you with a harsh message of love: You've been bamboozled.

    {ok, u_no_me, {down_with, init, [State, Mod, OtherMod, Pid, SomeImportantRefIforget]}, {permanent, brutal_kill, 10000, 9999, 100000, 5, worker}

Is not a genius language construct of a faraway Alien race. It's not elite. It's not even Swedish. It's just limited and unclear. (there are even more unclear examples in the annals of Erlang, but everyone is familiar with consulting and reconsulting the child specification documentation)

There are just so many things that make dealing with OTP nicer in Elixir. This is to say nothing of the meta-patterns that Elixir has driven home: Agents, Tasks, the actual supervisor/worker interfaces themselves. You could go on here.

I haven't even gotten to macros -- Have you ever had to make your own behavior, say for an acceptor/worker pool of some variety (presumably non-tcp, otherwise just ranch that out). Making your own behavior (what armstrong himself called "really advanced") is the easy part here. You've got to create a system where you pass around the TRUE module that holds the correct `handle_call/cast/info` implementation back and forth through the true module and the OTP state parameter.

This whole pattern (which comes with very real runtime costs) just doesn't even exist in Elixir. You just create a macro. A macro that sets all of this up at build time. No complex supervisor hierarchies where you need to constantly inspect each and every message, no custom behaviors, etc. You just have a mostly sane way of sharing software logic to begin with.

You can work up really clever solutions with parse_transforms, even standard "-define", but today Elixir has a totally brilliant solution to this problem and many more classes of problems.

This isn't to say there an't blindspots (beyond "wrap proc_lib/inets/other hated library"). There's minor issues here and there. Process registry naming can get confusing, especially operating between Erlang+Elixir supervision trees. Low-level details aren't nearly as well-publicized in Elixir either. There are even big issues, like the Elixir community leaning more "I'm playing around with Elixir because Phoenix is Webscale" than the grizzled realtime adtech/gambling/finance gurus and so if you want help with OTP platform/VM details, you going to have a harder time.

I first tried Elixir in v0.08. & function capture syntax had just been standardized. I suspect that like me, you tried it then, when it wasn't a fully-featured alternative yet. Things have changed and Jose Valim has a vision for the future of Erlang that I think you'd be foolish not to pay attention to.

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

#200

Post by im_down_w_otp » Sun, Apr 02, 2017, 8:44 AM UTC

ZephyrP wrote: post #199

im_down_w_otp wrote: post #82

Earlier quoted context omitted.

Erlang is a very simple language. It doesn't look like C, but it has a very basic syntax and a narrow set of core constructs. Elixir by comparison is significantly more complicated, but the fact that it looks tacitly like Ruby is apparently very attractive. I suspect I could sit down with you for an hour and remove all the weirdest seeming bits which feel alien. Such that the rest of it would just feel like any other…

Like you, I am also down with OTP (yeah u kno me) and thats why I have to come to you with a harsh message of love: You've been bamboozled. {ok, u_no_me, {down_with, init, [State, Mod, OtherMod, Pid, SomeImportantRefIforget]}, {permanent, brutal_kill, 10000, 9999, 100000, 5, worker} Is not a genius language construct of a faraway Alien race. It's not elite. It's not even Swedish. It's just limited and unclear. (there…

I do pay attention to it. I actually host an Elixir meetup out of my own pocket... going on 2 years now. I'm ~$3000 into a labor of love helping people learn and be exposed to Elixir's various features and help them make sense of its Erlang underpinnings.

Having used both Erlang and Elixir "in anger" there are a whole bunch of things that bug me about Erlang. There are a whole bunch of things that bug me about Elixir too. I'm not sure what any of that has to do with what I said. Elixir is a more complicated and larger language than Erlang.

It has structs (which are weirdly implemented as maps instead of records). It has type-classes/traits by way of "protocols" (which are a whole different layer of metaprogramming that could be replaced with behaviours and data-structure definition convention or dialyzer type-spec'ing). It has the pipe operator (which strangely elides the first argument in a function such that map/2 becomes map/1 when written... why no placeholder sigil). It has Agents (which are something which is confusing to have in the standard library as its a specific implementation of a gen_server which acts as a KV-store which will be really, really prone to data races). It has a fair bit of metaprogramming to be aware of in terms of macros and hooks that trigger at code loading/import time (which forces one to need to be a lot more aware of the inner details of 3rd party libraries being used). It eventually devolves into requiring knowledge of Erlang when attempting to do anything regarding debugging, tracing, or distribution related.

Elixir is a great language, and it has a lot of neat features, and I love teaching it to people and being increasingly critical of Erlang based on advancements in usability and community engagement/feedback that I see happening around Elixir. But I don't really need to be proselytized to about it.