I despise Facebook and all that it stands for, but if the surplus value that it has extracted from humanity over the last two decades is reinvested intelligently into nuclear energy, I'm actually okay with it.
Despite the hype that you see on Twitter, the hard tech startup scene is actually incapable of large-scale engineering coordination on the level needed for a nuclear power plant, or even a gas turbine.
If any innovation on fission reactors is going to be successfully commercialized, we will need to see billions of dollars of investment over medium to long time horizons.
Of course, the millstone around the neck of nuclear power is that it's a dual-use technology. There's probably a lot more behind the scenes that's been done to stifle the industry effectively for non-proliferation reasons, but masquerading as cost, regulatory problems, environmental concerns, etc.
I would buy a Cybertruck tomorrow if it had a gas engine. I would buy a $10,000 or $15,000 gas generator add-on if it enabled unlimited range (provided I have gasoline).
There are just too many places, even in California, where I have to limit my trip because of electric range.
i actually love the way it looks. i dont own it but i find it some inspiring that a company had to have audacity to create something so futuristic - what are you driving that is so beautiful ?
Interesting. I don't find the TC to be ugly; I find it to be dissonant. It hurts my brain like missed harmonics in a musical performance do. Here are my reasons:
First thing I noticed on reveal day: it looks like a star ship from the the 1985 game, Elite.[0] It's a 3D model of a space ship for a computer that could barely keep up.[1] This design was a great starting point for a child's imagination, but even as a kid it was always assumed that this was the best we can do for now. The future would be far less disappointing. Verdict: this design isn't futuristic; it's nostalgic.
Looking down, I saw that its beautiful, shining, crystalline, space-going shuttlecraft aesthetic sits on matte, round, rubber wheels tied to the ground. It wants to fly, but it can't, and that is sad.
A few months later, I saw the unfortunate resemblance to industrial garbage receptacles usually kept out of site behind decorative enclosures. I realized that while designing one of those enclosures. Then the memes came.
I actually prefer a version I saw that was mounted on tracks for arctic environments.[2] It says, "I am a raw shard of ice carved from a massive glacier," and it pulls it off quite well.
I don't find the idea all that audacious. Several EV trucks were already in the works. The Cybertruck is unique in form, but certainly not in function. There's precedent for sloppily-made stainless steel wedge-shaped American cars [2] thought up by executives on too many drugs [1].
The execution? Whoever figured out how to get a stainless steel wedge on stilts through NHTSA testing deserves a raise. That's sorcery.
Given recent high profile redaction events, I think one simple use of AI would be to have it redact documents according to an objective standard.
That should in theory prevent overly redacted documents for political purposes.
An approach that could be rolled out today would be redacting with human review, but showing what % of redactions the AI would have done, and also showing the prompt given to the AI to perform redactions.
I don't think the commentor above is saying that an AI should necessarily apply the redaction. Rather, an AI can serve as an objective-ish way of determining what should be redacted. This seems somewhat analogous to how (non-AI) models can we used to evaluate how gerrymandered a map is
Whether or not the patent was actually granted in this case, I have not been able to think of a compelling reason to have patents for software. In fact, I think most intellectual property laws need to be seriously rethought.
If the objective is to maximize investment by protecting successful results, I don't think our system is doing a very good job.
Who can do this with good data controls? I don't want to have to dig through the fine print of some Terms of Service page to figure out if a sequencing company is going to save a copy of my genetic code for possible future use.
I sequences my genome about 10 year's ago using illumina platform for ~1200AUD. We used a university sequencing facility. They were happy to extract and sequence the dna using a shotgun approach. Depth was 5x and I think we achieved about 90% coverage. It was just for fun.
The issue with this approach is that you'll receive raw data that needs to be processed. Even after processing you'll need to do further analysis to answer your questions. After all this, I'd be suspicious of the results and seek a medical councellor to discuss and perform further tests.
I'd advise on thinking what questions you want answered. 'Sequencing your genome' sounds amazing but imo you're better off with seeking accredited tests with acrionable results.
The really difficult part of sequencing is after the Vcf. Before that is trivial, you can plug your fastq raw data in some Nextflow pipelines and in a couple of days of computing get plenty of "results" to be busy exploring for years.
> if a foreign power can buy the platforms and adjust information flows to "shift" public opinion their way.
NO.
I will never accept this premise and nor should any American. The people ARE the government and they can be influenced any which way they want to be. There shouldn't ever be any such thing as the government "protecting" people from influence. If the people want to all tune into some foreign broadcaster all day and love everything he's saying. That's how the country will be.
The second you accept "oh foreign influence is manipulating our voters to X or Y so it has to be stopped" you are signing the death warrant for free speech. This is EXACTLY the justification used in all sorts of authoritarian garbage places to suppress information and restrict speech
I agree with you on this. People who don’t believe this fundamentally do not believe in democracy.
You may worry about citizens being sufficiently educated, you may worry about them having access to enough information to make good decisions. But to restrict information for fear that they may make the “wrong” decision—the one you don’t like—there is nothing democratic about that.
Foreign voices and perspectives are critical to understanding the world as a whole and making informed decisions. If the population isn’t ready to take in that information and sort the wheat from the chaff, then they aren’t ready for democracy.
Sure, but there's a difference in intent and degree between "foreign influence is manipulating our voters" via political content on TikTok vs a targeted state sponsored campaign run by intelligence agencies.
There are some common sense guardrails around elections in a democracy, and foreign influence targeting the actual election process is generally viewed as over the line of acceptability.
> foreign influence targeting the actual election process is generally viewed as over the line of acceptability.
Nope. "Influence" is just content. Free people can consume whatever content they want, even if it's about elections. Period. End of story. Either you're free or you're controlled.
That's a severe oversimplification. The world isn't black and white.
Take free speech, which has certain restrictions in most societies. Some societies draw the lines further than others.
Likewise, when it comes to elections, the election process is controlled to some degree. One can't, for example, broadcast misinformation about mail in ballots, because that would threaten the integrity of the democratic process itself.
There are countless ad absurdum arguments that could be made here, but that one will suffice. Say a foreign entity broadcasts misleading information about mail in ballots as part of a wider campaign to convince certain sections of the population that the post office is changing votes. Would banning that activity change a society from a "free" state to a "controlled" state like some sort of binary switch? Of course not, and typing "Period. End of story" is a completely asinine and amateur argument to support that. Devolution into semantics.
What I'm highlighting is that in most democracies, there is a sacrosanct ring around the democratic process itself - arguably necessary to at least some extent - and in the context of misinformation/state meddling/etc that would fall under the category of "election interference" if a certain bar is cleared. Ideally a high bar, so the red tape is as minimal as possible, but when it comes to state intelligence agencies specifically targeting an election itself, there is not just a coherent argument for it, it's the way it is in most democracies worldwide.
You and I both know the US was not interested in forcefully taking over TikTok because of the possibility they could broadcast misinformation about mail in ballots near to election time
That is a crime because it is fraud (election fraud). If this arose on TikTok the great thing is, you can prosecute the creators who post such things. China, by promoting such stuff, in fact would make the prosecution job easier.
People in these comments talk about "influencing" people to have certain thoughts and thus change how they vote by showing them stuff that might change their minds. That is the very idea of free speech itself and it should never be under government control. Not fraud but exposure.
I don’t think Rust syntax and patterns (no classes) are especially elegant for many tasks. I can’t express the behavior of a system as cleanly in Rust as TypeScript, C#, go or Python. I know that’s not what it was designed for, but a guy can dream.
But what Rust has is the best tooling bar none(cargo, build system, compile time checks, ease of first use). The tooling is actually more important than the borrow checker and memory safety in my opinion.
If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language. It avoided the fragmentation of JS/TS (npm, yarn, pnpm, bun, deno) and dep hell of Python (which was a nightmare until uv).
If Rust didn’t have the syntax warts (macros), it would be eating the world.
This is a bizarre take to me, what do you want to do with classes that aren't supported by structs and traits? Imo the usability issues with rust arise from the borrow checker and associated complexity + restrictions on patterns, so I'm surprised that you're citing macros and classes.
Here's a struct that maintains an invariant - say, that field a is less than field b. That invariant should be set when it is created.
You find a bug where a is greater than b. Where is the bug? With a struct, it can be anywhere in the code - any line that touches the struct. But with a (well designed) class, a and b are private, and so you only have to look at lines of code within the class. The surface area where the bug can be is much smaller.
The bigger the code base and the more well-used the class is, the more this matters.
Rust has privacy and encapsulation just fine. More than that, Rust's entire safety story is built on these mechanisms; being unable to (safely) access private fields outside of the module in which they were defined is load-bearing when it comes to safely encapsulating unsafe code.
I think the large C++ or Java shaped hole in your understanding is simply that you think "class" means encapsulated and "struct" means Plain Old Data and in Rust that's not what it means.
Take std::os::fs::OwnedFd the file descriptor. In fact of course this struct is literally just a C-style integer inside, it's the same size in memory, representationally they're identical. But, it's encapsulated, so it gets to enforce the fact that file descriptors are never -1 by definition, and since it is encapsulated it gets to refuse to participate in arithmetic, and to call close when we throw away the file descriptor, and so on. It's a huge improvement.
Ah, that makes some sense, although some reading says that struct member visibility is by default the module, which is a file if you don't do anything. If you wanted you could probably just wrap all the structs you want to be protected inside a module per file? It is a bit annoying though. I guess the issue here is that in rust struct fields need to be accessed for trait implementations. It wouldn't be backwards compatible obviously, but I wonder if they could have tightened that so that by default only trait implementations for a struct can access that structs members?
Just the module the struct is defined in, not the file. Easy mistake to make, given that a file is implicitly its own module, but you can create submodules within a file with the `mod` keyword.
Rust has access control, and rust has better mutability and reference control. Many languages like C# and Java let you take references willy nilly and do almost whatever you want.
I'm confused too! When I write Python, I do it in a similar style as rust, but knowing the classes and enums are sloppier than rust's; regarding mutation for example.
Once you understand that a crate is the translation unit in Rust, it doesn't feel as bad. Most medium to large Rust project's will separate out their code into separate crates for both organization and compile time.
I've definitely cloned down my fair share of C projects, mashed the make command into my terminal, and watched the gcc/clang logs fly by and never batted an eye beyond checking the sha256sum on any downloaded tarballs.
There's a valid argument to be made about supply chain attacks, but there does exist tooling to lock that down, and I would argue that any serious software development firm should be auditing every third party dependency they take on.
> If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language
zig is very comparable, and much faster at doing so. zig also comes with a build system, libc and can compile c programs. its a better c compiler and build system than most, lol.
A type system in programming languages is a way to express and enforce compile time constraints (conventionally, anyway).
zig's type system is pretty straightforward, but its comptime is very powerful and, among other things, can enforce arbitrary compile time constraints. It's not the same as rust's types, but I wonder if it isn't better in many ways.
It's not comparable, comptime is more of an alternative to macros. You can build complex systems with it, but they don't natively give you the algebraic reasoning abilities that the typechecker does, at best you'd have to reimplement it yourself in an ad hoc way. Rust's proc macros are also fully programmable and have comparable expressive power to comptime.
I used Zig in the past (after my "why don't we just write everything simply in C" phase). I don't think I used comptime too much, but I understood why it would be useful.
Now I write Rust and absolutely love it, except for the damn macro edge cases, like not being able to use a known-at-compile-time string for format!() unless it's a literal (I even tried to fake it with more macros, no dice). I think Zig's Andrew Kelley mentioned this exact scenario, if I recall correctly.
It's funny because I do write a lot of code that generates code, but I avoid macros if I can.
Don’t underestimate Zig’s comptime or modern C++’s constexpr. You can use these to prove things about the program at compile-time far beyond the type system. In recent versions of C++, the scope of code that is compile-time verifiable is quite large, nothing like when it was first introduced 15 years ago.
This has limited (but not zero) applicability to memory safety but it has a lot of applicability to many other classes of defect against which Rust offers no special protection. Features like this are why modern C++ is still the language of choice for new software in high-assurance environments at DoD when performance matters. (When performance doesn’t matter it seems to be Java and C#.) These systems often have little or no legacy C++ code as a dependency, so that isn’t a factor.
I have less experience with Zig but this is an area where Rust can’t replicate the safety features of modern C++. With the introduction of compile-time reflection in C++26, this gap will increase. People who aren’t deep in it seriously underestimate what can be verified at compile-time in recent versions of C++ without the use of ugly arcana (which used to be required).
C++ constexpr is a nasty trap. Because after all it says right on the tin that we're getting a constant expression right? So it's as powerful as Rust's const right?
Nope - of course the usual suspects insisted they needed a way to write non-constant expressions and have that somehow "work" anyway. So whereas a const function in Rust genuinely is constant, a constexpr function in C++ might not be, and we only find out whether it was if we force the compiler to do the operation at compile time. If we leave any gap where it can just delay until runtime that's what happens.
You can literally write a random number generator, label it "constexpr" and a modern C++ compiler goes OK, that's not actually constant, but you didn't technically promise it was constant you just used this useless "constexpr" keyword to gesture performatively at the idea of compile time evaluation without promising anything so we'll only complain if you try to use it in a context where I must know the concrete value at compile time.
Zig has not hit 1.0 yet, and as recently as a few months ago completely reworked how every form of IO is written. AFAIK, this wasn't a syntax change, but it changed the function signature or type definition of every piece of code that reads/writes a file, establishes a connection, etc. At the current time, there is little guarantee that the code you write today will still work in 5-10 years time.
Thanks for the info, I was hoping there was something like Rust's editions that would allow for mixing libraries with differing language versions that have breaking changes.
It's not usually the standard library or dependencies that create the issues I've seen. The teams I work with producing Go tools (across multiple companies) invariably require carefully orchestrated dev environments that are nigh-unreproducible. It's 50/50 on whether I can actually build a random project first try without reading the instructions if CGO is involved, which seems to be all of them.
My experience with random rust projects is that they usually "just build", with limited exceptions like weird embedded stuff.
I haven't experienced this. Rust's build system allows you to automate most of the pain in building/bundling those dependencies, so it's just up to the builder to have the right headers (if they're not bundled). That makes it no worse than meson C/C++ builds.
In Go, it doesn't have any of that so it depends on the end builder of the binary to be aware of all the C dependencies and manually manage integrating the cgo configuration into their build process.
Its highly dependent on the kind of project. A few years back libxml and libxmlsec1 were a consistent pain in the neck for me. I don't know about now, I simply moved on from the project that needed me to interact with them.
I don’t hate the C language. I hate the C compiler (and the rest of the toolchain). Anything that helps me not interact with the C compiler is a huge win.
I worked for 10 years with Go and almost never seen a cgo dependcy, it's far more common in Rust, it's not even comparable. Rust replaces tons of c/c++ so it has more ffi.
The vast majority of Go code, like 99% doesn't have a single cgo dependency.
Despite the hype that you see on Twitter, the hard tech startup scene is actually incapable of large-scale engineering coordination on the level needed for a nuclear power plant, or even a gas turbine.
If any innovation on fission reactors is going to be successfully commercialized, we will need to see billions of dollars of investment over medium to long time horizons.
Of course, the millstone around the neck of nuclear power is that it's a dual-use technology. There's probably a lot more behind the scenes that's been done to stifle the industry effectively for non-proliferation reasons, but masquerading as cost, regulatory problems, environmental concerns, etc.
reply