1. Rust does manual memory management. It has some syntactic sugar for it in the form of a compiler-enforced RAII, but that is still manual memory management for all practical purposes. A good distinction to make is whether low-level, memory/ownership details leak into public APIs. This is trivially true for Rust, while is not true of managed languages.
3. Rust only addresses problems related to data races, not as an example. All the other race conditions are still on the table. It is a good thing to have, but I think they are the least problematic, and easiest to solve part of concurrency issues.
4. All of these have been known for like 3 decades. There are plenty of managed languages with these, ML, OCaml, Haskell, Scala. But I think your claim is subjective at best.
> It has some syntactic sugar for it in the form of a compiler-enforced RAII, but that is still manual memory management for all practical purposes.
Then you've got a different definition of "manual" than mine.
Manual means that developer has to insert calls to allocate / deallocate memory and that the developer is responsible for proving the correctness of those calls.
Automated means those calls are done by the runtime or by the compiler automatically, and the compiler makes sure they are correct.
In case of Rust, those calls are inserted automatically by the compiler.
> memory/ownership details leak into public APIs
The fact that ownership is a part of public API is a good thing, similarly how it is a good thing to specify an argument is an integer and not a string.
> There are plenty of managed languages with these, ML, OCaml, Haskell, Scala.
I referred to the ones mentioned in the above comment, which mentuoned Java/Go/Python. Haskell/Scala/Ocaml/ML are quite niche even compared to Rust these days.
But even though Haskell / Scala might get close on some type-system features, they don't offer similar experience as Rust in other areas. Haskell is more restrictive in terms of managing state than borrow-checker, and Scala tooling / compile times has been always horrible.
> Rust only addresses problems related to data races, not as an example. All the other race conditions are still on the table.
This is like saying a statically typed language doesn't stop you from putting a string telephone number into a string surname field. Sure it doesn't. But despite that, the value of static types is hard to overestimate.
In practice, the borrow checking + RAII + Send/Sync rules can be used to make the other types of concurrency problems very unlikely by properly modeling the APIs. Sure, no language can protect from all concurrency problems in general, but at least Rust gives you some good tools. For instance it is trivial to forbid concurrent access to something that shouldn't be accessed concurrently and let the compiler enforce that. Now try enforcing that in your "business oriented language of choice". In my experience the majority of concurrency related problems in real large-scale software development happen when some code not designed to handle concurrency accidentally becomes executed concurrently because developers don't realize something is shared and mutated at the same time. Another type of common issue is with communicating concurrent threads of execution, when one sends a message but the receiver is not there on the other end because of premature exit e.g. due to error, leading to a deadlock. Rust protects from those really well.
> The fact that ownership is a part of public API is a good thing
A libraries next version which switches up some internal representations memory handling should ideally not mess up your application, but it also mandates a higher refactor rate when you are only working within your application’s boundaries. These are worthwhile tradeoffs for the niche rust is targeting, but not for every use case.
I’m not saying Rust is a bad language, I really like using it for its intended niche of complex applications where absolute control is needed, like a browser engine. But it is not a panacea and I would definitely not choose it for a CRUD webapp.
> A libraries next version which switches up some internal representations memory handling should ideally not mess up your application
It doesn't have to because internal memory representation can and should be abstracted out, and Rust gives a plethora of tools to do that.
Your argument works against against static typing in general.
The next version changes the address representation from String to Address (in managed language) and messes up your app. That's the same thing.
If version 1 of your library has a function that returns a reference to T, then that constrains your choices of implementation for the underlying data structures containing Ts more than they would be constrained in a garbage-collected language. So unless there is to be a ban on functions returning simple references, Rust is always going to be a little less flexible in this respect. That is fine and expected given the overall design goals of the language, but there's no point pretending that it's not the case.
The simplest concrete example, I guess, would be a function that returns &'str. There are plenty of Rust APIs out that have functions with this type signature.
> If version 1 of your library has a function that returns a reference to T, then that constrains your choices of implementation for the underlying data structures containing Ts more than they would be constrained in a garbage-collected language
This is IMHO a good thing. If it returns a reference to T, it means it still owns it and allows only temporary usage of it. This is semantics of ownership and does not have anything to do with memory management. If you wanted to allow sharing for unspecified lifetime, sure, you can. There is Rc/Arc.
I've fixed plenty of bugs in code written in managed languages, where a reference to T was handed out from a library (because there is no other choice - everything is a reference) and then someone stored it for longer than it was valid, leading to a logical equivalent of use-after-free.
E.g. get an entity object managed by Hibernate. Pass it up outside of the context of Hibernate session. It will likely blow up because the object references a session that's now closed. Rust ownership model would prevent exactly that problem.
I find this "flexibility" of managed languages actually a problem in large codebases, similarly how flexibility of goto is universally considered bad. It severely hinders maintainablity. It allows to pass references freely and create implicit, complex, often cyclic, reference graphs which are very hard to reason about.
In my Rust code 99% of objects don't need shared ownership. But managed languages make shared ownership the default, optimizing for the edge-case.
BTW, your statement can be rephrased to:
"If version 1 of your library has a function that accepts a reference to T, then that constrains your choices of values of T more than it would be constrained in a dynamically typed language."
You may say that you can use Any / Variant / Object in a statically typed language to overcome that limitation. True, and similarly you can use Rc/Arc/Copy types in Rust.
This is all the same thing. It just takes static typing to the next level. Not only it allows to express constraints on values, but it also allows to express constraints on time they can be used.
This is dogmatic. In can be a good thing sometimes, in some domains. In other instances it can just be a pain.
Let's say I'm using a 'names' library that provides the following utility function:
first_name<'a>(name: &'a str) -> &'a str
My code happily uses this function (which we can assume is not performance critical). At some point, the author of the library notices that there are cultures where the nearest analogue of a 'first name' is not always a contiguous substring of the full name. To fix this bug they must change the function's type. They may choose e.g.:
first_name<'a>(name: &'a str) -> Cow<'a, str>
I'd like to update my version of the library to get the bug fix, but can't do this for free. I have to update the calling code, and possibly even change some of my own internal data representations. This contrasts with pretty much any GCed language. For example, in Go the type of the function would just be
func firstName(name string) string
and the bug fix would require no change in the API.
Now let's relate this example back to what you originally said in response to kaba0:
>> [kaba0:] A libraries next version which switches up some internal representations memory handling should ideally not mess up your application
> It doesn't have to because internal memory representation can and should be abstracted out, and Rust gives a plethora of tools to do that.
The above is a simple example of why this is not true. Any time you write a function that returns a reference, you are limiting the changes you can make to internal representations (both in the library itself and the calling code) without making a breaking API change.
Please don't respond by saying "this API was badly designed in the first place!" Most languages don't give you the opportunity to design APIs badly in this particular way. If all APIs were perfectly designed on day one then of course we'd never have to worry about API changes.
Again, none of this is to bash Rust. I just think it is important to be realistic about the downsides as well as the upsides of Rust's ownership system.
you promised the caller that the output is built directly from the input slice. That is your choice. I'll show you later that you didn't have to.
Similarly by writing this in Go:
func firstName(name string) string
you promised the function accepts a string.
Then you want to change the semantics (the contract) of the function, break your promise and you complain you have to change the signature. You can't do that in any statically typed language.
In Go's case, if you suddently wanted to change the memory representation of name to something else than string, e.g. to a name struct:
func firstName(first_name name) name
then obviously you have to change the signature. This is the same problem.
If you don't want your caller to be affected by lifetimes, just don't specify them in the signature:
fn first_name(name: String) -> String
this is perfectly fine in Rust.
You may say it might be slow because it forces a copy, and forces a particular string implementation. So as I said, Rust gives you tools to abstract out the implementation details:
The flexibility goes actually much further than just relaxing the lifetimes. With this signature I actually can change the name representation from String to any type that can be exposed as a slice, with no additional runtime penalty like virtual calls, which you'd need otherwise in Go/Java.
> I just think it is important to be realistic about the downsides as well as the upsides of Rust's ownership system.
So the downside is that it offers you more choices and allows to express more constraints in the signatures, and you can choose wrong. I guess that's quite ok in a general purpose language that wants to be applicable to many different niches.
>Please don't respond by saying "this API was badly designed in the first place!" Most languages don't give you the opportunity to design APIs badly in this particular way. If all APIs were perfectly designed on day one then of course we'd never have to worry about API changes.
I did edit in that paragraph ~5 minutes after submitting the comment, so apologies if you missed that.
As I said previously, "...unless there is to be a ban on functions returning simple references..." If you're willing to eat all that extra generic ceremony, then yes, you can make Rust APIs that are flexible w.r.t. ownership. However, you can't control the code style of the libraries that you're using.
> With this signature I actually can change the name representation from String to any type that can be exposed as a slice, with no additional runtime penalty like virtual calls, which you'd need otherwise in Go/Java.
Off topic, but you could do this in both Java and Go via generics.
> Please don't respond by saying "this API was badly designed in the first place!" Most languages don't give you the opportunity to design APIs badly in this particular way. If all APIs were perfectly designed on day one then of course we'd never have to worry about API changes.
Ok, I agree. But this is just as well a problem for any language that specifies API in some way. So it is really a decades old debate about static typing disallowing to change things easily. I mean, there might always be certain case when the library author has to change the signature because they made it too restrictive. It just happens that Rust allows you to constrain things that might not be constrainable in other languages, so I guess the chances for that happening accidentally are somewhat higher. But generally I like going from more concrete / restricted to more generic when needed rather than the other way round.
> Off topic, but you could do this in both Java and Go via generics.
I don't think so you can achieve same level of flexibility and efficiency at the same time.
Go doesn't have function level generics, so you'd need interfaces and runtime polymorphism as usual (and runtime penalty).
And in Java you cannot add a new interface implementation to a builtin type like String, so the idea of switching from String to any other type won't work. There is much more upfront ceremony needed to add such flexibility (defining custom interface + implementations and using them from the beginning).
To my mind, the issue is that a substantial portion of lifetime constraints reflect implementation details and not actual domain-level constraints that the programmer specifically wished to enforce. The same thing can of course happen with static type constraints generally, but I think not usually to the same extent.
>Go doesn't have function level generics
Not sure what you mean by this. Go functions can take generic parameters that satisfy a given interface (at compile time). E.g.
func firstName[T AsBytes](name T) T
(You'd have to define the AsBytes interface yourself.)
>in Java you cannot add a new interface implementation to a builtin type
Yes. However, because strings in Go are immutable and byte arrays are necessarily mutable, you can’t safely convert strings to byte arrays (or vice versa) without copying, so it would not necessarily be a particularly useful interface.
By the way, this was an interesting discussion. I do see your overall point more than I did at the beginning of it, although I don’t think we completely see eye to eye on the costs/benefits of lifetimes.
> Your argument works against against static typing in general
I don’t think this argument works. Ad absurdum a very strong type system would even specify the implementation itself, making any change breaking — is that good? No, it isn’t as the useful property of the type system is no longer there. I don’t agree that this usefulness line is behind “ownership annotations” — that’s what you would have to convince me of.
3. Rust only addresses problems related to data races, not as an example. All the other race conditions are still on the table. It is a good thing to have, but I think they are the least problematic, and easiest to solve part of concurrency issues.
4. All of these have been known for like 3 decades. There are plenty of managed languages with these, ML, OCaml, Haskell, Scala. But I think your claim is subjective at best.