The Servo Browser Engine Has Been Making Great Progress In 2023

[Artim]

Just because morons like you says it's true doesn't make it any true, in fact it says the exact opposite since it comes from you specimens.

Thanks for proving my point. It's not that you can't just visit GitHub and other platforms and have a look for yourself. But wait, that would destroy your idiotic world view. Well, your problem. Don't make it other peoples problems.

Nope, because it doesn't. You can keep claiming stuff, it won't make it true.

"Experts" lmao. If they use Rust they're already off that tag.

Says the stupid dumbfuck that never wrote a single line of code in his entire life?

Coming from a rusted brain that sure means a lot. You want some help unrusting those neurons?

Keep wondering why Servo is dead and not adopted by most apps, though. I'm sure you'll figure it out... eventually...

Guess what moron, Servo isn't dead anymore, and the simple reason it hasn't been edopted by most apps isn't because it's written in rust, but because they all flocked to Chromium long before Servo even was an experiment at Mozilla. But hey, what's facts for someone as dumb as you?

[ehansin]

I am not a programmer, but my observation has been that there is a lot of interest in Rust, and seems like a good language for more lower-lever or systems-level stuff. On a side note, I am also seeing some cool stuff in Go these days, where a whole web application can be wrapped up in a single binary (web server + logic + front end assets + etc.) Here is one I just discovered, download the single binary and was able to try it out (and my initial thoughts were it is super slick):

https://github.com/filebrowser/filebrowser

Same concepts as you see with Gogs/Gitea/Forgejo programs. Anyway, different languages have there different strengths. Personally I like all the stuff happening in/with Rust.

[bug77]

Oh this will be funny, please enlighten us how memory leaks work if not by losing the reference without freeing the memory.

You don't need to lose a reference, you can simply keep allocating memory to what you already use. No automated check can fix that (though some could raise a red flag, maybe).

[bug77]

I am not a programmer, but my observation has been that there is a lot of interest in Rust, and seems like a good language for more lower-lever or systems-level stuff. On a side note, I am also seeing some cool stuff in Go these days, where a whole web application can be wrapped up in a single binary (web server + logic + front end assets + etc.) Here is one I just discovered, download the single binary and was able to try it out (and my initial thoughts were it is super slick):

https://github.com/filebrowser/filebrowser

Same concepts as you see with Gogs/Gitea/Forgejo programs. Anyway, different languages have there different strengths. Personally I like all the stuff happening in/with Rust.

I am a programmer and I agree. For casual stuff, you get do it quickly in Go. For more "hardcore", you'll never find something that will get it done faster than Rust.

There are only two areas where C will still beat Rust today:
1. Exotic hardware (gcc can still generate code for stuff rustc won't)
2. Binary size. If you need small executables, Rust still can't do that out-of-the-box.

[Anux]

There's a difference between sending information to another process to ingest and a garbage (or you yourself in the absence of a garbage collecotor) collector neglecting freeing up space.

Sure, did I claim otherwise? My point was, a language that has the capabilities to communicate with other has the "tools" you need to leak memory, because it can drop the reference to memory without freeing it.

A memory leak isn't the process of removing reference to memory

What? That is it's very definition. As long as you have a reference to that memory it is not leaked.

but the faulty behavior of not releasing memory when not needed anymore.

That's not what I understand under memory leak but yes it's effect is the same. But this has nothing to do with an error a language could fix, it's a logic error and I wouldn't know how an automatism could ever detect or avoid this.

[bug77]

A memory leak isn't the process of removing reference to memory

What? That is it's very definition. As long as you have a reference to that memory it is not leaked.

That's the definition for garbage collected languages. For everything else, you have to actually free the memory, not just get rod of the pointer.
And yes, memory can be leaked if you still have a pointer, when you hold that pointer by mistake (e.g. you keep building "temporary" data structures, but forget to get rod of them).

[Anux]

2. Binary size. If you need small executables, Rust still can't do that out-of-the-box.

https://darkcoding.net/software/a-very-small-rust-binary-indeed/

You need custom RUSTFLAGS and a post-compile script (that could easily be automated).

That's the definition for garbage collected languages. For everything else, you have to actually free the memory

No it's the same, the difference is, when you drop the reference in a GC language and the GC works correct you 'should' never have a memory leak. With no GC, you drop the reference -> memory leak.

[bug77]

https://darkcoding.net/software/a-very-small-rust-binary-indeed/

You need custom RUSTFLAGS and a post-compile script (that could easily be automated).

Yeah, that -Z build-std is still an experimental feature. If it works, big help right there, but I'm guessing there are a number of cases where it won't, hence the "experimental". Plus, the part where he basically turns a main method into a big unsafe block is just rubbish, nobody would do that to production-ready code.

[Anux]

hence the "experimental".

Oh didn't know it still is, the article is pretty old by now.

Plus, the part where he basically turns a main method into a big unsafe block is just rubbish, nobody would do that to production-ready code.

Where does this happen? I only see unsafe where it is necessary.

[darkonix]

https://darkcoding.net/software/a-very-small-rust-binary-indeed/

You need custom RUSTFLAGS and a post-compile script (that could easily be automated).


No it's the same, the difference is, when you drop the reference in a GC language and the GC works correct you 'should' never have a memory leak. With no GC, you drop the reference -> memory leak.

If you keep a reference to memory that's no longer needed and don't release it's a memory leak anyway. It is not releasing it that makes it a leak, not the reference.