201–210 of 283 posts
Earlier quoted context omitted.
C/C++ developers can't use Rust without learning new concepts . That's not a failure. If there were no new concepts, then there wouldn't be any point in the langauge in the first place.
Contrariwise there is huge demand for a language with a trimmed-down set of concepts from C++ and a much improved syntax.
I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has? Step forth priests of Rust! As for me: I use C++ at my job daily but have never done Rust so I cannot compare. What I do know about is "memory safety" in C++, and to be hon…
> I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has? Hello. :-) I started writing C++ around 1992, and was lead programmer on various C++ production systems from 2002 until 2011. I worked with valgrind, unit tests, and boos…
That's exactly the kind of c++ code you probably don't have to refactor/move to another language at all
Earlier quoted context omitted.
> you are making a mistake that in C++ would have bitten you down the line. Taking some C++ code from an explorative phase that "usually works kinda ok" to something seaworthy requires, in my experience, a huge amount of work (which usually neglects a few issues that will bite you later regardless). I'm not so sure the (probably) faster exploration in C++ compensates for this compared to more "strict" languages like…
I found that strict compile time checks speed up my exploratory phase. That's because the type system provide an even tighter feedback loop than a REPL, and effectively cuts down the search space. Other people seem to have experienced the opposite, though. I have no idea why.
My hypothesis is a software growth, like a business or an economy, is fueled by debt. We create technical debts, both deliberately and accidentally, to write software faster. And when the software proves itself as a viable project, we could (ideally) start paying the debt. Rust forces users pay certain kinds of debt upfront that makes Rust attractive for rewriting, but I don't think it's that much attractive for gree…
Wut? Piston, actix, Amazon Firecracker, Alacritty, Xi, the list goes 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…
> 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…
If the coder's C++, that is written in flow without being distracted by borrow-checkers and whatnot, is in fact correct code, then no, there is no solution that is being ignored; what's being ignored is a "problem in search of a solution".
> Or is anyone expecting that your memory corruption problems will magically cease because you write your same old memory allocation and access bugs in Rust instead of C or C++?
That's a pretty good executive summary of the Rust cheerleading.
In fact, what you describe is sometimes possible. For illustration, let's confine our attention to use-after-free bugs and memory leaks. If we make the free function do nothing, and stick in a garbage collector, then in fact you can write (some of) "your same old memory allocation and access bugs" yet they are mitigated.
Earlier quoted context omitted.
Interesting. I would be interested to know more details about what you worked on and with whom. This hasn't been my experience in any of the four jobs I've used Haskell at. I don't deny that Haskell leads to spaghetti code messes, unexpected runtime errors, and indecipherable crashes, but the Java that I've previously worked with and the Python I currently work with suffer from those to a degree greater by an order o…
It was first for a bank, later for a data analytics start-up, and then also for an education technology company. I had many skilled functional programmers on my team too, including a few people who had done work on GHC itself. I’ve also see code messes in many languages. It’s a business culture problem, has nothing to do with the language or paradigm. I’ll greatly dispute with about Python though. It has been a langu…
To give you a Python example, it encourages stuff like:
def send_email(recipients, contents):
if type(recipients) == str:
send_one_email(recipients, contents)
else:
for recipient in recipients:
send_one_email(recipient, contents)
send_email("tome", contents)
send_email(["tome", "mlthoughts2018"], contents)
send_email(u"tome", contents)
" When you implement an algorithm using C++, you can write it down without one second of pause, but you can’t do that in Rust. As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. " Yeah... On my last C++ project, one very productive co-worker kept disabling -Wall, etc., be…
Depending on the situation a write unsafe fast fix later maybe the more economic approach. Especially if the code is more exploratory, changes a lot and large parts will be finally discarded.
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…
> 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. Dunno about Rust specifically, but I have written a little Haskell, and a significant amount of OCaml. I found that the type system reduces my cognitive overhead, compared to looser languages like Python or Lua. The compiler is disciplined…
Likewise, with Rust it is a relief after Go. In Go interfaces are a massive part of the language and they can only be pointers, which means much of your programming experience holds mental overhead needed to frequently answer "is this variable safe? Can I access it, or might it be nil?".
There's definitely overhead in learning how to use the borrow checker, but I feel that's the same as any basic language features in any language. Once learned, I largely don't think of them, and I don't fear using variables or what is concurrently safe anymore.
Doing game dev and digital content creation in anything but C++ and some python is simply a fool's errand. Any decent software in this area needs to use libraries written in C++ to have even a remote chance of being successful. These libraries are often written in ways that makes wrapping them for other languages impossible or at least force the exclusion of some desirable features in the bindings. In other words, C+…
Modern C++ is "good enough" where you'll potentially end up with some unsafe code but unless you're writing an SSL library it'll be OK.
Earlier quoted context omitted.
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.
>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…
If we are talking about emulator, why not just make clear communication between CPU, RAM, and graphic device? Memory can be split into rows (e.g. by split_at()), so graphic device can take ownership of a single scan line at a time, leaving majority of the memory unlocked. We cannot avoid problem, but we can make scale of the problem much smaller by splitting memory into pages, so CPU can take ownership of pages, it works with right now, while graphical device can work with it own pages.