Ladybird Browser - die Google, die

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
guiltyspark85 said:
Rust claims here they have backwards compatibility with their editions: https://doc.rust-lang.org/edition-guide/editions/
Click to expand...
That's not backwards compatibility. I can take any standard C99 code (*) and compile it with whatever GCC currently has as its default (don't know; don't care) without changing anything. (There may be issues with library availability, etc. for very old software, but that isn't the fault of C). Automatic "migration" is nice, but it isn't backwards compatible.

* Only one function has been removed, gets, the only truly dangerous C function.

However, there are times when it's useful to make backwards-incompatible changes to the language. A common example is the introduction of a new keyword. For instance, early versions of Rust didn't feature the async and await keywords.

If Rust had suddenly introduced these new keywords, some code would have broken: let async = 1; would no longer work.
Click to expand...
C has added a few new keywords without breaking anything, maybe the pre-processor and headers are actually useful for something after all...

⚞⛇⚟ said:
What is rust and why is it bad? Can someone explain it in laymen's terms?
Click to expand...
Rust (iron oxide) is formed when iron is exposed to oxygen and moisture. Rust impacts the structural integrity of the iron and is best dealt with as soon as possible as the rough surface can trap moisture and accelerate the rusting process.

Rust is the latest in a long line of languages that will finally replace C once and for all. The "community" being full of troons, and the obscenely long compile times get talked about because they are the most visible and understandable to people who don't know much about programming. The language has a bunch of built-in "safety" features to deal with the flaws and deficiencies of C, each with their own "escape hatches" so you don't have to deal with them when it become too inconvenient. The end result is pretty much "funny looking C, but worse".

In this specific case, Rust was already considered a poor choice, as acknowldged:
Andreas Kling said:
When we originally evaluated Rust back in 2024, we rejected it because it’s not great at C++ style OOP. The web platform object model inherits a lot of 1990s OOP flavor, with garbage collection, deep inheritance hierarchies, and so on. Rust’s ownership model is not a natural fit for that.
Click to expand...
And mixing Rust and C++ is just asking for trouble. They don't mix very well and the Rust solution is, of course, more Rust. (hence the dumb joke)
 
Goose the Redeemer said:
That's not backwards compatibility. I can take any standard C99 code (*) and compile it with whatever GCC currently has as its default (don't know; don't care) without changing anything. (There may be issues with library availability, etc. for very old software, but that isn't the fault of C). Automatic "migration" is nice, but it isn't backwards compatible.

* Only one function has been removed, gets, the only truly dangerous C function.
Click to expand...
I've just installed Rust. I've written the following test program, using async as a variable name per their example.

Code: 
fn main()
{
    let async = 1;
    println!("async = {}", async)
}

Running the command 'rustc test.rs' will successfully compile a binary without any errors or warnings. This is because it defaults to the 2015 edition of Rust, the 1.0 release. However, when I run the following 'rustc --edition 2018 test.rs', it errors out because async is a reserved keyword. Sorry, I'm confused at how that's not backwards compatibility?
 
guiltyspark85 said:
I've just installed Rust. I've written the following test program, using async as a variable name per their example.

Code: 
fn main()
{
    let async = 1;
    println!("async = {}", async)
}

Running the command 'rustc test.rs' will successfully compile a binary without any errors or warnings. This is because it defaults to the 2015 edition of Rust, the 1.0 release. However, when I run the following 'rustc --edition 2018 test.rs', it errors out because async is a reserved keyword. Sorry, I'm confused at how that's not backwards compatibility?
Click to expand...
Because the old code is incompatible with the new edition. If you wanted to upgrade to the new edition, you would have to spend some amount of time modifying your code so that it would run. The versioning means you can still compile as if you still had an old compiler, but that’s not backwards compatibility.
 
guiltyspark85 said:
I've just installed Rust. I've written the following test program, using async as a variable name per their example.

Code: 
fn main()
{
    let async = 1;
    println!("async = {}", async)
}

Running the command 'rustc test.rs' will successfully compile a binary without any errors or warnings. This is because it defaults to the 2015 edition of Rust, the 1.0 release. However, when I run the following 'rustc --edition 2018 test.rs', it errors out because async is a reserved keyword. Sorry, I'm confused at how that's not backwards compatibility?
Click to expand...
I suppose that you could consider that to be backwards compatible in that you can take old code and run it through a newer compiler, however, if you wanted to use something else from a newer edition then you would have to change it. Defaulting to 1.0 unless you explicitly tell it otherwise is a workaround for the lack of backwards compatibility (because Rust deliberately chose to discard the mechanisms which C uses to deal with this).

C11 added threading support to the standard library, including atomic type, e.g. atomic_int. This will still compile with -std=c11 (because I didn't include the new header), so I can also use other C11 features, such as unnamed struct/union members.
C: 
int main(void) {
    int atomic_int = 1;
    return 0;
}
(The new keyword is _Atomic (reserved) and the header defines atomic_int.)
 
guiltyspark85 said:
The technical reasons for it being 'bad' seem to get mentioned far less. I think compile times are slow, but I'm sure there are more.
Click to expand...

Don't think anyone has mentioned that the borrow checker, used to ensure memory safety, is not intuitive or easy to understand coming from other languages.

The end binaries also tend to be bloated. Most system tools in Linux link against other libraries and have a dependency trees. Things like Firefox tend not to use any system libraries (they don't like to libjpeg for example, it has its own built-in jpeg decoder, and media tools, and XML engine.) This is done for stability, and web browsers are their own mini-operating systems

The whole Crates system defaults to making large monolithic builds with most dependencies included. This wouldn't be bad for a web browser, but it's not great for system tools that might need to live on embedded hardware. There's an ls replacement called exa. ls is 162kb while exa is 900kb!

Overly Serious said:
The thing with memory safety and C++ is that it gets better and better every year. It's not the 90's anymore. People use standard libraries that are very mature for most things. Tooling and testing have gotten better and better to catch things like this. And I would have thought, though I've been out of the business for a while, that modern AI tools are excellent for catching memory problems in code.
Click to expand...

A lot of that started around C++11 I think? I haven't touched C++ in years, but as I understand it now, you shouldn't every have to worry about unsafe operations like using the wrong delete (delete vs delete[] for arrays) so long as you use a good code linter and adhere to all the new syntax.

There's also "CHERI," a system for handling possible security issues within the CPU hardware itself. Hardware solutions make more sense to me than trying to rewrite everything in a new language. Most CHERI enabled SoCs are still prototypes or experimental though.
 
HootersMcBoobies said:
The whole Crates system defaults to making large monolithic builds with most dependencies included. This wouldn't be bad for a web browser, but it's not great for system tools that might need to live on embedded hardware. There's an ls replacement called exa. ls is 162kb while exa is 900kb!
Click to expand...
You're not kidding. Whilst I accept that it's a young project, I compared the Rust version of coreutils (which I just compiled on my system) with the standard C version pre-installed on Ubuntu. I gave Rust the benefit of building with the flags to optimise for binary size, also.

*drum roll please*

The Rust coreutils is 9MB in size.
The standard C based ones are 4MB.

N.b. this is a combined total of all since the C based one are individual binaries and Rust by default compiles as one big blob. I checked out their ls version as you'd called it out, compiling just that The C binary is 140K for me and the Rust version an insane 2.4MB. That's less of a fair comparison though as plainly the 9MB version is less than each core util individually and the default is combined. But on the other hand it's not entirely unfair as it really speaks to how Rust blobs all those dependencies internally and is a great example of that, really. 2.4MB for ls ! :story:

HootersMcBoobies said:
A lot of that started around C++11 I think? I haven't touched C++ in years, but as I understand it now, you shouldn't every have to worry about unsafe operations like using the wrong delete (delete vs delete[] for arrays) so long as you use a good code linter and adhere to all the new syntax.

There's also "CHERI," a system for handling possible security issues within the CPU hardware itself. Hardware solutions make more sense to me than trying to rewrite everything in a new language. Most CHERI enabled SoCs are still prototypes or experimental though.
Click to expand...
Thanks for that. It honestly jibes with what I feel is probably the case. Maybe one of the people who actually still works with C++ can comment. I think @The Ugly One does? But I really feel like they make more of a meal out of Rust's 'advantages' than they really should, in order to drive the political side. I would be interested to see how much real world Rust development deliberately side-steps some of the safety features, which I believe you can do.
 
teriyakiburns said:
Might be better to compare it to BusyBox then, or some other combined userspace blob. I think busybox rocks in at under 3MB.
Click to expand...
In theory, but busybox has a bunch more things in it than coreutils so it's not a fair compari.... Oh, wait. My busybox binary is still smaller than the Rust Coreutils and wins anyway. :story:

Yes, mine is < 1MB.

I actually think though it seems unfair that the coreutils one is a good comparison because the default combined approach they use is actually a small hiding of the issue. The fact that the individual executable are so chunky is really an illustration of the way it drags in so much. The combined version actually helps hide the problem, despite being a bigger absolute file size.

In any case, my biggest concerns with Rust is the evangelical side of it as much as anything technical, and the way in which it's being used to change the licencing terms of software and drive out the non-political people.
 
Static linking > Dynamic linking tbqhfr. This is one of the things Rust gets right, along with most newer languages. I member seeing something from the Plan 9 devs talking about how their linker was smart enough to pull in individual symbols from libraries rather than copying the whole thing in when you linked against it. Perhaps Rust’s is simply more crude and pulls in whole libraries rather than only the portion it needs. Perhaps their crate system is supposed to manage this, but most crates are too big to effectively do so and so everything ends up too big.
 
I'm not as down on this based on file size as my posts may suggest. This isn't the era of the i386 with its 1KB of L1 cache and you felt like Midas because your hard drive had 400MB. There's no point in having all this hardware advance if you don't use it. But... it's `ls` and friends. You need to be getting something in return for this, not just using more resource because you have it.

We've all seen the meme of Margaret Hamilton with her NPM package list for Hello World. It doesn't get much more bloated than web development, but even there you do get something - you get standardised tool chains and extensive libraries and compatibility across a big range of browsers. The software doesn't work better but the industry itself gets non-silo'd tech skills and rapid development and testing suites. And when it comes to systems programming I don't mind if the coreutils takes up 9MB instead of 4MB - even if I (deservedly) make a little fun of it.

But I don't see what we do get. Static Linking advantages over Dynamic, yes, they exist. But any performance issues in the coreutils are going to be in things like file system access or networks. You're not going to improve over what's there. We're in an age where testing is becoming far more automated which offsets a bunch of safety concerns.

It's not so much that I'm down on Rust technically, as that I feel its technical advantages are weighed extra heavily as a way to push it for the political reasons.

But then it's a long time since I've done systems programming. The guy seems to really feel they need to move away from C++. I honestly don't quite get it but he's in a better position to know than I am.
 
Overly Serious said:
But then it's a long time since I've done systems programming. The guy seems to really feel they need to move away from C++. I honestly don't quite get it but he's in a better position to know than I am.
Click to expand...
He sees the writing on the wall probably. The trannysphere and its supporters have been hard at work shilling Rust, which means newer generations of programmers are going to stick with it. If he doesn't do this, once C++ boomers start dying off or retiring, maintaining the codebase is gonna be hard.
 
GNU Abyss said:
He sees the writing on the wall probably. The trannysphere and its supporters have been hard at work shilling Rust, which means newer generations of programmers are going to stick with it. If he doesn't do this, once C++ boomers start dying off or retiring, maintaining the codebase is gonna be hard.
Click to expand...
Is it really that dire? Maybe I should dust off my own C++ skills. Might be able to make some pretty sums when it comes to maintaining old systems. Although perhaps AI will eat that market.
 
Last edited:
Overly Serious said:
Is it really that dire? Maybe I should dust off my own C++ skills. Might be able to make some pretty sums when it comes to maintaining old systems. Although perhaps AI will eat that market.
Click to expand...
I'm only saying this based on the state of open source programs, Ladybird's part of that.
 
Wake up, February video just dropped
Overly Serious said:
The guy seems to really feel they need to move away from C++. I honestly don't quite get it but he's in a better position to know than I am.
Click to expand...
GNU Abyss said:
He sees the writing on the wall probably.
Click to expand...
The reason he gives is parallelization. Perilous in C++ and a lot easier to do in Rust. But the plan is not a full rewrite, just interop
 
August Levasseur said:
Josh Moon cameo when he opens up Xitter
Click to expand...
Good point, didn't catch that
1772765265129.png
 
Regarding the Rust question. I'm not a coder, but Rust appears to be a relatively new language. If the mass adoption of Rust is seen as a cultural problem in part everyone supporting 'out with the old in with the new' mentality. Doesn't that suggest when the next meme language drops, everything will be rewritten again? Will the Rust cheerleaders gatekeep the Rust rewrites and condemn the newer language?

What I'm asking is if there's a likelihood of another better language to be expected right around the corner? Rust will lose it's cool shine eventually.
 
Virtue's Last Reward said:
Doesn't that suggest when the next meme language drops, everything will be rewritten again? Will the Rust cheerleaders gatekeep the Rust rewrites and condemn the newer language?
Click to expand...
Yes, that happened to some extent with Zig, but Zig will not be the Rust killer. The last event of such sorts was Go to Rust.

Virtue's Last Reward said:
What I'm asking is if there's a likelihood of another better language to be expected right around the corner? Rust will lose it's cool shine eventually.
Click to expand...
I predict that Rust will not lose its dominant position as "most loved language" in the next decade because of its deep-rooted cultism and because it actually solves many of the pain points from previous system languages. There are not enough valid criticisms of Rust (as of now) to warrant the creation of a new "superior" language.
 
You must log in or register to reply here.
Back
Top Bottom