GCC still for Linux distributions using glibc or any other library with many "GCCisms". Also, I'm not sure whether or not Clang is ABI compatible enough for enterprise customers with some rather extreme backwards compatibility requirements. Still, I can imagine a future where glibc can be built with Clang, possibly even one where llvm-libc is "good enough" for many users.
Where the Soviets were first, the US was typically very close behind (sometimes by just a few days). However, US space missions were of significantly greater value while Soviet missions were often just good enough to claim whatever "first" they were going after.
Have you opening Mathematica recently? Or visited the product page for Mathematica[1]? The only change has been branding the language itself as the “Wolfram Language” where Mathematica is just one of their product offerings.
Mathematica is open on my computer as we speak (or, rather, now Wolfram.app). The "About" screen indicates "Wolfram 14.2". I have a seat on an site licence.
Mathematica (MMA) and the Wolfram Language (WL) used to be the one and the same. But now a user could be using WL in a web based notebook, through Wolfram Alpha, or even on SystemModeler.
The brand name “Mathematica” isn’t going anywhere, not after nearly forty years. It’s basically marketing being like “how do we communicate updates to WL as not just being updates to MMA?”.
> The brand name “Mathematica” isn’t going anywhere
But it’s not what it used to be. Now you don’t “run” Mathematica - you “access” it running another program. It’s basically marketing to weaken one brand and strengthen the other.
And yet because Wolfram has a perpetual money machine called Mathematica, he’s got a huge megaphone to advocate for himself.
Wolfram primarily posts to his blog and occasionally publishes a book. He’s not exactly buying a marketing blitz with all of his money. Wolfram Research itself is primarily focused on other things too.
I don’t know what it is about Stephen Wolfram that drives people crazy. Yes, he’s self aggrandizing, but he’s hardly unique in that respect. Simply read past it or roll your eyes and move on. But apparently there are more than a few people who can’t help themselves (even this thread is an example).
Using (formal) specification languages doesn't guarantee a specification is "correct" either.
You have to write more code, and in a different language, but unlike just testing you can actually prove that invariants hold for all possible inputs.
Formal verification is needed to show that the code actually implements a specification. If anything, a formal specification is really good for generating test suites for the implementation code.
The SLS being a government funded competitor to SpaceX has little hope
SLS was never about being the most practical and/or efficient launcher. It is a pork barrel project, but one with an important role. In particular, it is maintaining vital aerospace industrial capacity. If the US wants things like ICBMs then programs like SLS are a necessary evil.
If the US wants ICBMs they'll leverage existing designs. The SLS has nothing to do with them, not in the slightest, aside from the fact that they're all cylindrical in shape.
I can't imagine there's much overlap. The early SLS uses space shuttle solid rocket booster casings (because the people involved are only the dumbest people on the entire planet Earth) which don't have parts commonality with anything else. The later SLS, bleh who cares what they'll do, with any luck cancellation.
Just look at the suppliers working on the SLS SRBs and those working on the LGM-35 program, perhaps then you'll see the extent of the overlap. Furthermore, you might want to look into why the space shuttle had the architecture it did, and why space shuttle SRBs were being shipped out of Utah. Large scale SRB manufacturing has been, and continues to be, an enormous problem for the DoD. Hence why wasteful programs like SLS exist.
I suspect the facilities working on SLS solid rocket boosters are owned by Northrop Grumman, just like the companies that were left over from making Peacekeeper missiles, now making Sentinel missiles, are probably now owned by Northrop Grumman. This doesn't show that Sentinel - or any other program - is benefitting from SLS's supply chains in a meaningful way. It's hard to see how that's possible, given SLS's low-volume nature. But I guess I'll try to keep an open mind...
> Furthermore, you might want to look into why the space shuttle had the architecture it did
I have lots of opinions about that, but if you have some reference material you'd like to recommend, please do! (and if they support the notion that SLS SRB production is somehow a boon to SRB makers everywhere, I guess I'd be intrigued by that as well)
"there's less missile business, and the missile people are making moon rockets now, but I don't see how that could possibly help them make missiles again if they were asked to"
This conversation is painful because people don't seem to understand that, okay, military boosters and civilian boosters are both related businesses, but the SLS SRB business is something separate and is as similar to the others as a fish is to a turnip.
The USA also fielded liquid-fueled ICBMs, but I believe they have all been decommissioned in favor of solid-fueled missiles, which are more reliable and easier to store.
There's lots of bad ideas currently becoming government policy, and that's not even a unique flaw of the USA or Trump or Musk.
So, just because idea of using Falcon 9s as a delivery solution for a strategic nuclear deterrent may be as bad as ordering your chief designer to throw a big steel ball at the window of the new model of car you're currently in the middle of announcing even despite the guy's obvious reticence, doesn't mean it won't happen.
I don't think it's a stretch at all. GP is pointing out a specific instance that illustrates that Musk doesn't truly understand the capabilities of the things he builds. He talks a good game, but he's not actually a rocket scientist/engineer. But he'll push for whatever he wants to push for, and people like Trump will eat it up and let him do what he wants.
If Musk wants to push for "Falcon 9-based liquid-fueled ICBMs", he'll do so, even if he actually does know they're not the best/right tech for the job. And someone like Trump will listen to him.
It's also a bit in bad faith of you to play the "you only disagree because Musk bad" card, when GP explicitly acknowledges that these sorts of bad government decisions are not unique to the US/Trump/Musk.
No one is seriously going to propose a liquid fueled rocket for the nuclear deterrence mission. It simply doesn't work.
However, there are potential military applications for a vehicle like Falcon 9. For example, imagine being able to insert a Special Operations team almost anywhere in the world on a few hours notice. In a potential near-peer conflict there will also be a need to quickly launch replacement military satellites to make up attrition losses.
>Just from a quick glance: I see he's talking about things like stack overflows and std::bad_alloc.
There are specific scenarios that a major issue, yes. But as the title of the video implies, the problem with exceptions runs far deeper. Imagine being a C++ library author who wants to support as many users as possible, you simply couldn't use exceptions even if you wanted to, and even if most of your users are using exceptions. The end result is that projects that use exceptions have to deal with two different methods of error handling, i.e. they get the worst of both worlds (the binary footprint of exceptions, the overhead of constantly checking error codes, and the mental overhead of dealing with it all).
C++ exceptions are a genuinely useful language feature. But I wish the language and standard library wasn't designed around exceptions. C++ has managed to displace C almost everywhere except embedded and/or kernel programming, and exceptions are a big reason for that.
> Imagine being a C++ library author who wants to support as many users as possible, you simply couldn't use exceptions even if you wanted to
I'm pretty sure that (much) less than 50% of the C++ code out there is "a C++ library that wants to support as many users as possible" -- I imagine most code is application code, not even C++ library code in the first place. It's perfectly fine to throw e.g. a "network connection was closed" or "failed to write to disk" exception and then catch it somewhere up the stack.
> The end result is that projects that use exceptions have to deal with two different methods of error handling. i.e. they get the worst of both worlds
No, that's not true. You might get a bit of marginal overhead to think about, but it's not the worst of both whatsoever. If you want to use exceptions and your library doesn't use them, all you gotta do is wrap the foo() call in CheckForErrors(foo()), and then handle it (if you want to handle it at all) at the top level of your call chain. It's not the worst of both worlds at all -- in fact it's literally less work than simply writing
std::expected<Result, std::error_code> e = foo();
and on top of that you get to avoid the constant checking of error codes and modifying every intermediate caller, leaving their code much simpler and more readable.
And of course if you don't want to use exceptions but your library does use them, then of course you can do the reverse:
std::expected<Result, std::error_code> e = CallAndCatchError(foo()).
Nobody is claiming every error should be an exception. I'm just saying you're exaggerating and extrapolating the arguments too far. A sane project would have a mix of different error models, and that would very much still be the case if none of the problems you mentioned existed at all, because they're different tools solving different problems.
