You can't really buy good TVs nowadays without those "smart" features, but that SoC hardware is pretty cheap nowadays, so I don't think it's affecting the price too much. Just buy a TV based on it's picture, price, and general physical qualities. Fortunately, you can still treat your TV like a simple monitor and leave all the media wrangling to a dedicated box, whether it's a console, Roku, Amazon Fire, or some roll-your-own PC-based solution.

It appears to be a six month ban, not permanent. Also, although it's hard to be certain, part of the motivation may have been to combat farming of honor points in PvP, which apparently has been rampant. There are cheat programs designed to help players do just that in PvP, so it could be that Blizzard found a reliable way to detect those programs running, and laid down the ban-hammer on everyone caught using it.

I use noscript instead of an ad-blocker. I don't mind seeing ads to some extent. I even choose not to disable slashdot advertising. But there is ZERO reason to allow a third-party advertising ad to run executable code on my machine. Screw that. If they want to show an unobtrusive image-based ad off to the side, that's fine. It's when they start getting obnoxious that they get the ban-hammer.

I'm also getting mildly irritated at Amazon showing external advertisements on their pages. So my shopping dollars aren't good enough for you? You have to squeeze a few more bucks off of my eyeballs, and trick me into accidentally clicking on those ads because they look like Amazon-sold products?

Advertisers, take note. If people are blocking your ads, it's because you're being way too obnoxious about shoving them in people's faces. Also, remember this: once an ad-blocker is installed, it's probably unlikely to get removed. It's in your best interest not to push people too far.

I may have to try out the ergonomic version. I currently use a Microsoft Natural Ergonomic 4000 keyboard. I love the shape of it, and I don't mind the key action, but I wonder if it's more because I really haven't tried something else. Still, $200 is a lot of money to drop on a product you're not sure you'll actually prefer using.

Is there anyone out there who's actually tried mechanical vs membrane keyboards and actually prefer the latter (excluding the noise factor, as it sounds like that problem has been largely solved)?

Since this is compiled code, the predictions I've heard of "it will perform about as well as C++ if you're using it with the same level of protection as Rust gives" makes sense to me. The implication is that yes, it's going to be a bit slower in the general use case, but if you're writing highly threaded or parallel C/C++ code, then you'd have to manually implement that level of protection anyhow in those languages.

We'll have to see if that actually pans out in practice or not. I remain slightly skeptical of promised performance gains, because we've heard for years about how interpreted languages could match native code with enough work on JIT optimization, but it never really materialized (despite getting much closer).

I'm in an industry that's dominated by C++, so I certainly don't expect to be using Rust in practice anytime soon, but I'll definitely be keeping an eye on it.

I meant to type "runtime interpreter". No need to be so snarky.

We should probably make a distinction between cyber "attacks" and cyber "thefts". This appears to be of the latter variety, although of course no details were given. Ransom-ware or Stuxnet would better be classified as an "attack". No doubt the government would like any military or political intelligence they can get, and I'm sure they're working to that end already.

One problem (among many) with equivalent retaliation is that we have a lot more worth stealing then they do. There's less of an incentive in launching cyber thefts against a country that we already have a significant advantage of in terms of intellectual property, at least if the goal isn't simply to disrupt internal systems... and I don't think we want to go there.

Believe the church in matters of faith. Trust the scientists in matters of science.

So, is that like a Python or D commitment to stability, or a C/C++ level commitment to stability? Exactly how committed are they to preserving to preserving backwards compatibility through hell and high water? Because that's why people trust C/C++ - they know that the language committees are not going to suddenly "fix" the language by making billions of lines of code obsolete, simply because it was written fifteen years ago before a bunch of new shiny features have been added.

I think widespread adoption is going to remain limited until it becomes clear how Mozilla plans to shepherd and develop this language as well. Will it become standardized? Will mature cross-platform tools become available? What will the performance penalties be to optimized C or C++ code?

I wish Rust all the best. It's going to be difficult to unseat C/C++ simply due to inertia, as well as convincing programmers of the merits of an entirely new language, but I like the idea of a memory-safe language that doesn't require a runtime or use managed memory.

A lot of people besides you also call C++'s backward compatibility "baggage", but it's unwavering backwards compatibility both with itself and with C (mostly) are one of the cornerstones of it's success and longevity, at least in my opinion. Maintaining strict compatibility, even though sometimes ugly, is one of the smartest thing the C++ committee has done.

When a language breaks compatibility, it tends to split the developer community (e.g. Python 2 vs Python 3), since people or organizations then have to decide whether a costly upgrade or rewrite is worthwhile. With C++, we can rest assured that even older C and C++ projects will continue to compile with modern compilers just fine, and we can move ahead with improved, modernized code at our leisure. This assurance of backwards compatibility gives confidence when in investing many millions of dollars in a code project.

Sure, backward compatibility definitely comes with downsides, such as the difficulty in creating effective tooling for C++ source code or slow compile/link speeds, but I have to laugh when people suggest breaking compatibility or switching languages as a serious alternative. When you're working with projects that have hundreds of thousands or even millions of lines of code, you don't just rewrite that stuff at the drop of a hat.

How to avoid the tech support script runaround? The code word is "Shibboleet."

C++ isn't about productivity. It's really about performance. If your application isn't performance-critical, you probably don't have a good reason to be using C++. And actually, nowadays it's a lot easier to write much safer C++ than previously, especially with recent changes to the language. Overall, the language is a pretty good tradeoff between performance, productivity, and safety, with emphasis on the performance, of course. I'd imagine that's why game developers use C++ almost exclusively, at least for larger AAA games.

On the other hand, game development tools are often written in languages such as C# (plus a mix of various other languages), because productivity is typically more important than performance for those types of applications (after all, you can just buy faster machines for your developers).

So... why not write games / game engines in Rust, D, or some other arguably "better" language?

Simple answer: inertia. Because there's an entire industry's worth of game developers who know C++ extensively (like myself). Our libraries and game engines are all in C++, and are battle-hardened and well-optimized. Who wants to rewrite all of that? Sample code is in C++. Libraries are C or C++. Etc, etc. C++ is often derided for it's flaws, but it's a language that actually gets *used*, and like it or not, being reasonably popular as a language is also a merit. It means that every major platform for which you might want to port a game has a modern C++ compiler and C libraries to link against, and mature debugging development and debugging tools.

It's kind of a crappy chicken-and-egg problem for new languages to go up against, but that's the reality.

Really? Everything I dug up during research said you pretty much had to interop with Objective-C, since Swift classes are exported as Objective-C classes. I'm not doubting you, as I'm sure there's some horribly ugly way to do it, given that we're talking about C here.

Still, for my purposes, it doesn't really matter that much. I'd still prefer a "clean" interop, since I'll be doing a lot of that.

Speaking of C++... I'm currently learning Objective-C rather than Swift. Why? Because all I want is a thin interop layer between my cross-platform C++ code (the bulk of my game engine and game code) and the operating system APIs. Objective-C can iterop with C or C++ fairly easily, while Swift can only interop with Objective-C.

Frankly, I wish I could use Swift instead of Objective-C, whose syntax takes some real getting used to.

When I mentioned "entertainment platform", I was just talking about videogames or other forms of entertainment you'd find on a standalone PC, not a PC acting as a media center. I probably should have been more specific.

Honestly, I've never considered PCs a good fit in the living room. As far as I can tell, people who set up their own media or entertainment PCs connected to a TV have always been in the "enthusiast" camp, and probably are a fairly small minority. It's far easier nowadays to just subscribe to Netflix and stream to your TV or console or set top box than to set up a PC as a media device.

So, I totally agree with you there. The living room will likely remain the domain of purpose-built hardware for the foreseeable future.