191–200 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.
Earlier quoted context omitted.
I worked professionally in Haskell for a long time and I cannot disagree with you more. This is always the promise of strict functional languages but in a business setting where the very nature of what you build has to be arbitrarily mutable at the whim of competing interests between stakeholders, engineers, customers, etc., it just doesn’t work. You end up with the same spaghetti code messes, unexpected runtime erro…
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…
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 language that facilitates notably cleaner and more extensible implementations in my experience. Seen messes in Python too, but absolutely no way it’s “an order of magnitude” worse. That’s simply ridiculous. The only way that’s happening is if the programmers are exceptionally bad to the extent that it would not matter which language they used.
Earlier quoted context omitted.
I never met a GC that can deal with millions of allocations per second while having several millions of objects in the young generations. Some mesh processing algorithms have a tendency to get you there very quickly if you do not employ custom allocators. At this point you already defeated the GC provided by the language.
You would have to be dealing with a very large number of meshes at once, if you were churning through millions of vertex and uv arrays per second. I can't say what you should use in this scneario. But this is a pretty niche scenario! And you would probably want to focus on parallelism, where C++ again is not the best.
Here again, this is wrong.
99% of highly scalable parallel code that run on supercomputers is C++ or Fortran.
And there is reasons to that, if you want parallelism, you want generally performance. If you want performance you want control on NUMA, SIMD, cache locality, etc... and C++ gives you that. Not Java.
...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.
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…
Rust ensures that all valid rust programs are safe, but this does not mean that programs that are difficult to express in rust are unsafe.
Consider how future improvements to rust may make some previously difficult to express patterns easier. I think non-lexical lifetimes would be one such example. You could imagine that someone who learned on a future version of rust might be similarly annoyed at compiler errors when working with an old version of rust that's more limited in what things can be expressed and understood as safe.
Earlier quoted context omitted.
> You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community. Having read those comments, many of them can be best characterized as politely dismissive, e.g. from the top rated comment " If the author is more comfortable writing this code in C++ it makes sense to use it, but I feel like there is a long way to go to make…
How would you describe the trade-off between safety and the developer productivity listed as the reason in the article? The comment seems to just be saying that it’s reasonable for someone to make this trade off when they are more knowledgeable and familiar with one language rather than another. I think your reading quite a bit into that comment to take it as elitist.
"... there is a long way to go to make this code "safe" regardless of language." and "...values developer efficiency over ... correctness ..." are somewhat uncomplimentary additions to their main points, no matter how you look at it.
Earlier quoted context omitted.
> capacity to change Good luck making changes to a 100kloc Python codebase.
I do something similar daily, and it works fine, as we have a strong test suite. You can't disassociate dynamically typed languages from (strong) test suites, so one needs to qualify: > Good luck making changes to a 100kloc Python codebase without test suite versus > Good luck making changes to a 100kloc Python codebase with a good test suite In context, the first case is no different from "Good lucking making change…
It's not the same. Type system provides certain guarantees. Also it's much harder to write spaghetti code in Rust.
Earlier quoted context omitted.
My counter argument is nicely summed up by The Problem With Single-threaded Shared Mutability ( https://manishearth.github.io/blog/2015/05/17/the-problem-wi... )
I like the blog post, and I mostly agree with you that shared mutability can cause problems in big programs. It's something I try to keep to a minimum in most code I write, and I'm better at avoiding it after learning rust. The thing is, getting rid of shared mutable state entirely is a huge paradigm shift. It means many libraries (GUI libs especially) can't be cleanly wrapped. It means throwing away common data stru…
I mean you could imagine a hypothetical future scenario where it is demonstrated that the optimizers are good enough to essentially eliminate the run-time cost of RefCell wrappers, and a lot of Rust programmers just start wrapping everything with RefCells by default.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#exclusive-w...
" 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…
Until, you natively start thinking and writing code with idioms that the borrow checker is tuned for, there will be friction.