> I have been writing software for over 30 years, and dammit I have yet to forget to free after I malloc in released code!

You don't know that. Or can you offer me a machine-checked proof?

> Everyone loves to think that there will be plenty of memory, you can never run out!

Not everyone. In particular, not the designers or users of Rust. Are you sure you've been paying attention?

> C is the smallest, most efficient, most elegant language ever built

It isn't the smallest and it's only your opinion that it's the most elegant. It certainly isn't the most efficient in all cases. Languages where the compiler can prove no pointer aliasing often kill it in performance.

> Why oh WHY do you think then entire Linux kernel is ONLY written in C!

In 1991, there was no reasonable alternative to C. The Rust project would not be started for another 15 years. In 2019, C has a massive ecosystem and culture, the Linux kernel includes over 15M lines of C code and there are C compilers available on platforms where Rust is not available. If a student was to start a similar project in 2030, can you be sure it would be in C?

> If you are too lazy, stupid and ugly to even check if the memory you have allocated is freed, the arrays you create are checked, if you cant be bothered to look at your code, and stop being so fucking clever, so fucking slick, then just go do something, hell anything else, but stop pretending you can write smart tight efficient code.

Why? It's perfectly feasible. And some software needs security _guarantees_, not your opinion, no matter how attentive, clever and pretty you are.

Rust is something new. It's from the future. It's isn't like things you know.

You made clear that you don't want to learn this new thing. You give me the impression you don't want to learn new things at all.

> Where are the braces?

Do you really not use languages without curly braces? You know they exist though, right?

When I see a magic technology from the future, I'm fascinated by it and seek to understand it.

It's true that most applications should use garbage collectors. But Rust is for those situations that cannot use a garbage collector.

You're also right about the garbage collectors of the '80s. But you implied that there haven't been significant advances in garbage collectors since. There have indeed been significant advances since. Take Go's latency-optimised system for example.

Rust offers something unique: memory safety in situations where a garbage collector and runtime system are not feasible and correctness and performance are critical. C and C++ are commonly used in these situations but they do not offer safety guarantees.

> The other thing Rust fanbois don't seem to understand is that MOST programming languages are memory safe.

They absolutely understand that. Rust is for when you can't afford a runtime system and garbage collector, and the alternatives are C and C++. For example, a browser or OS kernel. They don't mention Java, Javascript, Python, Go and friends because *it's obvious* that if you can use them, you should.

What layers of defence do you believe Rust duplicates?

I'd mod you up if I had the points to do so. My team develops locally on Macs or Ubuntu, then pushes to CI in the cloud, which builds deployable artefacts and deploys to cloud environments. All our cloud environments are interchangeable and if they were all ARM, I'd lose very little, since I already can't run them locally. (Well, actually, I could with some scripts around Docker and/or Kubernetes, but nobody on my team has ever had occasion to.)

Just use a kanban board on the wall to practice agile without jira. Works great if everyone is in the same room. You absolutely need source control though. You don't need branching necessarily.

Your advice to do what works for your team is great. But your advice not to read books... not so much. Reading books is one of the best ways to learn and grow. The underlying theory that explains _why_ things work for your team is not at all obvious and deserves concentrated study.

Care to share your experiences of them? I sense anger in you but there is hope.

I don't think you properly read the post to which you are replying. Their first sentence wasn't meant to be read literally, as their second sentence makes clear. They were simply pointing out that it's easy to make blanket assertions that aren't really true. The particular assertion-that's-not-really-true is the following:

> More cores are worthless for most tasks.

This statement would be _definitely_ true if you'd said, "more cores are worthless for _many_ tasks". Now it's far too easy to assume that everyone on the Internet is a total idiot. But the truth is that many people aren't (well we all are, some of the time). It's really best to give people the benefit of the doubt.

In particular, if someone claims that a million core is a lot of performance, it doesn't necessarily mean they don't know what can and cannot be done with those cores. Especially if they describe spinning up lots of cores on AWS as a stunt.

Google, Amazon. Netflix and the people who build and use super-computing clusters all use lots of cores. And they know what they're doing.

In another post, you also said this:

> compared to on-chip or at least on-board multiprocessing, the network is really, really slow

This is, of course, true. But it's not the whole story. The "network" and "on-board" aren't quite as distinct concepts as they once were. Especially in a datacentre or super-computing cluster. In practice, network latencies are often surprisingly small. (And, conversely, the latency within a CPU or board is often surprisingly high - they're full of networks these days) The plain fact is that super-computing clusters (and the datacentres they resemble) get more work done than if they had a single CPU.

We'd all like faster cores. But the people scaling horizontally are not idiots.

> analized

I think this was a typo.

I agree with you that browsers can already run arbitrary code. And that wasm will be built into the browser. And that any bug would be a problem.

But wasm isn't just a standardisation of asm.js. It's more that asm.js is highly influential prior art. In 2015, Brendan Eich did say that wasm would be 'initially co-expressive with asm.js' but that's only approximately true of what actually shipped. See the start of the wasm FAQ: https://github.com/WebAssembly...

What you say is true.

But to be fair to wasm:

* 'View source' will display the text version of wasm.
* JavaScript is often minified or obfuscated too.
* Wasm supports sourcemaps, arguably better than JavaScript does.
* Most people get their sourcecode from github rather than 'view source' these days.

Much of what you say is morally true. But it's not technically true.

It's true that wasm is a binary serialisation of an abstract syntax tree (AST) but that AST is defined _without reference to JavaScript_, see https://github.com/WebAssembly... . In contrast, the asm.js spec is genuinely a subset of JavaScript.

You're right that wasm doesn't introduce new capabilities to the browser as such. In the current 'MVP' version of wasm, the only way to invoke web assembly is via JavaScript, and the only way for wasm code to interact with the browser is via JavaScript.

But it does make certain scenarios, such as running large compiled C programs, much more practical. It is, by design, a far more efficient compilation target than JavaScript or asm.js, see https://github.com/WebAssembly... . For example, we can expect Unity running on wasm to become commonplace, see http://webassembly.org/demo/ .

You can't be sure of that. The wasm codepaths will reuse much of the existing JavaScript execution engine but there will be new code and that new code could - and probably will - have security vulnerabilities. But probably no more than any other major browser feature.

I'm not so sure the parent poster means that we need to eat sugar, merely that it's the main energy source in our blood. The second paragraph of the paper you quoted implies as much:

> Blood glucose concentrations around 30 mg/100 ml were recorded consistently during the last 8 months, although the patient was ambulant and attending as an out-patient.

If I understand the paper correctly, that patient ate no sugar (or indeed, anything else) and yet they maintained sugar in their blood. Clearly, their body had manufactured it from other things.

It's possible that you're actually in some agreement than the parent poster. You both think it's a bad idea to eat lots of refined sugar, don't you? I speculate that they think it's fine to eat apples - certainly I do. What about you?