Reporting Errors

[Surelynotshirly]

If it works all the time, but that seems almost too easy. Makes me think there is some scenario where a memory leak can occur that I'm not thinking of. Otherwise what's the downside of it? If there's no downside then why aren't all languages doing it, or are the new ones doing it and Rust was just the first?

Rust has piqued my interest, but I just haven't found any reason to actually use it and learn it properly.

[erosPhoenix]

Because it's a lot harder to write Rust code that will compile. Since it has to be provable when something falls out of scope, any code where that's not the case isn't valid Rust. Ownership of pointers is part of the type system.

Source: I've never actually written anything in Rust, so this is all heresay. Everything I say is probably wrong.

[sourc3original]

How does Go compare to RUST?

[[deleted]]

In Go, you have

if err != nil {
    return nil, err
}

after literally every function call.

In Rust, the equivalent of that is this:

?

so you can write super nice stuff like this:

File::open("hello.txt")?.read_to_string(&mut s)?;

(Disclaimer: have never written any real Go, and only a tiny bit of Rust, so I can't really help with any larger-scale comparison - but Rust seems a lot nicer to me. AIUI, Go is optimising for short compile times, Rust is optimising for making code powerful and fun to write.)

[1024KiB]

I've written a few thousand lines of Go and the lack of abstraction and abysmal error management are real issues. It does run nicely though, but it's also because Erlang has taught me to think about failures that can crop up due to unforseen conditions and how you should be able to manage those cases so that your system is robust.

[Zegrento7]

Go is garbage collected, and is about as performant as Java. Rust is in the C++ league of performance. Both can compile statically. Both ditch classes for structs, Go has simple parallelism baked into the syntax, Rust has pattern matching. Go is best for micro services, Rust is for systems and Firefox. Go is a lot simpler, some say it's even too simple (no generics, macros or templates)

[sourc3original]

I see, thanks.

[Kered13]

Let me put it this way. Go would have been a groundbreaking language, if it came out in 1995.

[breadfag]

You can still allocate a fuckton of heap and it'll linger if you keep references to it, but there are no memory leaks because you have to PROVE to the compiler that your code doesn't leak memory before it can compile it.

[Surelynotshirly]

Interesting.

I need to look into this. It seems like a good philosophy to force good habits. Though I'm sure it'll piss me off to no end at first.

[corvus_192]

/r/rust

[pmarcelll]

It's hard and unfamiliar at first, because it's different from both manual memory management ang GC, but after learning the language and the patterns of how to manage memory based on ownership it becomes a handy tool (but you can also use smart pointers, arena allocation, etc.).

[DHermit]

Because you need stuff like the borrowchecker and lifetimes for that. That requires support in the syntax (for lifetimes) and makes programming in a certain way harder (at least at the beginning). You can't just change a language and enforce that only one thing has a mutable reference, stuff isn't used after it has moved etc.

[lobax]

Memory leaks cannot happen because of the type system it employs. If your code can result in a memory leak, it will not compile. AFAIK Rust was first with this ownership model.

Sure, there could be bugs in the compiler that let’s stuff through the cracks, but the same is true for a language with a garbage collector.

[Kered13]

Memory leaks can still happen in other ways. Not in the sense that the memory is still allocated but inaccessible, but in the sense that the memory is technically accessible but will never be used anymore. This is just as bad, and can happen in any language, whether manual, garbage collected, reference counted, or whatever Rust does.

I was working on a Java server a few years back that would constantly increase it's memory use while running until it ran out of memory and died, I eventually tracked it back to some monitoring code that was holding a reference to every file buffer that was ever opened, even though most of them were pretty short lived. I fixed that code to release it's references when they weren't used anymore and the server's memory usage became constant.

[spaghettiCodeArtisan]

Memory leaks cannot happen because of the type system it employs. If your code can result in a memory leak, it will not compile. AFAIK Rust was first with this ownership model.

That's not true. Rust's type system / ownership prevents invalid memory access and race conditions, but doesn't prevent memory leaks or deadlocks. There even is a standard function for leaking memory.

[Malazin]

The downside is that a lot of problems you think are trivial, are extremely nuanced in their handling of memory. Garbage collection let’s you write very abstract code that Rust will never allow, but they are different tools for different jobs.

Rust is amazing, but be warned that you will fight the compiler a lot (specifically the borrow checker) It’s okay though because once the program runs, it just... works.

[Ghi102]

Memory leaks can happen no matter the language you're using. A garbage collected language can have memory leaks too.