Silk Road did a spinoff where guns were being sold as the primary goods (the Armory) and they closed it because it wasn't profitable enough.
You're probably unaware that the GP specifically used 'HSBC' because they were caught laundering trillions of dollars of drug money and nobody was indicted.
He probably isn't unaware of that. He may well have actually read the indictment itself or a detailed summary of it, which made clear that the US case was very weak to the point of hardly working at all. In particular, not only did they fail to clearly establish that drug money was really moving (their case was "there is so much cash, some of it must be from cartels") but in particular they failed to show intent by HSBC execs to help drug cartels. Actually their case boiled down to HSBC didn't try hard enough, they weren't suspicious enough, etc. (I'm ignoring the Iranian transactions here which gets into issues of international jurisdiction, as you only brought up drugs).
The reason you think the are guilty is twofold. Firstly US anti money laundering laws are unbelievably extreme. The PATRIOT Act removed the need to have intent to be found guilty of money laundering. Bankers can now be found guilty of AML violations even if they genuinely tried hard and had no intent to break the law. Hence the accusations from the DoJ that were of the form "HSBC should have designated Mexico as high risk", etc. Secondly as part of the plea agreement HSBC had to act guilty and accept whatever the DoJ said about them. So you only heard one side of the story, the prosecutions side (except there was no court case). No surprises that you think the whole thing is cut and dried.
It's no crime to be ignorant of such things, but just try not to hold any policy positions on the subject.
Given that there was never any court case and HSBC was never able to defend themselves, pretty much everyone is ignorant in this case because we never heard the full story. But I'm pretty sure if DoJ had emails from HSBC execs that looked like the ones from BitInstant there would indeed have been prosecutions.
Compiler optimizations don't really help if your code is I/O or input-bound, which accounts for most of the code written today - so users rarely see the benefits. Occasionally you get a situation where one particular code path is CPU-bound and is hit often enough that optimizing it matters, but in that case it's usually still easier to use C++ for that particular bit, and some other high-level language for the rest.
Granted, with all the changes already in C++14, and more good stuff coming in C++17, C++ itself gets more high-level every year. Right now I'd say the problem is really more with the tooling than with the language... debugging C# or Java is still a much more comfortable experience than debugging C++. But it doesn't have to be that way.
Promises and async is indeed a good point. I've been writing async (UI) code in C# for the past two years, and have almost forgotten what a mess it was before tasks and await.
BTW, async/await is also proposed for C++, though it is a much more generalized construct there:
VC++ has a preview of the implementation in the current betas:
Yes, you should (and you should also include e.g. SharePoint for
The countries as a whole may be the richest ones, but if you look at how those riches are distributed within those countries... most people in those kind tend to be worse off than the other kind.
But the rich will not recognize that until the mobs with pitchforks are breaking into their gated communities.
It only needs to happen in one place for others to recognize the urgency. Just like the communist revolution in the USSR prompted the rise of the welfare state in the West (and, with the collapse of the USSR, welfare state is also slowly evaporating).
That might not work out so well when it's proles building those robots.
So you can actually shoot them and hit? Sounds like a win-win!
This is subjective. But it certainly goes beyond "remembering whether to capitalize the first character of your methods and variables", at least if we're talking about idiomatic C# vs Java.
Granted, Java is catching up with lambdas and the associated library stuff in Java 8. But it is still hampered by type erasure, and libraries haven't picked up on their use yet, while in C# the patterns that only really make sense with lambdas have been idiomatic in libraries for a few years now.
This was true circa Java 1.4 / C# 1.0. Since then they've got rather different model for generics, lambdas, and a bunch of other stuff. C# has LINQ, dynamic and iterators on top of that. There are enough differences to matter.
Did you count the jobs that only listed C# or VB.NET in the
Perf of JVM vs CLR is a complicated topic. Generally speaking, JVM (HotSpot, specifically) has an edge when it comes to optimizing code, but CLR has an edge in that some of the language semantics generate more efficient code to begin with. User-defined value types (structs) and non-type-erased generics thereof make a big difference there.
HotSpot is better at optimization because it can afford to be slower - it can interpret the bytecode for rare code paths, and only kick in the full-fledged optimizer after it figures out that something is worth optimizing. CLR doesn't have a bytecode interpreter at all, it always JIT-compiles on first call - which means that the compiler has to be fast enough, and that in turn means shedding slow but effective optimizations.
10 years ago
Enterprises usually don't start using a new tech extensively until it has been out for a while.
Did you have the same indignation about the similarly authoritarian and brutal but non-communist regime that was in place in Cuba before Castro?
You know, the one that was not only tolerated, but actively supported by US?