291–300 of 474 posts
Most of the C that I do these days is Arm Cortex-Mx work. Realtime cooperative multi-tasking using an RTOS on the bare metal. It seems like Rust would be a great option for that kind of work if the low-level ecosystem were complete enough.
I think if programming is to make progress as a field, then we need to develop a methodology for figuring out how to quantify the cost-benefit trade-offs around "engineering tragedies waiting to happen." The fact that we have all of these endless debates that resemble arguments about religion shows that we are missing some key processes and pieces of knowledge as a field. Instead of developing those, we still get enamored of nifty ideas. That's because we can't gather data and have productive discussions around costs.
There are significant emergent costs encountered when "programming in the large." A lot of these seem to be anti-synergistic with powerful language features and "nifty ideas." How do we quantify this? There are significant institutional risks encountered when maintaining applications over time spans longer than several years. There are hard to quantify costs associated with frequent short delays and lags in tools. There are difficult to quantify costs associated with the fragility of development environment setups. In my experience most of the cost of software development is embodied in these myriad "nickel and dime" packets, and that much of the religious-war arguing about programming languages is actually about those costs.
(For the record, I think Rust has a bunch of nifty ideas. I think they're going down the right track.)
Earlier quoted context omitted.
Hmm. Is it less transparent than vectors which use implicit run-time bounds-checks? Don't RefCells use implicit run-time checks? (Btw I don't know Rust very well, so feel free to correct me.) And what about the question mark operator for dealing with exceptions/errors? Isn't there a lot going on under the hood there? But yeah, I can understand the sentiment of wanting to minimize that kind of thing in a lot of cases.…
RefCell does use run-time checks; that's it's entire reason for existing. They're "implicit" in the sense that they're inside of the functions, but that's the job of calling the function, so. Question mark is roughly six lines of code, it's a match statement on Result, which has two cases.
edit: Or is that just looking too far ahead?
I have been anxious about using Rust as webserver. But so far there is no mature framework that I think can use. I had a look at few like mio and iron framework etc. It has no mature Websocket implementation or an http package mature enough to be used in production. I am looking forward to make an ultra efficient PubSub server that supports HTTP poll and Websockets. Hope my dream comes true :)
What about bare-metal options? Is there any development effort in that direction? Most of the C that I do these days is Arm Cortex-Mx work. Realtime cooperative multi-tasking using an RTOS on the bare metal. It seems like Rust would be a great option for that kind of work if the low-level ecosystem were complete enough.
Some osdev stuff still needs nightly, but there's been really great movement on tooling, with stuff like xargo, and https://github.com/rust-embedded/ is a group of people trying to work towards improving things generally by identifying common needs, etc.
Earlier quoted context omitted.
RefCell does use run-time checks; that's it's entire reason for existing. They're "implicit" in the sense that they're inside of the functions, but that's the job of calling the function, so. Question mark is roughly six lines of code, it's a match statement on Result, which has two cases.
So do you agree that Rust should remain a "high transparency" language? Do you have an opinion on a "high productivity"/"application level safety supporting" superset of the language? Rust seems to be creeping out of the system space and into the application space. Will/should Rust go out of its way to support application level programming? (By, among other things, facilitating enforcement of application level invari…
I think Rust is mostly about safety in the same way that skydiving is mostly about safety. Having safety features that you know you can rely on allows you to take risks that you normally wouldn't in order to accomplish some really awesome things. (I guess in this analogy C is a parachute that you have to open manually, while Rust is a parachute that always opens at exactly the right altitude, but isn't any heavier th…
Have you done much skydiving? I used to go three days a week, for a couple years, between 4-10 jumps a day at a place that had world class experts. My experience is that only beginning skydivers are constantly preaching safety. They go around (vocally) judging everything they see, and I think they do it because it alleviates their own fear. Instructors would teach safety, but really only to their own students. I thin…
Is that a bad thing? All programmers start as beginners, and if C is too painful to begin with then they'll learn via an easier language, and then comfortably spend their whole careers using those easier languages. If we want to expand the field of systems programmers organically, then we need to make tools that don't punish beginning programmers.
> They can feel safer looking down their nose at us dangerous C or C++ programmers.
What makes you feel like anyone's looking down their noses at you? Every language in history has been made to address the perceived flaws of some prior language. Safety is a crucial selling point for a huge chunk of people, and C and C++ have failed to appeal to this market. Just because safety isn't a priority for you doesn't mean that the people for whom it is a priority are suddenly pretentious.
Earlier quoted context omitted.
Maybe it will change in future. Currently slaps seems so hard that developers are still smarting and not producing code for production
We've been in production with Rust almost six months already. Couldn't be happier with the language. Works like a charm with our consumers.
Earlier quoted context omitted.
If only Go was useful in building closed source products. Google must not have gotten the memo about Rust yet.
Contrary to popular legend, Google is not particularly strong on Go use, and it's not "THE official language". It wasn't officially commissioned or officially adopted by Google to solve Google's coding problems as some believe. It was merely initiated by a small team in Google, as their proposal for solving Google-scale coding problems. And has never been mandatory for new Google projects etc. Go is ONE of the allowe…