calcopiritus

I don't see how LLVM helps with bootstrapping.

Yes, it helps with supporting newer platforms, since LLVM is a big project and will probably have support for the new platforms relatively fast.

But as long as any part of the whole process is in rust, it means that you need a rust compiler to build the rust compiler, thus needing to solve the bootstrapping problem.

Of course, every compiler has this issue (even if not self-hosted, you still have to bootstrap the compiler of the language your language is written in).

The only solution for this is to have a compiler-chain where the first level is a simple compiler that can be relatively easily written in the assembly language of the new platform.

EDIT: or of course I could've read any other comment. Of course you can use one of the intermediate representations that are portable to build the first compiler. In which case you don't need a rust compiler, just need LLVM. Makes sense then.

You can reference count, but you must do so explicitly, just like in C++ you have to explicitly use std::shared_ptr, in rust you must explicitly use std::rc::Rc.

Rusts' memory safety is managed at compile time, that's what the borrow checker does. It enforces a strict set of simple rules that guarantee at compile time that all the references are valid when they are used. This means that there is no runtime cost.

Q: "Why would you use Rc then? It would only introduce runtime overhead that is not needed because rust already checked that the program is correct"

A: the borrow checker ensures that your program is valid. However, not all valid programs are allowed by the borrow checker. That is what unsafe is for. unsafe allows you to skip some rust safety features if you want to make a program that is valid but rejected by the "safe" rust compiler. Rc uses unsafe internally to expose an API that is safe, but allows you to do things that would normally be rejected by rust.

Of course, the borrow checker is not all the safety features of rust. There are some safety features that actually do have runtime checks.

For example, you can try to access invalid memory by reading out of the bounds of a buffer/array. Most of the time, it is impossible/impractical to solve for this at compile time. Therefore, a bounds check is done on every array access, if the check fails, the program crashes. That check is done at run time. Many times the compiler will optimize those checks, but sometimes they just cannot be optimized out.

What the fuck

You guys don't pay with cash?

So every purchase you make, doesn't matter how small, you give a cut to the payment processor? I'd be fucking pissed if I were a small shop selling to you. In fact there are many shops that just refuse to sell if you buy something too cheap through a payment processor.

If you pay your employees, it stops being profit. Paying employees is a cost. Profit = revenue - cost. You cannot hurt employees by taxing profit.

Low level goes way beyond raw pointers. But yes, rust does have raw pointers.

Java does have raw pointers too I believe though. I wouldn't call it low level.

But low level is not well defined. At some point, the difference between low level and high level used to be whether you had to write a different program for each computer architecture. Under that definition, C is a high level language. Assembly (and very old languages) would be low level.

My own definition of low level is: if you have to care at all about memory management, it's low level.

Basically, if the language has a garbage collector or if it automatically counts references without you explicitly telling it so, it's a high level language for me.

If you want an idea: just yesterday libre office writer crashed on me like 7 times. Losing all unsaved progress each time.

If someone competent wrote a good OSS alternative I would download it in a heartbeat.

Yes, the end goal is very similar to a garbage collector. Both are advanced systems of memory management.

The most important difference being that a garbage collector runs at runtime, while the borrow checker at compile time. Which means that the borrow checker has 0 impact on the program's performance. It just takes longer to compile the program.

Which also means that, while the garbage collector says "you can do whatever you want with memory, don't worry about it, I'll handle it for you". The borrow checker says "you fucking donkey. Why did you do that? I won't compile this if you don't fix it".

So you trade programmer comfort for performance (end user comfort).

Lemmy is social media, not school. Nobody owes an explanation. Mostly because the poster cannot know the knowledge level of whoever is gonna read the post. If every post has to be explained for every potential person that could read it, every post would be followed by a wall of text. Of all social media, the only time I've seen it happen is pugjesus' history posts. Which makes sense since he often references some niche history knowledge that very few people would know about.

Just googling "borrow checker" would've shown you it's something rust-related.

Yes. Someone that knows just a little more of rust than you do would know what the borrow checker is.

It's the core feature of rust.

Like talking about java and not knowing what "inheritance" is.

EDIT: just so you understand how vibecoded that project is.

The dude says he vibecoded "some of it" because some rust features make it a hard language for him. The one feature he's talking about is the borrow checker.

It's like saying "man, sure is hot today". Someone says "yeah, this summer sure is hot" and the dude replied "yeah, summerians lived in a hot place too".

I don't understand how anyone that plays online games would buy a PS or an Xbox. Paid online is so dumb.

If buying is piracy, piracy is not stealing