No, you didn't understand. I probably didn't explain well, but if you read the blogs then it's clear. They're talking about Ruby objects being manipulated from C. Memory allocated inside the C program is still manually managed.

The GC becomes a scaleability bottleneck; the parallel processing eventually being throttled by that GC that can only run as a single thread (more or less). So systems that need high performance, large scalability and distributed networking etc are invariably written in C++.

Which collector are you using? Modern collectors like HotSpot G1 are parallel and concurrent, that is, they can collect using multiple threads simultaneously whilst the application is running. Give them more CPU cores and they will collect faster. The way to start tuning them is to specify how much CPU time you are willing to spend on collection and how short your pause times need to be. Allocate more time and the heap will be smaller. Allocate less time and the heap will waste more space (i.e. be larger) but the application will be faster.

As I mentioned in my post, it's not true that systems which need high performance and large scalability are always written in C++. I've heard of multiple cases where large Java applications have GC'd heaps of several hundred gigabyte heaps and need a-few-milliseconds-or-less pause times. These tend to be apps in the financial industry for some reason. As another example I used to work at Google and they have quite a few very large, scalable systems written on the JVM, like the Gmail frontend web server.

The whole concept of threads and data ownership has exactly zero level built in conceptual support, and that sucks. It sounds as though Rust has been designed to resolve these issues for systems programmers. Which is a great idea.

Depends what you mean by resolve. Rust does static checking that data is only owned by one thread at once. If you need shared state then you are back to manual memory management again, as far as I know (Rust is a rapidly moving target so anything I say today might be out of date tomorrow).

Yes, that has been a persistent problem for speeding up dynamic languages for years. You can make a better runtime but then can't provide the interpreter API used by the C extensions.

The Oracle Research JVM team has a totally crazy solution for this. They have implemented an extended version of HotSpot that is capable of actually JIT compiling interpreted source code of Ruby C extensions such that the end result is much faster than the Ruby interpreter using GCC compiled versions of those same extensions.

The whole blog post is worth a read, but to summarise, what they've built is capable of actually inlining C into Ruby and vice-versa at the compilation level. So for example if a C extension function returns an array of three elements using the C extension API and then Ruby code unpacks it, it can actually compile down to returning those values in registers because the code is inlined together and then compiled in the normal way. Additionally, interpreting the C source code means that the JVM garbage collectors can still compact the heap and do other things that traditionally you cannot do with C.

Graal/Truffle are unfortunately still research projects. This technology doesn't ship in the regular JVM yet and won't do so for some time. But it's an interesting glimpse at the future of high performance dynamic language runtimes.

Wow, it sounds like you've certainly done your research, and are very familiar with what Rust is doing and how. I especially like your examples, and convincing arguments that Rust is unnecessarily complex. I mean, who even uses RAII anymore, or wants to have their code statically-verified at compile-time except by marking the unsafe bits as unsafe? Thanks, now I'm completely sold that you know what you're talking about, and that Rust is a badly designed language!

I think he spelled out why he thinks Rust is badly designed. I haven't reached a conclusion on Rust yet ,but I certainly wouldn't be so bold as to say it's well designed, at least not yet. At best you can say it's an open experiment.

First off, I'm not sure why you think RAII can't be done in a garbage collected language. For historical reasons C++ overloads the allocation of memory with the management of scoped resources hence the "resource acquisition is initialisation" name, but there's no reason that these tasks have to be joined together. Virtually all languages I know of have ways to do scoped resource management. Java has try-with-resources, C# has the using keyword, etc. The semantics are identical to RAII.

Secondly, I'm not sure what you mean with the statement about unsafe. Yes Rust requires you to mark unsafe regions of code with the unsafe keyword .... exactly like C#. Java has the sun.misc.Unsafe class that lets you do manual memory management and arbitrary unchecked memory reads/writes, albeit without any native language syntax. This doesn't seem like anything fundamental to Rust.

Now let's revisit silfen's criticism:

Rust makes trivial memory allocation, the kind other languages simply optimize quietly for you, unnecessary complex, while failing to work in complex scenarios.

Rust has a very complex set of rules that you must satisfy to make a program compile. "Fighting the borrow checker" is actually a thing in Rust. In some cases, the obvious way of writing a function that would work in any other language violates the language rules and requires workarounds. So let's not argue about this point specifically - Rust is a complex language and the lifetime management intrudes into even the most basic of programs.

What about failing to work in complex scenarios? This one is arguable. Rust can express the semantics of any program, I do not believe there is any case where you cannot write a program in Rust that could be written in another language. So "failing to work" is perhaps a bit extreme. However it is undeniably true that for quite common design patterns the Rust lifetime/borrow checking infrastructure cannot apply and Rust programmers must either spend time thinking carefully about ownership design or fall back on the equivalent of reference counting smart pointers. My experience of reading online discussions is that Rust programmers tend to see this as a virtue and everyone else isn't quite so sure.

The argument for Rust would be far stronger if it had been designed, say, 15 years ago, when garbage collectors were still very primitive. The problem Rust faces is that the key selling point of its design, the one that is used to justify all this unusual complexity, is "you can avoid garbage collection". But if you're working on a platform with modern garbage collector designs like the JVM or (to a slightly lesser extent) the .NET CLR, many of the old disadvantages of GC have been optimised away with time. On a properly tuned GC pause times are now very short even with large heaps, and some GC's like Azul or the new Red Hat developed Shenandoah GC don't actually have any pause times at all .... even with 200-300 gigabyte heaps. Google's ART runtime has shown that you can implement a concurrent compacting garbage collector on phones and get responsiveness that's basically as good as the iPhone. At least I don't perceive any obvious responsiveness difference on my Lollipop Nexus 5.

There have even been projects that applied garbage collection to places that conventional wisdom say should not work. The Unreal Engine is written in garbage collected C++ yet can still hit a reliable 60 frames per second. Even a very basic mark/sweep GC can easily sweep the core game state heap quickly enough to avoid frame rate stalls. Microsoft implemented an entire research OS kernel using an old version of .NET (Singularity).

This leaves Rust targeting applications where the developers either can't use even very basic GC, or believe that they can't. Undoubtably there are some applications like that. But many programming tasks won't find the Rust complexity/performance tradeoff worth it.

If I were to create a new language, I would not focus on creating the most beautiful syntax or the best built-in functionality. Instead, I would make damn sure it plays well with other languages and that it is trivial to use software packages already written.

Nim looks syntactically a little bit like Kotlin, which compiles to either JVM bytecode or JavaScript. If you compile to the JVM then you can not only use libraries written in Java, but also JavaScript, Python 2.x (via Jython), Ruby, Scala, C (via JNA), there's even a Haskell for the JVM called Frege.

The really neat trick, though, is that despite looking not much like Java at all, it compiles down to code that is binary compatible with Java and there is a Java-to-Kotlin rewriting tool, meaning you can convert existing Java codebases one file at a time whilst still having a fully compilable project. Thus you can not only leverage existing codebases written in many languages, but also slowly convert legacy codebases too.

Kotlin has some syntactic features that look similar to nim, like if being an expression not a statement, ranges, type inference, compile time inlining control, operator overloading, generics etc. Kotlin also has a a variety of features that focus on creating DSLs, but doesn't do it using a full blown macro system.

Nim has some things Kotlin doesn't and vice versa. I can write a more complete comparison (based on reading the docs) if anyone is interested. But the reason I mention it, is Kotlin's focus on interop with existing code.

What I am wondering is WHY all the articles (not just about Google) on how "businesses are ""failing"" " when all these businesses are posting 10-20% growth, yet some analyst says it's "bad" and so stocks get hit on that

Not all analysts are idiots, you know.

GOOG needs to post massive and ever increasing growth to be worth what it is. The reason is, Google pays no dividends. What's more they have never paid dividends and show no signs of paying dividends. Anyone who has studied Larry Page for even a few minutes knows that this guy doesn't want to pay dividends, any more than Steve Jobs did. Page wants to launch rockets to the moon and wire the matrix directly into people's brains. He is happiest when creating new technologies that are crazy expensive. Which is great for him and his employees ...... but less great for investors who need to make ROI for their pension/hedge/whatever fund.

There's another problem that weighs on Google's stock. Their revenue continues to grow very healthily. They make more money than ever before. But they also spend far more money too. Google has almost always been increasing its costs, through datacenter construction and hiring. There appears to be no limit to this spending and Page has never articulated any theory of how big his company needs to be. But it always gets bigger.

Final problem is that though Google spends massively on R&D most of its successful products make no money. They are at best small businesses compared to its main ads business (e.g. enterprise apps), at worst massive money toilets like Google Glass.

So stock analysts see two problems. Spending growth that matches or exceeds revenue growth, and almost total cultural inability to think about dividends. Just like it took Steve Jobs dying for Apple to pay dividends, it's not clear that Google will ever pay dividends until Larry Page/Sergey Brin are no longer at the helm. So if you own GOOG your only real option is to sell it on to someone else, or wait a veeeeery long time.

And that's why Google needs to see even more spectacular growth than it already has to support the share price.

EU has made it clear that avoiding conflict with Russia is worth the sacrifice of nations on the periphery of Europe.

Ukraine is only "in Europe" in some technical geographical sense that would also include Russia. Meanwhile the EU is trying to avoid being dragged by USA/UK into what is quite clearly a civil war, not an invasion by Russia regardless of what the talking heads would like us all the believe. Invasions aren't the sort of thing you can do quietly. Just ask the Iraqis.

Plus other bits of code actually required to make it run.

They also say that they think the same findings would hold for C++. So whilst it's a bit hard to know if this technique is useful without reading and pondering the paper, it isn't saying much about Java specifically.

That said - we all know Java is a very simple and verbose language. That has some advantages like ultra-fast compiles, but lots of disadvantages too. So here I'm gonna point out Kotlin, which is a new JVM language with transparent Java interop (in both directions). It's a lot more concise and expressive than Java, whilst simultaneously having a stricter type system. The neat thing about Kotlin is, it's developed by JetBrains so you get completely seamless integration with their refactoring IDE. Also there is a Java-to-Kotlin converter feature that lets you turn a Java file into a Kotlin file instantly, and you can convert a codebase on a class-by-class basis. So you can start using the features of the new language right away. Also, it runs on Java 6, so it's Android compatible.

Bad analogy. Anonymous Cowards on Slashdot have two attributes that make them unlike hidden services:

1) Slashdot can reveal their IP address at will

2) What they do can be either modded down by the community (if they're just posting garbage) or simply deleted if they're posting stuff that is outright illegal or deeply unethical (SSN dumps or whatever)

So Slashdot provides a limited form of anonymity with controls on it to prevent excessive abuse, and this is a good thing - although there's a lot of crap posting by AC's that gets modded down, I've been reading /. for 15 years now and many of the best comments have been anonymous. It's a clear net win.

Hidden services on the other hand are NOT a clear net win for the Tor community. There are zero controls on them, even though Tor is not alien technology or a force of nature ... it's a network run by a small group of people who can and do enforce rules on it, rules like "exit nodes may not engage in SSL stripping". Although Tor and the EFF like to claim there are tons of great social uses for hidden services, clear examples with real world impact are sorely lacking.

So I don't think you're arguing what you think you're arguing. Not all forms of anonymity are equal.

Ulbricht set up a sister site called The Armory at some point which did sell a range of weapons including very dangerous ones like RPG launchers. Silk Road also sold forged IDs and malware (e.g. that could be used to empty bank accounts). His definition of "victimless crime" was a very poorly thought out and inconsistent one.

Why is everything a slippery slope for you people? Is it not possible that we find a middle way?

Experience, and no, probably not.

Look. Let's be extremely generous and assume for a moment that the Great Firewall of France is never extended to, say, "extreme speech" or anything beyond terrorism and child porn. Judging from similar firewalls elsewhere (like in the UK) the chances of this being the case is nil, but let's pretend for a moment France is unique and doesn't slide down the slippery slope.

This still leads two gaping problems. One is that whilst the definitions of child porn and terrorist material might seem straightforward, they are not. The UN has struggled for years to come up with a tight definition of what terrorism actually is, but has never been able to succeed, partly because any obvious and straightforward definition tends to make western governments outright supporters of terrorism or terrorists themselves. So blocking terrorist material quickly becomes "we know it when we see it" which basically just means whoever is in charge gets to block whatever websites they like, under whatever flimsy justification they can think of. Anything that can be read as being against the state becomes terrorism, in such schemes. As there are no jail sentences for French officials who abuse the system, and no real way to even define what abuse is, political censorship will happen.

Even child porn is harder to nail down than you would think. One problem is figuring out if the person in the picture is actually a child. For the worst stuff it is of course obvious, but the problems start when e.g. the caption claims the girl is a young looking 18 and the censor decides maybe she's actually 15, but doesn't really know for sure, but hey it's better to be safe than sorry right? And who cares about some guy getting his rocks off to pictures of teenage girls anyway. In the memory hole it goes!

In the UK the age of consent is actually lower than the age at which you are considered to be a child for child porn laws, meaning if a naked teenage couple take a selfie in bed after 100% legal sex, the result can be considered child porn and trigger the full weight of the law. Common sense not applicable!

America has created an even more messed up situation. There they classify cartoons as child porn.

All this of course is based on the assumption that the right approach to dealing with child abuse is to try and block child porn at the ISP level. But paedophilia appears to be some kind of sexual urge or addiction, something fundamentally rooted in brain chemistry or psychology. People who really, really want to look at films of naked children will just use a VPN to America or some other country where there's no censorship in place. It's sort of like trying to ban the sale of cigarettes locally but not ban the import of them. Not gonna work. Medical attention might, though.

If the law worked more like a high quality computer program, with batteries of unit tests and every edge case considered and planned for, AND if politicians and officials were far more disciplined then they actually are, we might be able to say "hmm this sounds OK and isn't going to cause any problems". But France has already proven willing to jail a comedian for making a vague statement that could, theoretically, be read as sympathising with the Charlie Hebdo killers whilst simultaneously telling the world they're gonna defend free speech to the death. So if any country can avoid the slippery slope it's not going to be France.

They did this during the Vietnam War (search for videos on YouTube - or 4chan if you have to see them - I prefer not to look - I already know how bad my fellow man can get). Depending on the war, yes we would still call them "boys" and receive them as heroes. See what Jordan's response has been to this video. The "Rules of War" and Geneva Convention was put into place to keep this sort of thing from happening, and if you choose to ignore them, then the term "Non-Combatants" goes out the window. Sadly, what's going to happen is a lot of people are going to die.

That's a US specific issue again. No bank I've ever used lets you reset account access via email.

RSA tokens are inadequate.

Both my banks (UK and Swiss) provide CAP devices that require you to insert a card, enter a PIN, then enter a challenge code from the screen and copy the response back.

The key is .... when transferring money to a new account you haven't sent to before, you have to enter a part of the destination account number as the challenge. The idea is a virus can't swap the instructions you see (well, it can swap the account number perhaps but this is verifiable out of band). When using SMS, unless the message includes the transaction details, you don't know what you're authorising.