"Because we've all worked at companies where substandard code is routine due to a culture of passive-aggressive nonsense."

BS, 100% BS. Show your proof.

Prove it. Show an ounce of scientific study to prove that claim. Otherwise your statement has no more validity than a horoscope prediction.

"There's a balance. Too much of either flame or light-treading can lead to problems."

Claims made without evidence can be dismissed without evidence.

Show me any peer reviewed, scientific study to back that claim.

I swear, some of the most hysterical people who believe in hokum and myths are computer science engineers who pull out this crap that negativity produces productivity.

Agile software development is a team effort with a constant feedback loop. Waterfall is top-down authority and no feedback loop. The agile process is ever changing in scope and delivery depending on the situation on the ground. Waterfall software development is a fantasy that management gets to pretend is real and berate their employees when that fantasy fails. I believe it is the fantasy and power allure of waterfall development that is the crux of the matter as to why after all these years agile has such low adoption rates and not anything related to Agile. Corporations today are the equivalent of monarchies before democracy where the people at the top make the decisions, it is all about ego. Top down authority has run its course as to capability to deliver. Agile is an attempt to compensate but until the power management structure changes Agile will always be at the mercy of authoritarian, unilateral decisions of ego. Feedback is critical for success and top-down management has no feedback. This is one of the fundamental inefficiencies in any bureaucracy and why, still, to this day 9/10 software projects fail. I don't like to fail.

When Bill Joy created Berkeley Unix back in 1984 he did so by rewriting 100% of the implementation and only kept the interfaces/APIs. AT&T sued...and lost copyright and license infringements. If that hadn't happened we would not have Linux. This should be settled law.

And then there is this:
"Single ownership eliminates pointer aliasing, making it
impossible to implement data structures like doubly-linked
lists in pure Rust. The language offers two mechanisms to
remedy this limitation. First, Rust embeds an unsafe subset
that is not subject to the single ownership restriction and
is used to, e.g., implement parts of Rustâ(TM)s standard library,
including linked lists. Techniques described in this paper
rely on properties of the Rust type system that only hold
for the safe subset of the language. In the rest of the paper
we assume that unsafe code is confined to trusted libraries."

Trusted libraries! woo hoo! /facepalm

Thanks!

"Our SFI implementation (Section 3)
introduces the overhead of 90 cycles per protected method
call and has zero runtime overhead during normal execution."

90 clock cycles is still 90 clock cycles more than C.

Perl has GOTO and LABELS. I used PERL mostly for ETL and having the capability to break out nested for loops using LABELS made the code cleaner not having to use a bunch of condition variables. Now that I'm in Python I have to filter things which means iterating over things once for the filter in the for list and then again for the processing. Things can be corrected by using 'yield' to iterate once with generators but, and here's the but, the Perl LABEL code is intuitive, whereas the 'yield' code trips people up, is confusing and is under utilized. Therefore developers in Python not using 'yield' are less efficient. Python should use LABELS as a best practice in my opinion.

I'm sorry but I don't see the security problem, at all. All I see is a bunch of hyperbole.

First thing one learns in security is that as long as humans are involved then you have a problem. RUST only addresses one aspect of human involvement, operator error. RUST does not address backdoors of design. The recent IOT attack the created the largest DDOS attack was such a back door.

If the past is any indication of the future then RUST will find its niche and that's it. Safe malloc libraries have been around a long time. But, and here's the but, protection comes at a cost. Kernel developers care about that cost. RUST is being put out there as a free lunch, security without cost. We know that is not true. Instructions need to be run to secure things. Kernel calls that are called orders of magnitude far more than user space calls require bare metal performance.

It would be interesting to see the statistics on the security attacks over the years so as to compile a percentage of types of breaches. Password hacks are far more common the buffer overflow attacks. So, the question is how much so? The Sony attack was a password attack. If an analysis is done whereby the security breaches due to human error of C coding are minuscule relative to the total then RUST needs to be accounted for: the cost of replacing C with the risk of C breaches. I'm guessing that calculation has already been made.

Finally, my advisor at UC Berkeley sat on the Board of VISA in the 1990s. In one class he invited students to breach VISA's network protocol. And guess what, someone did. The student's analysis was that security protocol wasn't of the highest order and known breaches existed on the Internet. This was the lesson for the day. The cost of loss for VISA due to security breaches was lower than the performance cost using better security.

The RUST advocates need to make a better business case than just "RUST is better security". What the RUST advocates such as the one are doing is spreading FUD. The sky is falling! The sky is falling! But if you ask security experts what their top security priorities are, human error due to the C programming language is not in the top of the list.

Hi! Chat is a large enough space with a diverse enough set of requirements that one size does not fit all.

Discord works great for games.

Zoom focuses on business conferences.

Skype has cheap long distant rates for internet to non-Internet phones.

WhatApp is great for international users.

There is another international chat app I used which had great call back, call forwarding, and automatic response features because of being in different time zones.

People who live on Facebook use that chat.

I use Google hangouts for a couple of people who use gmail a lot. You'll be emailing back and forth and then just move to hangouts.

I use at least 5 different chat apps depending on the context and this is just fine. Google hangouts to me is the stripped down chat when it comes to features and limited when it comes to audience. The client on Linux only has about 20 characters with and is not very "long text" friendly. You can't really dump code or other long text into it and have it be cut/copy/paste friendly.

This is inevitable with the current trend of having the web browser be a thick client.

The trend is to put as much code as possible, i.e. thick client, in Javascript. Now, suppose one wants to leverage that code as middleware? Taa daa! Headless mode. We've been down this road before with client/server, thick/thin clients.

What makes Javascript particularly impossible to reproduce is the fast moving, every changing set of libraries. This will put pressure on the business logic sitting in all the Javascript to become middleware so as to capitalize on ones investment. As they say, what's old is new again.

I predict within the next 2 years headless browsers as middleware will be common place.

1. 2 disks, one OS disk of 500GB, one backup drive of 1TB
2. 20% physical reserve using LVM on on OS disk.
3. Nightly snapshot backups, hot backups, to 1TB drive.
4. Weekly external 3TB drive backup.
5. Fully encrypted drives using I7 processor with built in encryption in the CPU for speed.
6. Multiple VM images are backed up.

I've had harddrive failure multiple times and I just restore from the external hard drive. I keep weekly/monthly on the 1TB so as to recover human error deletion on the OS disk. The real deal is I know it works because I've done the restore multiple times, including buying a new laptop.

The I7 Intel chip with onboard Linux encryption instructions makes the encryption fast enough to run multiple VMs with only a little lag, mostly starting a VM.

Cheers!

AMD and Nvidia Silicon Are Manufacturing Secrets Allegedly Stolen, Sold To China

---OR---

AMD and Nvidia Silicon Manufacturing Secrets Are Allegedly Stolen, Sold To China

Don't let Javascript and Hacker News fool you. Hacker News is predominantly a hang out for the functional programming crowd. This is a self selective audience. If you are not interested in functional programming then there is not a lot of content on Hacker News for developers.

Javascript is a bloody mess, especially with the Nodejs. A bloody mess is not functional programming. For/while loops are for more prevalent in Javascript then functional programming. At issue is all the callbacks for async event handling. Javascript is very poorly designed software because unless your async code is wrapped in monitors it is not proper async code. Promises? Pick up any programming text book on async programming and it will always teach you to wrap your async code in monitors/semaphores/locks.

CS61A, or Introduction to Programming, is a flunk out/weed out class at UC Berkeley. It is taught in LISP and is functional programming. Why? Functional programming runs counter to the way the majority of people think. Science says that functional programming is demotivating for the general population. So, what do you do if you have way more students interested in Computer Science than you have slots available? Easy, just make them pass a functional programming course.

CS61A is the only mandatory functional programming course at Berkeley. All other courses are in Java, C/C++, Python etc.

The only question one needs to ask about a computer language is this: can the language exercise the full functionality of the target computer? If the answer is yes then all such languages are interchangeable and logically equivalent.

Since scientifically speaking most people think in for/while loops and not function calls then procedural programming is the most common.

What have we learned?

1. A. If a language can exercise the full capability of the target computer than it is synonymous with any other such language in capability.
2. B. Science has shown people are far more motivated by procedural programming than functional. For and while loops are more natural to how the mind works. Most people find functional programming an unnatural way to think and therefore do not like it.