jjpe

Generally I don't do this (go ahead, have yourself a google). But the error was so blatant that I just couldn't not say anything about it. In a sense the article baited me into it.

Well in all fairness, I might've kept reading had it not been for that blatant factual error.

I'm not doing that at all. I'm merely saying it isn't worth the time.

Ignorance and having time are 2 orthogonal things. Your argument is not even close to valid. And I haven't even mentioned the ad hominem, which is an automatic disqualifier for any argument.

Like someone said above, who has time to wade through all the verbal feces before deciding that an article is worth the time?

In this day and age, you need to decide quickly, or you'll be wasting a lot of your time.

Now I don't know about you, but my time is valuable.

Or the author should/could improve their writing style. Just a thought. One concrete improvement would be not to moan about things that aren't even true (anymore).

Pretty much every touted feature is WIP, definitely all the important ones. So yeah no that's vaporware.

The problem with this article is that the first example is wrong, as in it compiles fine. I could even tell without running it that it would compile.

Therefore the article as a whole cannot be taken seriously, and reflecting that I stopped reading it immediately after.

> I personally am not a fan of too many abstractions.

Then you're likely in the wrong business, since most of what programming is is dealing with the various facets of one abstraction or another.

> The cost of this borrow checker is huge: every reference in every program needs to be annotation with whether it's shared or mutable

No. You need to "annotate" a mutable binding since bindings are immutable by default. But that also means that immutable bindings (ie the vast majority) does not to be "annotated". And even when you do need to, you literally just add the keyword `mut` as in `let mut foo = 42;`.

> and you often need to splatter confusing lifetime annotations all over the place. It adds a big learning curve to the language.

Again an extreme exaggeration. There are a few cases here and there where you need lifetime annotations, but most often the compiler simply infers them for you, allowing you to elide them completely. Specifically, you only need to do it yourself when it's ambiguous from which input(s) the output is derived.

You could just serve a webpage that queries your desktop, and visit that with the browser on your phone. Slightly more work, but definitely viable. You can even make a shortcut on the home screen of your phone that automatically navigates to your custom search page.

These rap songs are both funny and ring true. Please make more, and a video would be cool too :)

They're failing, and hilariously so. The Gmail GUI is awful, it's slow (especially on non-chrome browsers), you're still being tracked (nothing new but still worth mentioning) and manipulated. And worse, the slowness thing was done for (allegedly) anti-competitive reasons.

Then there's android and chrome: the new material design style is something you need to be a little brainwashed to really like, as a lot of space is simply wasted on eye-searing white backgrounds.

And finally, let's talk about search, Google’s raison d'etre. It's consistently dropped in quality. For example, a number of years ago I'd never even think about going to page 2 or even 3, or even going to another search engine. But now it's par for the course, since page 1 is just chock full of garbage e.g. advertisements (nothing new, but still) and links that don't even come close to providing the answer to my question.

Quite frankly, properly justifying staying with Google is starting to get seriously difficult.

This is not as much as a problem as you believe. Rust is perfectly capable of making objects that have a C API and ABI precisely for this reason, and the most popular distros only work with supported compile targets anyway. That said, a distro like Debian might indeed encounter some issues at this time for the less prominent platforms eg MIPS or PowerPC based chips. That shouldn't prevent Debian from including Rust altogether though, they merely should exclude it on those less or even unsupported platforms.

This.

Basically the net effects are a mix of: 1. Push more computation to compile time rather than runtime 2. Verify a lot more state at compile time, preventing dangerous or nonsensical state from occurring altogether 3. Because of 2,you get hard guarantees about the runtime state e.g there is no chance of encountering undefined behavior in safe Rust 4. Building, testing, and deploying are all quite straightforward in almost every Rust project. If you can get away with simple statistics, benchmarking is very simple too. The ones that don't typically have native non-Rust dependencies

It seems you are missing the point of Rusts safety. Yes that safety does prevent things like segfaults, but the real value is in security. As software becomes evermore critical to our lives in pretty much every aspect, having a system that can be derailed by malicious actors is not just unfortunate in the way that a segfault is, no. It is reckless. At this moment what we see is news about company X or Y being hacked,including some infrastructure like electrical grids. Fast forward a half decade and we will have people being hacked and killed from a distance. All made possible because of bugs.

While your use cases are definitely valid for you, this is not a Rust issue, but something that's 100% decided by your distro. They decide if, when and how they integrate Rust into it.

As for the multiple copies issue with Cargo: I generally agree with you that this definitely feels like 1 source of major blow up in project compile times, and it would be nice and useful if that were reduced as much as possible. But there is a reason that this system is in place: each crate defines how it compiles and consumes its dependency crates, so if crates A and B both depend on crate C, then A might compile and consume C differently than B does. This results in effectively different libraries once compiled, and ATM there is no way to predict in advance what the effect of any given compile flag will be since any flag can switch on/off arbitrary code. Hence Cargo keeps A's C dependency separate from B's.

Then there's the not doubting whether an application uses the latest patches. Up to a point, this can be automated through exploitation of SemVer: if Cargo could figure out that a new library version is API and ABI compatible with the previous version then I'd argue that Cargo should perhaps just auto-update it. A bigger issue is what happens when a new major version of the library is released, as those tend to break APIs in order to perform maintenance. That is something that as of yet has not been automated.

That's not really all that relevant for most existing commercial code since legacy code tends to not get rewritten at all unless it's absolutely necessary, and thus remains stuck with the Old Ways.

Spoken like someone with plenty of money in the bank, which is of course a luxurious position to find yourself in. And in those circumstances I agree with you.

But the above doesn't hold for everyone, and thus I don't in general agree with your assessment.

I have always defined spam as "unwanted and undesirable incoming communication, typically for financial reasons". So that includes mass emailing, but is far from restricted to it.

However, that is a definition I basically invented based on experience (i.e. How I imagine most people learn most of their vocabulary).

If it really has to be done in bulk to be spam-callable, what is the individual version of spam? Harassment?

Ah so that's what was going on. The issue insofar I could perceive it is fixed now though. All googly sites are up again.

Where in the Netherlands would be a good idea to check out?

Power imbalances often arise solely because the people involved perceive it as such (i.e. it's a purely psychological effect). Therefore, simply perceiving the situation differently and then acting on that can make a lot of difference.

Actually, I'd say that these days that crown has been taken from PHP by Node.JS. It may not be as popular but it is definitely easier to work with than PHP, if only becausee it's 1. JavaScript and 2. Doesn't have most (all?) of the warts of PHP.

Of course it introduces a few of its own but on the whole I'd say Node is definitely easier to work with for a newcomer.

This is pretty cool. I might actually use this (assuming it can solve any "solvable" linear system). I'd also use a version of this for differential equations, if you happened to write one :)

"Ok, but isn't the question of whether or not something is done at compile or runtime always an implementation detail?"

No it isn't. It changes the entire semantics of your language. For example Python as it exists today simply can have neither type checking nor GC decisions* done at compile time. The language is not capable of expressing those things adequately. Adding those would require some significant changes to Python the language, its stdlibs, as well as the Python VM.

Conversely, starting to use reference counting in Rust is definitely possible but will jack up your memory-related bug count, a rather undesirable result. The code is also pretty much always more difficult to read, understand and debug. Its only redeeming feature is that some datastructures simply need the flexibility it brings.

* I define a GC decision as deciding what to de/allocate and when to do it, rather than performing the de/allocations themselves. For example, the GC algorithms in Java and Go fall under this definition, as does Swift's ARC mechanism, as well as Rust's ownership based decisions. The former 3 decide at Runtime. Rust usually decides at compile time, the only exceptions I can currently think of being code based on the Rc/Arc/RefCell types, which do reference counting and therefore the de/allocation decisions are deferred until runtime.

As rvense explains below, there are a number of very desirable consequences to rusts strong static guarantees, and even performance improvements, all while getting less buggy code. It's even more secure in the sense of being less exploitable: the bugs being prevented by the type checkers are largely about resource allocation e.g. memory but also file handles. And those are often easily exploitable when not properly managed. That kind of compile-time bug prevention is something runtime garbage collection (that is, every VM platform out there) has yet to achieve and so is pretty amazing if you ask me.

Another consequence is the sheer range of applications for which this language can be practically used: systems and concurrent programming obviously, but also Web, realtime, embedded and even supercomputer programming. The reason for that is that rust mostly feels like a light weight scripting language like python, but because of its performance characteristics can viably be used as a drop-in replacement for C.

Rust: it provides extremely strong guarantees about your code at compile time so that usually it feels like a script language with C/C++-levels of performance. And the best part: no data races, and no runtime garbage collector overhead.