5 ms·
What’s missing from Rust? I don’t care if you use C, but don’t pretend like there isn’t another option
by superb_dev 2y ago
What’s missing from Rust? I don’t care if you use C, but don’t pretend like there isn’t another option
- pico303 2y agoMy problem with Rust is that it’s a hammer, and every nail is memory safety. If I’m writing a TLS library or kernel module, yes, memory safety is paramount. But if I’m writing pretty much anything else, Rust isn’t worth the slog.
- superb_dev 2y agoHow is that a problem with rust? Like any language it's a tool with strengths and weaknesses. Don't use it when it doesn't make sense
- pico303 2y agoSorry, should have been clearer. I was thinking in the context of every online discussion I’ve run across around “Rust vs. any other language,” where the diehard Rustaceans insist that we should just rewrite everything in Rust. Totally agree with you: use the best tool for the job.
- JonChesterfield 2y agoSimplicity.
- deleted 2y ago[deleted]
- yetihehe 2y agoSimple | Fast | Safe. Choose two.
- jamesdhutton 2y agoExactly this. It's all about trade-offs. You need to pick the right tool for the job. Sometimes the right tool is dangerous. Knives are dangerous tools, but you need them if you want to cook a meal.
- yetihehe 2y agoI love one comparison to hole hawg[0] (used for unix vs windows&mac), which is usable here. Memory safe languages are like a fancy electric drill from target. They get the job done, but if you want some more serious drilling they die on you instead of doing something dangerous. C is like one of those drills which are comprised of engine and a handle (cheap, changeable piece of steel pipe). They are designed to do one thing: they rotate a drill. When drill blocks, they rotate you. But when you take appropriate precautions, boy do it drills... This is from my favourite book: In the beginning was the command line. [0] https://web.stanford.edu/class/cs81n/command.txt https://web.stanford.edu/class/cs81n/command.txt , search "HOLE HAWG".
- superb_dev 2y agoSo what are you able to do with C that you can’t do in Rust? Somethings are more difficult to pull off, but everything possible in C is possible in Rust. Worst comes to worst you can always drop into unsafe Rust This “sometimes you need a knife" argument just doesn’t make sense. You can have the power and the safety. Stop cutting off your fingers.
- yetihehe 2y agoMake a program for 8051 MCU. Or a lot of other microcontrollers. > This “sometimes you need a knife" argument just doesn’t make sense. You can have the power and the safety. Stop cutting off your fingers. Sometimes you need a scalpel. I'm not against Rust. I still want to start a project where Rust will be worth learning for me, but I'm currently busy writing erlang and java for big systems and C for microcontrollers. This is of course only my local situation, I don't advocate for those languages (I love erlang though and I'm wishing for advertised easy concurrency in Rust, maybe someday).
- relistan 2y agoThis. Learning Rust is like a long series of jousting matches with the compiler.
- superb_dev 2y agoHow is that different than learning any other language? I think Rust’s reputation for being hard to learn is overblown. Yes it is probably a little more esoteric than what you’re familiar with but any decent dev should be able to pick it up
- jiggawatts 2y agoThe alternative is jousting with attackers. In production. When you're not aware of it. You're not even on the field, let alone mounted on your horse and wearing armour.
- cornholio 2y agoIt's more than that. Even after you learn it, you will struggle a lot with productivity, especially fast iteration and incremental changes and fixes, as Rust forces you to redesign and refactor your code.
- superb_dev 2y agoWell computing has gotten a lot more complex since c’s inception. It’s model has held up well but the cracks are there
- JonChesterfield 2y agoPrograms are a lot more complex. The computers aren't. They were far less homogenous in the early years. Today you have a octet addressed little endian integer machine, with ieee float hardware and a small vector unit. Maybe you have two different instances of that on the same address space, but probably just one. I think reasonable argument could be made that the complexity in modern computing is primarily self inflicted by software engineers.
- superb_dev 2y agoComputers have gotten much more complex. Maybe your OS provides that nice little bubble for you, but it’s an illusion
- tialaramex 2y agoThis isn't a crazy thought to have about K&R C. They're trying to fit a high level language onto a 1970s computer and so sacrifices must be made. Some of the trades they make are... questionable and others I'd say clearly wrong (they just don't need Tony's billion dollar mistake, nor to be so cavalier with types in general), but it's not as though they're targeting a machine with gigabytes of RAM and a multi-core CPU. But, people aren't writing K&R C. These days most of them are writing something closer to C99 or C11 and some may be using something newer (e.g. C17) or proprietary (GNU's C dialect) either deliberately or just because it compiled and nobody told them not to. At that point you've actually given away much of the simplicity, and yet what you get for your trouble is largely more footguns. Trade up for a sound type system and fewer footguns instead.
- jstimpfle 2y agoWhat things simplicity do you lose? I think there isn't much of a difference between these dialects. Most important one might be possibility to define variables on the spot instead of at top of block. Then, some people like C99 compound literals. I don't think any of these break simplicity, they are quality-of-life improvements with no interactions with the rest of the language semantics. Next one is what, the C11 memory model? Doesn't take away any simplicity, just defines things better.
- JonChesterfield 2y agoK&R gets used as a shorthand for the "portable assembly" C that some people remember and others swear never existed. That's my guess at what the parent meant, not the syntactic strangeness of writing types after the parameter list. C11 atomics would have been much better if they'd standardised existing practice instead of inventing something based around the application centric design C++ was inventing. It's nice that there's an acquire/release scheme one can reason with but a real shame that they conflated it with type annotations.
- tialaramex 2y agoHere's my thinking. It's fair to say C99 isn't that much more complicated than C89, which formalizes various things that are a bad idea such as "volatile", as well as numerous good ideas like hey we should let you define a variable where you use the variable - however C99 adds more of the bad like "restrict". In both those cases the K&R C model was very simple. You could decide you love how simple this model is, and when smarter compilers optimise it into a pretzel or other languages are faster that's OK. This code used to drive the serial port, now it does nothing, OK, don't use C to write such drivers. This code used to go real fast, now everybody else is faster, OK, don't use C if you need the best performance. C89 and C99 choose different, making the language more complicated to keep addressing performance and compatibility. In C99 I can write the fast serial port driver, but it's significantly more complicated as a result. The beginner will definitely get it wrong and explaining why is pretty subtle. Then C11 says actually you're not writing sequential programs, which was a crucial simplification in K&R C - the programs you can write do one thing at a time, in order, and then maybe stop. The memory model in C11 is needed because it says actually your programs might do more or different things at once. Now, in reality by 2011 lots of people were writing C that's not actually sequential - after all SMP Linux long pre-dates C11. But those weren't legal C programs, they're GNU's dialect and so all bets are off. Nobody is claiming Linux is simple. So C11 definitely isn't the simple language for a 1970s computer any more. C11 is a competitor with C++ or today Rust. And it doesn't fare so well by that comparison.
- marcyb5st 2y agoWith all the language features I agree. However, if you reduce the language surface it is possible to have something safe and simple enough (IMHO). For instance, you can say no async, no custom traits and only {Debug, Display, Eq, PartialEq, ...} are allowed for your structs and generics. From limited personal experience that takes away more than half of the complexity of navigating rust code.
- jstimpfle 2y agoThe more you take away, the closer you are to a simple but unsafe language. If you remove the "unsafe" keyword, many things you can't solve easily nor optimally. You might be able to outsource some complexity to external libraries, but integrating libraries is itself a major headache, and it can lead to security issues too.
- marcyb5st 2y agoFair enough. But unsafe for kernel code I guess it's a necessary evil (that's why I didn't mention it). However, I believe the being "opt-in" by explicitly marking sections unsafe is the way to go instead of having unsafe by default (which is the only way using C).
- superb_dev 2y agoUnsafe is a daunting language feature, but ultimately it’s a feature. You’re meant to use it if you need it. You don’t need to outsource complexity anywhere. Rust is fully capable.
- wudangmonk 2y agoIf the borrow checker was optional and not baked into the language. If it compiled fast and not slower than c++. I might try it out if these two requirements were met. I have a mental model between what I write in C and what I can expect the assembly to be. Or maybe the problem is that we have the same stack for code and data? could that be it?.