saynsedit

It's really not that simple.

If there are external groups trying to influence this election, they are not limited to the Russian government. They aren't even limited to governments.

Russia is just the bogeyman du jour of American news media. Many other more capable enemies are completely unreported.

The bogeyman figure is conveniently utilized to spin many stories. E.g. The DNC hack. In this case it's being used to smear Trump's campaign.

The fact is there no substantial evidence Trump is a Russian sympathizer. There is also no evidence that Russia is a Trump sympathizer.

The US has not changed its foreign policy agenda since WW2. There is beautiful continuity from Truman, to Eisenhower, to Kennedy, to Johnson, to Nixon, to Ford, to Carter, to Reagan, to HW Bush, to Clinton, to Bush, to Obama. It's highly unlikely that the next presidential election will have a noticeable effect on our policy towards Russia.

Manafort was hired by many Republican campaigns. Ford, Reagan, HW Bush. Cold War era. He's always been big in the Republican establishment. Check his Wikipedia for yourself.

The story isn't as simple as "Trump is pro-Russian." If that were the case, then Cold War era presidents could be described as Pro-Russian.

Reasonable.

Wow, what a strawman. Seems like someone was blowing off some steam.

Meh, no one ever remembers all those stateful hidden parameters to fork() for process creation. This results in painful bugs later on, possibly affecting security. Speaking from experience.

Python says explicit is better than implicit. I agree in this case.

Face the fact, fork() is fundamentally flawed!

Hillary Clinton is on their board of directors?

Gmail blocks based on IP. If you're running off of a dynamic IP at home you're going to need a smarthost.

If you're running from a VPS you may need a smarthost.

With Rust zero cost futures, only one memory allocation is done for the entire chain of futures. It's not doing an allocation for every callback.

This makes it comparable to using a stack. In an M:N solution, the stack is usually (but not always) allocated similarly (e.g. using malloc).

You can't get around page fault blocking with user-space M:N threading. It will be approximate until there is a way to do that.

I see your cgo analogy but at the same time it's much less pronounced there since the programming interface is the same, the programmer is supposed to assume everything will work as it should (even if it doesn't always). In this case it's a different programming interface and I think that stresses the issues.

Regarding your comment on preferentially having control over blocking/async code. I think that's right. At the same time, some C++ programmers would say that they prefer having to think carefully about how memory is managed in there program (say, for the benefit of fast no bounds checking). C++ draws a line, Rust draws a line, Go draws a line, Java draws a line, and Python draws a line. These lines are somewhat about technical superiority and somewhat about programmer identity/preference but they are mostly about domain-specific constraints and necessary tradeoffs. This futures-based approach will be sufficient (if somewhat inconvenient) where Go/Erlang can't be used, e.g. where GC pauses are absolutely intolerable.

It's my understanding that the alternative green thread runtime used stack swapping.

What I'm referring to here is the same futures method under the hood but transparent to the user.

It's also my understanding that there were unrelated engineering constraints that caused it to be unwieldy, such as binary size. I believe it's possible to provide an alternative runtime without it necessarily affecting the main configuration or limited environments like embedded devices.

System call context switching is cheaper than and different from thread/scheduler context switching.

I think this is becoming a semantic argument.

I think we all understand that Rust/C++ closures don't necessarily allocate memory. His point is simply that by using a rust closure to asynchronously handle an event a heap allocation must be done. Compare to the stack swapping method of classical coroutines, which wouldn't require a heap allocation.

I recognize that with Rust zero-cost futures, one big heap allocation is done for the entire futures combination and is roughly analogous to one big eager stack allocation for a coroutine.

He's talking about the difference between swapping the stack pointer and executing a single "jump" instruction vs initiating a full function call (pushing argument(s), function prologue/epilogue)

Right, there may be a lot of back and forth marshaling between using thread pools and not depending on whether the library you're using is futures based or not.

Maybe you use one library that is futures-based and one that isn't. Maybe the library you use is mostly non-blocking except for one use of sleep() or another esotorically blocking call. It's just annoying and prone to error. Most people may not even be aware of the subtly blocking nature of the code they use in their futures-based project.

This is what I mean by having two different languages. Libraries written for one aren't always/simply compatible with the other. You'll have a growing community of nominally "futures-based" rust libraries too.

This is why people use Go or Erlang. It just removes the need to have to think about this. Not saying they are generally better than Rust, and some Rust people may even like having a futures-based sublanguage, but I suspect most programmers will be loathe to have to deal with the extra mental tax.

Big downside is now you will have a dichotomy of functions that block using futures and functions that block at the OS level and no sane way to intermix them. Rust essentially becomes two languages. Async/await sugar doesn't fix this.

Would be great if functions could be written in a general way for both IO models and users could select the implementation at their convenience.

This is missing his point. "Increment" is called outside of its scope when the epoll triggers. If "counter" is stack allocated that would cause a segfault, so it must be heap allocated which is his point.

Are libmill and Go's approach the same? I.e. Holding concurrent state in multiple stack frames? What causes that to have degraded performance?

Is this new approach different because instead of stack frames you just have dynamically allocated callback state?

Also Hawaiian Pidgin (not a literal pidgin).

I think there is an assumption underlying your belief that non-violent movements need complementary violent ones for state recognition: that non-violent movements can't gain majority acceptance by the population (without needing a complement).

I believe they can, furthermore I believe that the state is unable to ignore a majority non-violent movement. One example is the gay rights movement. Once critical mass is reached and culture is changed, politicians change their tune, and laws practically unwrite themselves.

In the case where a minority non-violent movement necessarily stays just that, then yes I think there is a valid tactical argument to be made in having a complementary movement.

I sense shades of implication that the effectiveness of MLK's non-violent resistance movement is a convenient docile mythology for the ruling class that ignores the other simultaneous aggressive challenges to the power structure, e.g. BPP, Malcolm X.

That may be so... history is written by the victors.

I do know this: the path to success for any minority movement is the path to becoming accepted by the majority.

A growing violent movement gives a virtually infinitely powerful state legal and moral justification for wiping you out.

A peaceful movement gives the state no justification for stamping it out with force. It must be challenged at an intellectual level.

Sure the current media environment is manipulative... but it's nowhere near as bad as it was in the past. Watch national news from the 60s, you'll see what I'm talking about. Also we have the internet now, every falsehood the media spreads is immediate debunked and it seems they know that.

The truth can't be suppressed forever. As MLK said, "The arc of the moral universe is long, but it bends towards justice."

This is why I think non-violent resistance as a tactic is the best chance any movement has for success when normal legislative channels have failed.

I hope you're not implying that the logical conclusion of "standing up to the bullies" is police murder.

Ever heard of non-violent civil disobedience? It was popularized by a little known guy named Martin Luther King Jr. He got it from another guy who went by the name of Mahatma Gandhi.

Wait, if both China and the US meet those criteria then where is the dichotomy? Wouldn't they both then be bazaars?

That's fair and makes sense. Still, do you have a source for that type of CA policy? With all due respect, I can't tell if this is just your opinion or a codified threat model.

Look at the new MacBook airs motherboard sometime

Source?

I remember reports in the past decrying CAs for issuing certificates for phishing sites in the style of "gooogle.com" etc.

Be more confident and you'll get any job you want. No one here on HN knows the future and you know yourself better than anyone does.

It does, I stand corrected.

One litmus test to check the usefulness of an abstraction is to see if it conforms to existing laws of the specific case.

Let's use distributivity of AND over OR:

    a & (b | c) = a & b | a & c

This also works in the abstraction of Boolean algebra to normal algebra:

    a * (b + c) = a * b + a * c

What about with your digit MIN/MAX abstraction:

    MIN(a,MAX(b,c)) = MIN(MAX(a,b),MAX(a,c))

Well... No, this does not generally hold. If b and c are both larger than a, then this equality fails.

Distributivity is a pretty important property. Without it, your MIN/MAX algebra just has commutivity and associativity which arguably aren't very unique considering all other possible commutive/associative functions. In any case, losing a property dramatically decreases the usefulness of your algebraic abstraction.

Another wart in your abstraction is the missing NOT operation, further deteriorating its usefulness.

Just because the MIN abstraction works for the AND case, that's not enough to make it a worthwhile abstraction. What happens when you want to do more complex yet natural operations like a & (b | c)? In the same vein, AbstractManagerFactoryFactory may seem elegant now, but it may make it harder for new code to do trivial things down the road.