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.
60 karma · joined November 14, 2015
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.
Therefore the article as a whole cannot be taken seriously, and reflecting that I stopped reading it immediately after.
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.
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.
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.
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
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.
But the above doesn't hold for everyone, and thus I don't in general agree with your assessment.
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?
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.
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.
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.