5 ms·

When someone defends use of Electron they usually say it helps productivity so much, that the application would not be created if it would have to be done with

by hawski 4y ago

When someone defends use of Electron they usually say it helps productivity so much, that the application would not be created if it would have to be done with a more conservative technology stack. I like to write my personal projects using C. I feel that I wouldn't have motivation to work on them if I would use Rust. I do see many shortcomings of C, I see a lot of advantages of Rust. It is always a game of trade offs. Safety/correctness, speed of development, performance of applications. It all depends on many factors, familiarity being one of them. Lately I am thinking if it is possible to write in a subset of Rust, that would essentially be C-with-Borrow-Checker. Not using most of stdlib and very limited set of libraries. I also look at all those Better-C languages and do hope for their maturity: Zig, Odin, Hare etc.

still_grokking 4y ago
> It is always a game of trade offs. Safety/correctness, speed of development, […] Where's the trade-off? If the result is buggy crap and/or a security nightmare it makes no difference whether it was "fast to develop". Saying something like that is like saying that you could build houses much faster if you just didn't have to follow any safety regulations. If you would try that in the real world you would end up in jail sooner or later. But in the virtual world of software people really seem to think that such an "argument" is valid. I'm eagerly looking forward to the EU finally (and hopefully soon!) removing the liability exceptions that are still in place for software. It's in the working. Than software products would fall under the same liability laws than any other products, and vendors going to be finally full responsible for what they ship to customers. The whole "I don't care about safety and correctness because there are no consequences" madness would come to a very abrupt end in case vendors would be liable and could end up in court easy for shipping subpar products that were manufactured not adhering to state of the art practices. > […] performance of applications. Rust and C are the same in this regard. So no "trade-offs" here.
pitaj 4y ago
Have you learned Rust or used it for any significant project? In my opinion: - Rust is more productive than C - Rust is easier than C, once you get past the initial bump And it's not my opinion, it's just fact that Rust has practically the same performance as C. I say this as someone who is currently actively maintaining embedded firmware with 10,000+ lines of C. It will be my last significant C project.
- idealmedtech 4y ago
  In my experience, the limitations imposed by the borrow checker actually make you express your ideas more clearly. In this way, you might be fighting the compiler, but when your code does compile, it usually does what you wanted it to (and is also designed in a much better way, since you're forced not to take the easy way to the finish line).
- bsder 4y ago
  Rust is a replacement for C++ not C. Rust macros are a disaster. The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin). #![nostd] still doesn't handle alternate memory allocators all that well. My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity.
  - pitaj 4y ago
    > Rust is a replacement for C++ not C. I disagree. We're finding that it's a great replacement for C++, C, C#, and Java. It even fits to replace or compliment scripting languages like JavaScript, Python, Ruby, etc. > Rust macros are a disaster. Better than C macros or no macros at all. Could it be better? Certainly. However, I don't think that Zig comptime is capable of the very important things that Rust macros enable. > The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin). Actually, I consider Pin as a triumph of the Rust way. By adding a simple rule (do not move this) you get enable a bunch of useful properties. And it only affects things which need it. It requires some understanding of you're working with it in unsafe territory, but the API surface keeps things safe for the average user. > #![nostd] still doesn't handle alternate memory allocators all that well. I don't know enough about it to say otherwise. > My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity. All of your problems with Rust are being worked on. Most of the missing features and pain points I see bright up are really just cases where the language hasn't filled the whole multidimensional space where orthogonal features interact. Based on pace of development, you might see Rust fill out before Zig or especially D fulfill your dreams. Especially if you want actual memory safety.

by hawski 4y ago

still_grokking 4y ago

> It is always a game of trade offs. Safety/correctness, speed of development, […] Where's the trade-off? If the result is buggy crap and/or a security nightmare it makes no difference whether it was "fast to develop". Saying something like that is like saying that you could build houses much faster if you just didn't have to follow any safety regulations. If you would try that in the real world you would end up in jail sooner or later. But in the virtual world of software people really seem to think that such an "argument" is valid. I'm eagerly looking forward to the EU finally (and hopefully soon!) removing the liability exceptions that are still in place for software. It's in the working. Than software products would fall under the same liability laws than any other products, and vendors going to be finally full responsible for what they ship to customers. The whole "I don't care about safety and correctness because there are no consequences" madness would come to a very abrupt end in case vendors would be liable and could end up in court easy for shipping subpar products that were manufactured not adhering to state of the art practices. > […] performance of applications. Rust and C are the same in this regard. So no "trade-offs" here.

pitaj 4y ago

Have you learned Rust or used it for any significant project? In my opinion: - Rust is more productive than C - Rust is easier than C, once you get past the initial bump And it's not my opinion, it's just fact that Rust has practically the same performance as C. I say this as someone who is currently actively maintaining embedded firmware with 10,000+ lines of C. It will be my last significant C project.

idealmedtech 4y ago
In my experience, the limitations imposed by the borrow checker actually make you express your ideas more clearly. In this way, you might be fighting the compiler, but when your code does compile, it usually does what you wanted it to (and is also designed in a much better way, since you're forced not to take the easy way to the finish line).
bsder 4y ago
Rust is a replacement for C++ not C. Rust macros are a disaster. The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin). #![nostd] still doesn't handle alternate memory allocators all that well. My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity.
- pitaj 4y ago
  > Rust is a replacement for C++ not C. I disagree. We're finding that it's a great replacement for C++, C, C#, and Java. It even fits to replace or compliment scripting languages like JavaScript, Python, Ruby, etc. > Rust macros are a disaster. Better than C macros or no macros at all. Could it be better? Certainly. However, I don't think that Zig comptime is capable of the very important things that Rust macros enable. > The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin). Actually, I consider Pin as a triumph of the Rust way. By adding a simple rule (do not move this) you get enable a bunch of useful properties. And it only affects things which need it. It requires some understanding of you're working with it in unsafe territory, but the API surface keeps things safe for the average user. > #![nostd] still doesn't handle alternate memory allocators all that well. I don't know enough about it to say otherwise. > My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity. All of your problems with Rust are being worked on. Most of the missing features and pain points I see bright up are really just cases where the language hasn't filled the whole multidimensional space where orthogonal features interact. Based on pace of development, you might see Rust fill out before Zig or especially D fulfill your dreams. Especially if you want actual memory safety.