131–140 of 283 posts
...hasn't Swift become a viable alternative in this space by now? I see it's getting used in ML a bit, and looks nicer than D and easier to learn than Rust.
Earlier quoted context omitted.
your final assertion implies that any new language that is a significant paradigm shift from c++ must be flawed.
I do qualify that I speak about languages that are still "Algol-derived". Rust is not some significant paradigm shift (like e.g. Scheme vs C vs Prolog vs Haskell, etc). It's the same concepts and programming styles as C, C++ etc, plus fighting the borrow checker.
Earlier quoted context omitted.
> The downside that the author points out seem to be often neglected. Constant interruption and battling with the type system during development, when mental overhead is a problem. This assertion is just wrong. The author makes it quite clear that he doesn't know the language and is still taking his first steps ( "I am still a Rust learner, not a veteran" ), he implies that has problems with correct memory management…
> However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems. Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code. Now it's applied to the other side (…
This statement is absurd. It implies that you believe that there are only cosmetic differences between languages, that no language can ever introduce any useful new concepts.
Rust is not hard to learn. However, it contains new things that require you to put in the time to learn them. None of those things are as hard as learning, say, recursion or assignment was when you did it the first time. However, unlike switching between other mainstream "algol-derived" languages, there are actual new things you have to learn. If you go into it just pretending it's a cosmetically different variant of C++, you are going to bang your head on every sharp corner until you quit in frustration.
And having those new concepts is the price of progress. The current programming paradigms are not sustainable in a world where basically every line of code you write is going to end up as a part of the attack surface of some system that will, eventually, get attacked.
1. You still have to fight with borrow checking in Rust as in C++, it’s just not automated. You have to consider moves and copies, borrowed references, etc. As the author points out, if you’re used to writing C or C++, it’s going to take a while before responding to the borrow checker is second nature. The point is that the borrow checker is a computer and doesn’t make mistakes the same way a human does, and that’s value added not detracted.
2. Having the benifit of actually having a package manager, Rust is much easier to download and use dependencies with. That said, I agree with the general premise of not using Rust if you have an immediate business need and it’s missing a core library. My issue is that it should be fairly apparent before you start a project what dependencies you need, so a rewrite back to C++ seems odd. Also, Rust is an open source ecosystem, and people using it should feel compelled to consider writing the missing pieces they need for the benifit of the community. It’s also odd to say that Rust doesn’t have what you need, it sounds like there are C libraries that already do what you want, and Rust can wrap C.
3. If something is written in C and you don’t have time to replace it, just wrap it in unsafe and make a safe interface over it. Rust is exceedingly good at interfacing with C, so any library you can use in C can potentially be used in Rust.
Earlier quoted context omitted.
I do qualify that I speak about languages that are still "Algol-derived". Rust is not some significant paradigm shift (like e.g. Scheme vs C vs Prolog vs Haskell, etc). It's the same concepts and programming styles as C, C++ etc, plus fighting the borrow checker.
Actually, a lot of the issues that C/C++ programmers have when they are new to Rust seem to be precisely because idiomatic Rust code (which can help to avoid borrow checker issues) is often in a more functional Scheme/OCaml style. Rust is both algol-derived, and ocaml-derived. And arguably the borrow checker creates a new paradigm entirely.
I don't think this can be emphasized enough. You can get deceivingly far in rust with an OOP style, only to come to the disheartening conclusion that it's impossible to do what you want with the architecture you spent months of work setting up.
For example, how would you architect a simple single threaded emulator? The CPU is an object, RAM is an object, easy enough. Okay, the CPU needs mutable access to RAM at all times, so we'll make the CPU own the RAM, sure why not? Okay now we want to implement a graphics device that can mutably access RAM, so we just...put the ram out on it's own and make it a Rc>?!? Now it takes three lines of code to unwrap all the smart pointers to write a single byte of memory?!? And it's slower because we have to pay for runtime borrow checking!
I went down exactly this road. I still use rust and love many things about it, but I've come to the conclusion that writing typical single threaded object oriented code in rust only looks like it works; it's an awful idea in practice.
I think the reason C++ people have so much trouble with rust is the syntax makes it easy to do the things you've always done, but the mysterious borrowchecker tells you no later on.
The first few comments here seem to argue against the article, as do comments below the post but I am very much with the author. I strongly disagree with the Rust mentality, and the general mentality of statically typed languages with extremely prohibitive compile time checks, that seem to become more common. Underlying that model seems to be a concept of software like a sort of renaissance master's marble statue, er…
If you want to build the best company, you might not care so much about these.
But then, not all of us are running businesses. And building your company on top of the best code isn't even a bad idea.
Three problems with this: 1. You still have to fight with borrow checking in Rust as in C++, it’s just not automated. You have to consider moves and copies, borrowed references, etc. As the author points out, if you’re used to writing C or C++, it’s going to take a while before responding to the borrow checker is second nature. The point is that the borrow checker is a computer and doesn’t make mistakes the same way…
It's not that easy. The borrow checker gives you memory safety and thread-safety. In C++, you always have to worry about memory safety, so here the ownership model and borrow checker is a pure win. However, in C++ you don't have to worry about thread safety in a single thread...there's no barrier to passing pointers around and mutating things from different places in your code. In rust, the borrowchecker disallows shared mutable state...that's a huge win if you want to parallelize your code later on, but it also means that things that are trivial in C++ take a lot of thought and effort in rust, especially if you're thinking in a C++ paradigm (as opposed to coming from a functional language).
Earlier quoted context omitted.
why would i use rust in the first place if i was disabling the borrow checker? isn't that the main selling point? because of the ecosystem? because it's easier to hire rust programmers than C/C++ programmers, or get more open source contributions from rust vs C/C++? unlikely with a learning curve or community like that.
Rust only disables these checks very selectively. The idea is good, MS did same in C# since the first version in 2002. Allows to do pointer arithmetic when you really need to, for performance or native interop. What I don’t like about Rust is they use unsafe to workaround language limitations. In C# I have only used unsafe code couple times over the course of 20 years. The standard library doesn’t use unsafe code eit…
In all my years with Rust, the only unsafe I’ve needed in any of my applications is when doing FFI, and my toy OS. YMMV.
Earlier quoted context omitted.
> However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems. Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code. Now it's applied to the other side (…
> I don't care if the author is a Rust expert or total newb. Someone who can write a 3D modeler in C++ is someone who should be able to use any new Algol-derived language with ease in short time, regardless if they hasn't seen a line of code in that language before. This statement is absurd. It implies that you believe that there are only cosmetic differences between languages, that no language can ever introduce any…
Then add knowledge of the ecosystem :)
Earlier quoted context omitted.
> The downside that the author points out seem to be often neglected. Constant interruption and battling with the type system during development, when mental overhead is a problem. This assertion is just wrong. The author makes it quite clear that he doesn't know the language and is still taking his first steps ( "I am still a Rust learner, not a veteran" ), he implies that has problems with correct memory management…
> However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems. Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code. Now it's applied to the other side (…
You've picked a very poor example to repeat that tired old addage. You're using an example of someone who admits struggling with memory management issues who has just started learning a programming language which he doesn't master, and after he grew tired of having the compiler warn him that he was writing broken code he decided to keep writing broken code but this time in a language which doesn't warn him about how broke his code is.
How exactly is this case anything other than someone not knowing how to use a programming language insisting on writing broken code?
I mean, the rationale of switching to another language was quitr clearly how the programmer grew tired of the compiler warning him he was making a series of mistakes, and he prefered keeping making the same mistakes without being bothered about pesky memory access problems.