4 ms·

> Rust isn't really that difficult Fun Rust novice exercise: Write a linked list implementation in Rust. Regarding the carbon footprint stuff, I think any run

> Rust isn't really that difficult Fun Rust novice exercise: Write a linked list implementation in Rust. Regarding the carbon footprint stuff, I think any runtime performance efficiency stuff might often be outweighed but the massive compile times for development and CI.

speed_spread 3y ago
Fun C exercice: write a linked list impl that's guaranteed leak free, thread safe and type safe at compile time. Good luck!
- olliej 3y ago
  [edit: oliver used wall of text. Was it effective?] No need to get defensive, no one is arguing that rust doesn’t do a lot of things well. They’re saying that a lot of the restrictions makes things much harder than other languages. Hence the general problem rust has where a lot of trivial tasks in other languages are extremely challenging. The fact that these things are much harder in rust due to design decisions in the language to ensure that everything is guaranteed to be safe in all cases does not change that the language can be harder to use. You’re talking up getting a safe implementation in C, but what matters is “can I get the same level of safety with less complexity in any language”, and the answer is yes: Java and c# implementations of a thread safe linked list are trivial. If I wanted I could do it in c++ though the complexity would be more than c# and Java it would be easier than rust. We know that rust makes some things more complicated than other languages for the same level of safety plans correctness, but that’s ok because complexity is a trade off. Rust has increased complexity of some “simpler” things to reduce the overall complexity of larger systems. This is an ok choice. But it is still a trade off, and part that trade off does make some things harder. People can point that out without it being an attack on the language.
  - spease 3y ago
    > They’re saying that a lot of the restrictions makes things much harder than other languages. Hence the general problem rust has where a lot of trivial tasks in other languages are extremely challenging. Like what? So far the discussion has revolved around rewriting a linked list, which people generally shouldn't ever need to do because it's included in the standard lib for most languages. And it's a decidedly nontrivial task to do as well as the standard lib when you don't sacrifice runtime overhead to be able to handwave object lifecycle management. - C++: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_list.h https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-... - Rust: https://doc.rust-lang.org/beta/src/alloc/collections/linked_list.rs.html https://doc.rust-lang.org/beta/src/alloc/collections/linked_... > No need to get defensive, no one is arguing that rust doesn’t do a lot of things well. That's literally what bsaul is arguing in another comment. :) > You’re talking up getting a safe implementation in C, but what matters is “can I get the same level of safety with less complexity in any language”, and the answer is yes: Java and c# implementations of a thread safe linked list are trivial. Less perceived complexity. In Java and C# you're delegating the responsibility of lifecycle management to garbage collectors. For small to medium scale web apps, the added complexity will be under the hood and you won't have to worry about it. For extreme use cases, the behavior and overhead of the garbage collector does became relevant. If you factor in the code for the garbage collector that Java and C# depend on, the code complexity will tilt dramatically in favor of C++ or Rust. However, it's going to be non-idiomatic to rewrite a garbage collector in Java or C# like it is to rewrite a linked list in Rust. If we consider the languages as they're actually used, rather than an academic scenario which mostly crops up when people expect the language to behave like C or Java, the comparison is a lot more favorable than you're framing it as. > If I wanted I could do it in c++ though the complexity would be more than c# and Java it would be easier than rust. You can certainly write a thread-safe linked list in C++, but then the enforcement of any assumptions you made about using it will be a manual burden on the user. This isn't just a design problem you can solve with more code - C++ is incapable of expressing the same restrictions as Rust, because doing so would break compatibility with C++ code and the language constructs needed to do so don't exist. So it's somewhat apples and oranges here. Yes, you may have provided your team with a linked list, but it will either (1) Perform less efficiently, due to needing the GC to check whether to free things (2) Require more expertise to use safely, due to C++ being incapable of expressing constraints > Rust has increased complexity of some “simpler” things to reduce the overall complexity of larger systems. This is an ok choice. This is sort of right and sort of not. In the context of Java and C#, Rust hasn't "increased complexity", it makes it explicit rather than paying runtime cost to try and hide it. In the context of C++, Rust hasn't "increased complexity" either, it makes it mandatory to deal with things that C++ lets slide. I'd look it more as Rust requires a higher degree of confidence in the code. Rust is more likely to take the programmer to task about "What did you mean?" or "Are you sure about that?". It's like doing a code review with an extremely pedantic developer. As a product of this, the performance is better because the programmer has pre-answered questions which would otherwise need to be disambiguated by a garbage collector at runtime. The less ambiguous behavior makes it faster to integrate modules, because the compiler can point out discrepancies between what the code owner said they expected and how something is being used by itself. But it's not like Rust added that complexity - it was always there. C++, C#, and Java just let you ignore at the risk of adversely affecting software stability or performance, respectively.
    - soulbadguy 3y ago
      You seem to be mixing "designing" a linked list and just implementing a known design. > which people generally shouldn't ever need Agree! However, we can still use the implementation of a "reasonable" linked list a good yard stick to measure things across languages since it usually involves a good coverage of basic language features (like collection, traversal, life time management etc... etc...). Also, looking at the rust implementation of the linkedList you linked, we do have the magic unsafe keyword somewhere in there... which negate a lot of your argument have probable safety. > Less perceived complexity. This a seems very strange thing to say. Isn't reducing perceived complexity the name of the game in language design ? Reducing the complexity the dev have to carry in their mind by moving some of the decision to the toolchain is in my option a very valid approach. > In Java and C# you're delegating the responsibility of lifecycle management to garbage collectors. For small to medium scale web apps, the added complexity will be under the hood and you won't have to worry about it. > For extreme use cases, the behavior and overhead of the garbage collector does became relevant. First, designing for non extreme case is a valid approach in language design. Make the common case dead easy, and for complicated/rare case, provide API and customization points. In .Net/Java it is possible (also not always easy) to beat the GC into submission. Second, i think the comment about GC not being adequate for large scale web app is very 1990.New garbage collectors are able to manage those use case easily. A lot of the largest backend are in java. > If you factor in the code for the garbage collector that Java and C# depend on, the code complexity will tilt dramatically in favor of C++ or Rust. Why would you factor the code of the garbage collector in the equation... > However, it's going to be non-idiomatic to rewrite a garbage collector in Java or C# We are not talking about idiomatic vs non idiomatic. We are talking about simple and not simple. Writing GC friendly code in Java (even better in C# in my opinions with Structs) is still relatively simple and clean. > You can certainly write a thread-safe linked list in C++, but then the enforcement of any assumptions you made about using it will be a manual burden on the user. This isn't just a design problem you can solve with more code - C++ is incapable of expressing the same restrictions as Rust, because doing so would break compatibility with C++ code and the language constructs needed to do so don't exist. The unsafe keyword in the implementation pretty much negate all of this... > Yes, you may have provided your team with a linked list, but it will either (1) Perform less efficiently, due to needing the GC to check whether to free things (2) Require more expertise to use safely, due to C++ being incapable of expressing constraints 1) is a very strong statement, GC code can perform better than manual memory management, and does in a lot very real case. GC vs non GC is not about performance or efficiency, it's about control. Do you want to do it, or do you want the system to do it. The best parallel is register allocation : can you do a better job than the compiler in some case ? maybe. But in average (especially when you had things like x-function register allocation) in most case the compiler beats every dev except the top 5%. > In the context of Java and C#, Rust hasn't "increased complexity", it makes it explicit rather than paying runtime cost to try and hide it. In the context of C++, Rust hasn't "increased complexity" either, it makes it mandatory to deal with things that C++ lets slide. Making it explicit is increasing the complexity... > it makes it mandatory to deal with things that C++ lets slide. And thus making it "harder" to produce the same code... > But it's not like Rust added that complexity - it was always there. C++, C#, and Java just let you ignore at the risk of adversely affecting software stability or performance, respectively. I don't have a nice way to say it, just gonna say it : This is what fanboyism sounds like. C++/Rust and java are different point in the language design point. Now they are not perfect, as in it might be posssible that for each their respective domain, we can with the benefit of hindsight design something that works better. But to think that rust magically found a point in that design space which doesn't also add another sets of compromise is not realistic.
LeFantome 3y ago
I am sure you know enough about Rust to know that writing a linked list in Rust is not a “novice exercise”. It is also not something you require to use the language. This is like a C# dev trolling a C developer by say “first novice exercise”, HTML encode a UTF8 string. I mean, it is a single line of code in C# so how hard could it be in C? Or, it is like a C dev telling a Java programmer that their “first novice exercise” should be to write a fixed binary layout to a device driver or even just to call directly into an OS system call. Both are trivial in C after all. How about using a hash table for something though? Reasonably big job in C but new HashMap in Java. Rust is designed to prevent exactly the kind of thing you do to create a linked list and it is designed to make it difficult for a good reason. It is a cherry picked example meant to sound smart but, in reality, it is an eye-rollingly dumb thing to say. In DOS, I can write a program to dynamically overwrite and extend the behaviour of the operating system in RAM. In Linux, I cannot easily do that. I guess that means DOS is more advanced? To me, this sounds like the argument you are making about Rust. I do it care which language people like. There are pros and cons of each and legit arguments on use one over the other. Why not use one of the valid arguments instead of dumb gotcha comments that only tell us the languages are different and not which one is better.
- appleskeptic 3y ago
  >This is like a C# dev trolling a C developer by say “first novice exercise”, HTML encode a UTF8 string. I mean, it is a single line of code in C# so how hard could it be in C? It’s not like that at all. The difference you’re identifying is that C# has it in the standard library while C does not. But it’s a conceptually intricate problem and implementing it from scratch in both C and C# would actually be somewhat similar, but C# obviously has some convenience features that would make the code tighter. Linked lists are very simple and GP’s complaint is that Rust makes it very difficult to implement them.
  - LeFantome 3y ago
    The difference is that both C and C# let you use pointers and make it your responsibility to use them correctly. C# provides the facilities, both in the naked language and in the standard library to not need pointers whereas you need to use pointers to do even trivial tasks and so the standard library makes extensive use of them. Pointers are a core language feature of C so obviously it is trivial to make use of them ( though not at all trivial to use them safely ). Rust’s core principle is that unsafe memory access should be prevented at the language level. Unsurprisingly, a data structure completely reliant on potentially unsafe use of memory will be difficult to implement. Both C# and Rust include features in their standard libraries so that implementing your own linked lists is unnecessary precisely because you are not supposed to. This is “non-idiomatic” as they say. C does not include linked lists in the standard library because this is exactly the kind of data structure you are meant to create when needed as the language makes it completely trivial to implement them. In C, a linked list is completely idiomatic and many, many C projects use them. If you write an OS in C, you will almost certainly create a linked list structure. Linux did. If you write an OS in Rust, you do not need to do that.
zozbot234 3y ago
You can do it safely by importing a ghost-cell crate. That particular pattern is not yet part of the Rust standard library because it comes in so many varieties, and it's not yet clear how to best support it in the language. But I assume it will get there at some point.
spease 3y ago
> Fun Rust novice exercise: Write a linked list implementation in Rust. struct LLItem<T> { next: Option<Box<LLItem<T>>>, value: T }

speed_spread 3y ago

Fun C exercice: write a linked list impl that's guaranteed leak free, thread safe and type safe at compile time. Good luck!

olliej 3y ago
[edit: oliver used wall of text. Was it effective?] No need to get defensive, no one is arguing that rust doesn’t do a lot of things well. They’re saying that a lot of the restrictions makes things much harder than other languages. Hence the general problem rust has where a lot of trivial tasks in other languages are extremely challenging. The fact that these things are much harder in rust due to design decisions in the language to ensure that everything is guaranteed to be safe in all cases does not change that the language can be harder to use. You’re talking up getting a safe implementation in C, but what matters is “can I get the same level of safety with less complexity in any language”, and the answer is yes: Java and c# implementations of a thread safe linked list are trivial. If I wanted I could do it in c++ though the complexity would be more than c# and Java it would be easier than rust. We know that rust makes some things more complicated than other languages for the same level of safety plans correctness, but that’s ok because complexity is a trade off. Rust has increased complexity of some “simpler” things to reduce the overall complexity of larger systems. This is an ok choice. But it is still a trade off, and part that trade off does make some things harder. People can point that out without it being an attack on the language.
- spease 3y ago
  > They’re saying that a lot of the restrictions makes things much harder than other languages. Hence the general problem rust has where a lot of trivial tasks in other languages are extremely challenging. Like what? So far the discussion has revolved around rewriting a linked list, which people generally shouldn't ever need to do because it's included in the standard lib for most languages. And it's a decidedly nontrivial task to do as well as the standard lib when you don't sacrifice runtime overhead to be able to handwave object lifecycle management. - C++: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_list.h https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-... - Rust: https://doc.rust-lang.org/beta/src/alloc/collections/linked_list.rs.html https://doc.rust-lang.org/beta/src/alloc/collections/linked_... > No need to get defensive, no one is arguing that rust doesn’t do a lot of things well. That's literally what bsaul is arguing in another comment. :) > You’re talking up getting a safe implementation in C, but what matters is “can I get the same level of safety with less complexity in any language”, and the answer is yes: Java and c# implementations of a thread safe linked list are trivial. Less perceived complexity. In Java and C# you're delegating the responsibility of lifecycle management to garbage collectors. For small to medium scale web apps, the added complexity will be under the hood and you won't have to worry about it. For extreme use cases, the behavior and overhead of the garbage collector does became relevant. If you factor in the code for the garbage collector that Java and C# depend on, the code complexity will tilt dramatically in favor of C++ or Rust. However, it's going to be non-idiomatic to rewrite a garbage collector in Java or C# like it is to rewrite a linked list in Rust. If we consider the languages as they're actually used, rather than an academic scenario which mostly crops up when people expect the language to behave like C or Java, the comparison is a lot more favorable than you're framing it as. > If I wanted I could do it in c++ though the complexity would be more than c# and Java it would be easier than rust. You can certainly write a thread-safe linked list in C++, but then the enforcement of any assumptions you made about using it will be a manual burden on the user. This isn't just a design problem you can solve with more code - C++ is incapable of expressing the same restrictions as Rust, because doing so would break compatibility with C++ code and the language constructs needed to do so don't exist. So it's somewhat apples and oranges here. Yes, you may have provided your team with a linked list, but it will either (1) Perform less efficiently, due to needing the GC to check whether to free things (2) Require more expertise to use safely, due to C++ being incapable of expressing constraints > Rust has increased complexity of some “simpler” things to reduce the overall complexity of larger systems. This is an ok choice. This is sort of right and sort of not. In the context of Java and C#, Rust hasn't "increased complexity", it makes it explicit rather than paying runtime cost to try and hide it. In the context of C++, Rust hasn't "increased complexity" either, it makes it mandatory to deal with things that C++ lets slide. I'd look it more as Rust requires a higher degree of confidence in the code. Rust is more likely to take the programmer to task about "What did you mean?" or "Are you sure about that?". It's like doing a code review with an extremely pedantic developer. As a product of this, the performance is better because the programmer has pre-answered questions which would otherwise need to be disambiguated by a garbage collector at runtime. The less ambiguous behavior makes it faster to integrate modules, because the compiler can point out discrepancies between what the code owner said they expected and how something is being used by itself. But it's not like Rust added that complexity - it was always there. C++, C#, and Java just let you ignore at the risk of adversely affecting software stability or performance, respectively.
  - soulbadguy 3y ago
    You seem to be mixing "designing" a linked list and just implementing a known design. > which people generally shouldn't ever need Agree! However, we can still use the implementation of a "reasonable" linked list a good yard stick to measure things across languages since it usually involves a good coverage of basic language features (like collection, traversal, life time management etc... etc...). Also, looking at the rust implementation of the linkedList you linked, we do have the magic unsafe keyword somewhere in there... which negate a lot of your argument have probable safety. > Less perceived complexity. This a seems very strange thing to say. Isn't reducing perceived complexity the name of the game in language design ? Reducing the complexity the dev have to carry in their mind by moving some of the decision to the toolchain is in my option a very valid approach. > In Java and C# you're delegating the responsibility of lifecycle management to garbage collectors. For small to medium scale web apps, the added complexity will be under the hood and you won't have to worry about it. > For extreme use cases, the behavior and overhead of the garbage collector does became relevant. First, designing for non extreme case is a valid approach in language design. Make the common case dead easy, and for complicated/rare case, provide API and customization points. In .Net/Java it is possible (also not always easy) to beat the GC into submission. Second, i think the comment about GC not being adequate for large scale web app is very 1990.New garbage collectors are able to manage those use case easily. A lot of the largest backend are in java. > If you factor in the code for the garbage collector that Java and C# depend on, the code complexity will tilt dramatically in favor of C++ or Rust. Why would you factor the code of the garbage collector in the equation... > However, it's going to be non-idiomatic to rewrite a garbage collector in Java or C# We are not talking about idiomatic vs non idiomatic. We are talking about simple and not simple. Writing GC friendly code in Java (even better in C# in my opinions with Structs) is still relatively simple and clean. > You can certainly write a thread-safe linked list in C++, but then the enforcement of any assumptions you made about using it will be a manual burden on the user. This isn't just a design problem you can solve with more code - C++ is incapable of expressing the same restrictions as Rust, because doing so would break compatibility with C++ code and the language constructs needed to do so don't exist. The unsafe keyword in the implementation pretty much negate all of this... > Yes, you may have provided your team with a linked list, but it will either (1) Perform less efficiently, due to needing the GC to check whether to free things (2) Require more expertise to use safely, due to C++ being incapable of expressing constraints 1) is a very strong statement, GC code can perform better than manual memory management, and does in a lot very real case. GC vs non GC is not about performance or efficiency, it's about control. Do you want to do it, or do you want the system to do it. The best parallel is register allocation : can you do a better job than the compiler in some case ? maybe. But in average (especially when you had things like x-function register allocation) in most case the compiler beats every dev except the top 5%. > In the context of Java and C#, Rust hasn't "increased complexity", it makes it explicit rather than paying runtime cost to try and hide it. In the context of C++, Rust hasn't "increased complexity" either, it makes it mandatory to deal with things that C++ lets slide. Making it explicit is increasing the complexity... > it makes it mandatory to deal with things that C++ lets slide. And thus making it "harder" to produce the same code... > But it's not like Rust added that complexity - it was always there. C++, C#, and Java just let you ignore at the risk of adversely affecting software stability or performance, respectively. I don't have a nice way to say it, just gonna say it : This is what fanboyism sounds like. C++/Rust and java are different point in the language design point. Now they are not perfect, as in it might be posssible that for each their respective domain, we can with the benefit of hindsight design something that works better. But to think that rust magically found a point in that design space which doesn't also add another sets of compromise is not realistic.

LeFantome 3y ago

I am sure you know enough about Rust to know that writing a linked list in Rust is not a “novice exercise”. It is also not something you require to use the language. This is like a C# dev trolling a C developer by say “first novice exercise”, HTML encode a UTF8 string. I mean, it is a single line of code in C# so how hard could it be in C? Or, it is like a C dev telling a Java programmer that their “first novice exercise” should be to write a fixed binary layout to a device driver or even just to call directly into an OS system call. Both are trivial in C after all. How about using a hash table for something though? Reasonably big job in C but new HashMap in Java. Rust is designed to prevent exactly the kind of thing you do to create a linked list and it is designed to make it difficult for a good reason. It is a cherry picked example meant to sound smart but, in reality, it is an eye-rollingly dumb thing to say. In DOS, I can write a program to dynamically overwrite and extend the behaviour of the operating system in RAM. In Linux, I cannot easily do that. I guess that means DOS is more advanced? To me, this sounds like the argument you are making about Rust. I do it care which language people like. There are pros and cons of each and legit arguments on use one over the other. Why not use one of the valid arguments instead of dumb gotcha comments that only tell us the languages are different and not which one is better.

appleskeptic 3y ago
>This is like a C# dev trolling a C developer by say “first novice exercise”, HTML encode a UTF8 string. I mean, it is a single line of code in C# so how hard could it be in C? It’s not like that at all. The difference you’re identifying is that C# has it in the standard library while C does not. But it’s a conceptually intricate problem and implementing it from scratch in both C and C# would actually be somewhat similar, but C# obviously has some convenience features that would make the code tighter. Linked lists are very simple and GP’s complaint is that Rust makes it very difficult to implement them.
- LeFantome 3y ago
  The difference is that both C and C# let you use pointers and make it your responsibility to use them correctly. C# provides the facilities, both in the naked language and in the standard library to not need pointers whereas you need to use pointers to do even trivial tasks and so the standard library makes extensive use of them. Pointers are a core language feature of C so obviously it is trivial to make use of them ( though not at all trivial to use them safely ). Rust’s core principle is that unsafe memory access should be prevented at the language level. Unsurprisingly, a data structure completely reliant on potentially unsafe use of memory will be difficult to implement. Both C# and Rust include features in their standard libraries so that implementing your own linked lists is unnecessary precisely because you are not supposed to. This is “non-idiomatic” as they say. C does not include linked lists in the standard library because this is exactly the kind of data structure you are meant to create when needed as the language makes it completely trivial to implement them. In C, a linked list is completely idiomatic and many, many C projects use them. If you write an OS in C, you will almost certainly create a linked list structure. Linux did. If you write an OS in Rust, you do not need to do that.

zozbot234 3y ago

You can do it safely by importing a ghost-cell crate. That particular pattern is not yet part of the Rust standard library because it comes in so many varieties, and it's not yet clear how to best support it in the language. But I assume it will get there at some point.

spease 3y ago

> Fun Rust novice exercise: Write a linked list implementation in Rust. struct LLItem<T> { next: Option<Box<LLItem<T>>>, value: T }