- Very, very few people outside of foundational system software, HFT shops, and game studios understand why it's a great selling point. Everyone else likes the other points and don't realize the actual selling point of the language.
- There is nothing new under the Sun. However, some languages manifest as good rewrites of older languages. Rust is that for C++. Zig is that for C.
Rust is the small, beautiful language hiding inside of Modern C++. Ownership isn't new. It's the core tenet of RAII. Rust just pulls it out of the backwards-compatible kitchen sink and builds it into the type system. Rust is worth learning just so that you can fully experience that lens of software development.
Zig is Modern C development encapsulated in a new language. Most importantly, it dodges Rust and C++'s biggest mistake, not passing allocators into containers and functions. All realtime development has to rewrite their entire standard libraries, like with the EASTL.
On top of the great standard library design, you get comptime, native build scripts, (err)defer, error sets, builtin simd, and tons of other small but important ideas. It's just a really good language that knows exactly what it is and who its audience is.
- Cameras and other means of tracking cannot remove me from commerce. The problem isn't just the tracking. Cash requires no oversight to transact. If I am required to use a payment network, there are many third parties who get a say in what I can do. That's the biggest issue.
On the plus side, once cash is de facto outlawed, the US Supreme Court will be forced to finally step in on the subject. The removal of cash will force banks to authorize bank cards and accounts, no matter who. A bit later after that, they will be forced to give access everyone access to payment terminals and gateways.
- I completely agree with you, but you cannot stop this train. Cash will continue to exist only as a loophole to be exercised by rich and connected individuals. Everyone else will be robbed by police for having "suspicious amounts of cash."
- The most important pattern to learn in C is to allocate a giant arena upfront and reuse it over and over in a loop. Ideally, there is only one allocation and deallocation in the entire program. As with all things multi-threaded, this becomes trickier. Luckily, web servers are embarrassingly parallel, so you can just have an arena for each worker thread. Unluckily, web servers do a large amount of string processing, so you have to be careful in how you build them to prevent the memory requirements from exploding. As always, tradeoffs can and will be made depending on what you are actually doing.
Short-run programs are even easier. You just never deallocate and then exit(0).
- Except this is an article on how to perform technical politics in large organizations. Functional, intelligent, non-nepotistic leadership is the exception, not the rule. It has been this way for a long time, perhaps forever. Dilbert became one of the most circulated comics for good reason. This article is the third guy.
Pretending that identifying stakeholders' needs, communicating the solutions, and delivering them are the keys to succeeding in corporate politics is a joke. It's our parent's telling us that we need to be good for Santa Claus. Human politics is an enormously deep subject, and a newbie will get trampled every single time. If you are sitting at a poker table and don't know who the sucker is within five minutes, congratulations, you are that sucker.
- We have already removed so much liability in other licensed professions, either through law or practice. It's almost impossible to obtain a malicious prosecution or SLAPP judgement against attorneys. Malpractice lawsuits have been legally capped all over the USA against doctors. Engineering liability is a joke outside of rare circumstances.
The social will for having real accountability and professional ethics just isn't there. If you license software, large companies will just outsource the stamps to small contractors who will legally assume responsibility while nothing else changes. All real accountability will be so sparse and random that all ethical complaints will be ignored. If this liability becomes large enough to effect anything, all tech companies will band together to bribe politicians to limit legal remedies in the laws themselves.
In the end, the only thing that will happen is that large companies will use these regulations to bludgeon smaller competition like they already do.
- How are you going to get around Griggs v. Duke Power Co.? AFAIK, personality tests have not (yet) been given the regulatory eye, but testing cognitive ability has.
- I would bet that, especially outside of library code, 95+% of the typed objects are only interacted with using a single interface. These could be turned into structs with direct calls.
Outside of this, you can unify the types. You would take every interface used to access the object and create a new type that has all of the members of both. You can then either create vtables or monomorphize where it is used in calls.
At any point that analysis cannot determine the actual underlying shape, you drop to the default any.
- Outside of really funky code, especially code originally written in TS, you can assume the interface is the actual underlying object. You could easily flag non-recognized-member accesses to interfaces and then degrade them back to object accesses.
- Yeah, that is why I said TS (or something similar). TS made some decisions that make sense at the time, but do not help compilation. The complexity of its typing system is another problem. I'm pretty sure that it is Turing-complete. That doesn't remove feasibility, but it increases the complexity of compiling it by a whole lot. When you add onto this the fact that "the compiler is the spec," you really get bogged down. It would be much easier to recognize a sensible subset of TS. You could probably even have the type checker throw a WTFisThisGuyDoing flag and just immediately downgrade it to an any.
- I have thought about doing this and I just can't get around the fact that you can't get much better performance in JS. The best you could probably do is transpile the JS into V8 C++ calls.
The really cool optimizations come from compiling TypeScript, or something close to it. You could use types to get enormous gains. Anything without typing gets the default slow JS calls. Interfaces can get reduced to vtables or maybe even straight calls, possibly on structs instead of maps. You could have an Int and Float type that degrade into Number that just sit inside registers.
The main problem is that both TS and V8 are fast-moving, non-standard targets. You could only really do such a project with a big team. Maintaining compatibility would be a job by itself.
- What do you mean, "So?" This is maybe one step below being removed from the ability to have a checking account. He has been removed from Internet commerce with Zero Recourse and even gaslit by the company harming him.
This will keep happening because people like you will just flippantly continue saying, "It's not my problem." It will become your problem soon. As companies continue ignoring completely screwing a slowly growing percentage of people, that demographic will do what he will likely do next, call his local congressional representative to grab your company by the metaphorical ear.
Internet companies have incredible legal privilege right now. As expected, they are now abusing it as they have grown large enough. I'm glad these companies are filled with people like you because you don't even mask yourself. That is what will make the boot come down faster and harder.
- It happens in all fields, at all levels. You cannot trust any papers without reproducing them. The intentional fraud is rampant. There is too much reward for publishing junk as quickly as possible and too little punishment for misbehavior.
- Apple is just as sleezy as Google but doesn't have as much power and reach. If I don't want to, I don't have to interact with Apple at all. Google is much harder to avoid, impossible in some domains like email.
- Except large code bases do the same. They regularly die when their ability to be understood drops too low. Even with well organized code, they are pushed to add features until they aren't understood at the deepest level. Once you hit millions of lines of code, even when you spend decades in that code base, you still forget changes you made even if you have an overarching picture. That's ignoring other people working on it all the time. The understanding gets reduced to contracts, types, and interfaces.
And most importantly, humans are more complicated than code. With enough time and knowledge, I can accurately tell you what any piece of code does on a single expression or statement. Humans regularly do things they don't even know for purposes they don't understand.
- I explain it in the third paragraph but to illustrate it further: Consider a function. A function that is 1 line long is immediately understandable. At 10 lines, it is readable within a minute or two. At 100 lines, it is maybe legible to someone who lives in that function. At 1000 lines, it is a black box. Human organizations are the same way.
You might suggest refactoring, which is what companies do too. They create departments, promotion ladders, org charts, and mission statements. The problem is that abstractions leak by design. As your abstractions accumulate and change outside your view, your ability to understand the entirety reduces.
- It's less about risk aversion than it is about position, size, and complexity. As these things grow, the incentives change and the ability to understand what the organization even is becomes impossible.
A startup starts at the bottom. It begs investors, customers, and employees from a position of optimism and humility. The organization enthusiastically changes itself to find a good balance between those three or it dies. As the organization grows, it starts demanding everyone else change for them instead. Google's interviews are an example. Its famous customer service is an example.
Then we get to size and complexity. Thanks to Dunbar's numbers, we know that there are numerical limits to a human's ability to know people. This makes sense. I can know everything about 6 people, most things about 50, and keep track of about 250 well enough. As the organization grows, your ability to know it disappears. You begin making abstractions. Instead of knowing exactly what Susan does, you say she works in X Department, for Y Initiative, doing Z position.
Google is so big that one person can't understand it anymore. The inevitable reduction to a corporate abstraction occurs and then people treat it like the X Company, which is just like Y Company but makes X instead of Y. Short term revenue and expenses are the only measures at the end.
And in this faceless abstraction, the professional parasite class infests and extracts resources and morale. Eventually the C-suite stops fighting it and joins in on it until only the sheer size and momentum of the company keeps it going. Maybe an investor group will come and force a rework of the company, but not before the company is just a shadow of the shadow of its former self.
- Freedom not only allows jerks and kooks, but it requires them. We need sovcits and police auditors, because they define the boundary and remind the police and prosecutors, whom are apt to forget, where that boundary is.
Everyone demands victims be kind and normal, but that is rarely the case. Kind and normal people stay far away from the boundaries by nature, but the boundaries always shrink when there is no push-back. We need the kooks out there getting tazed so we don't have to.
There will be small niches leftover:
* Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.
* OS / Kernel - Nearly all of the relevant code is unsafe. There aren't many real benefits. It will happen anyways due to grant funding requirements. This will take decades, maybe a century. A better alternative would be a verified kernel with formal methods and a Linux compatibility layer, but that is pie in the sky.
* Game Engines - Rust screwed up its standard library by not putting custom allocation at the center of it. Until we get a Rust version of the EASTL, adoption will be slow at best.
* High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go.
* Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Mozilla lost their ability to make effective change and already killed their Rust project once. Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it.
* High-Throughput Services - This is where I see the bulk of Rust adoption. I would be surprised if major rewrites aren't already underway.