51–60 of 192 posts
That said, I never want to see another rounding bug in financial statements that happened because some piece of code implicitly converted a string to a float and it kinda almost worked every time. To quote a cliche, I'm too old for that shit.
"Each method is defined on this Context type that carries some common state, and the methods tend to call one another." This is classically a problem of GUI systems, where you have a large number of interlinked on-screen objects constantly undergoing modification.
- wait for input
- a dispatcher take any input and turn it into a queue of model update actions
- pop queue to perform latest model updates.
- trigger a full tree rendering, passing the new model
- start again
So:
- the model is a dumb static data structure
- the dispatcher is the responsible for model updates and is a single entry point for the data flow
- the UI and the model don't know about each other
That what ELM, react and so on do now. Monodirectional MVC. It's hard to optimize the rendering though, but it's way easier to reason about when concurrency gets high.
Earlier quoted context omitted.
I work in probably what is considered one of the least "safe" languages: C++ The issues that Rust is supposed to help with are simply not what we spent time on. All the bugs reported are pretty much exclusively root caused to "business logic". From recent time I can recall only one that was a programming mistake and not architecture/business logic related. It was a missing break in a switch that already had some fall…
I've worked in a variety of languages, and returning to a c++ project recently I do see that we spend a lot more time thinking about how to write the code in a way that avoids problems. Meaning that there's a lot more architecturing required to reach a sane state. We have a sister product written in a dynamic language, and sometimes we have identical functionality. I've noticed that when a change is discussed, the c+…
Earlier quoted context omitted.
You mean the tale of someone rewriting a very complex and fiddly software from scratch, having it work great in production, and then using the ecosystem's great tooling to easily find and eliminate even more bugs than what the language already protected them from?
The thing they rewrote also worked great in production. And fuzzing originated in C / C++ tools and is available for them as well, probably more diverse and mature than what is available in Rust. The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. Which Rust evangelists find difficult to acknowledge b…
There are straw men and then there are straw man armies. This is probably the biggest one I've seen yet.
Earlier quoted context omitted.
Agree; this is not an issue that slows down my development or bughunts. You can get a long way towards safety without learning Rust. It's those rare cases that will get you. It's a trade-off; take the time to learn the language and deliver later, or just use what you already have to deliver a product now.[1] [1] During a Rust discussion some years back, when I was at a different company, on a specialised and large-is…
It probably depends on project type and how complex your ownership models are, but that doesn't really track with large projects having a majority of their CVEs be memory safety issues that are far less likely in Rust[1] (e.g., https://www.chromium.org/Home/chromium-security/memory-safet... ) [1] I say far less likely because obviously it's possible with unsafe Rust, but I've never had one happen, seen one happen in…
I skipped all the code and only read the text. I got to the point where it mentions that the language prevented them from storing a pointer to a stack object in a heap object, and that's really great, but boy oh boy, the code presented, and the error messages, where very difficult for me to grok even after the first few times...
It seems to me that the more sophisticated the safety a language provides is the more complex its error messages/code are. It would be so nice if we could solve both problems at the same time...
Earlier quoted context omitted.
The thing they rewrote also worked great in production. And fuzzing originated in C / C++ tools and is available for them as well, probably more diverse and mature than what is available in Rust. The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. Which Rust evangelists find difficult to acknowledge b…
What you said, although I would have probably phrased it less harshly :) But yes, my point was that there are a lot of enthusiastic articles about how Rust can prevent "whole classes of bugs", which mostly gloss over the fact that there are other classes of bugs that it doesn't prevent. Of course this doesn't mislead experienced developers, but I'm not so sure about novices or less technically inclined people.
That's nothing more than a technically-dressed version of whataboutism, isn't it? Or can you show other languages that do prevent those other unnamed classes of bugs?
Rust is undoubtedly a step forward in correctness, but boy, the article's code is so thick that for me, that I am a C++ programmer, is almost unreadable, especially for a quick reading... I skipped all the code and only read the text. I got to the point where it mentions that the language prevented them from storing a pointer to a stack object in a heap object, and that's really great, but boy oh boy, the code presen…
Reason being that you have to unlearn your paradigm before you’re able to learn the new paradigm; and it’s made slightly worse by giving the appearance of similarity (since certain concepts map directly, like flow control and loops).
Earlier quoted context omitted.
The thing they rewrote also worked great in production. And fuzzing originated in C / C++ tools and is available for them as well, probably more diverse and mature than what is available in Rust. The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. Which Rust evangelists find difficult to acknowledge b…
> The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. You know, I'm a Rust evangelist. And I can tell you, why I ignore logic bugs when trying to sell Rust. Rust can prevent some logic bugs if they break invariant you managed to encode or enforce in your types. But it is a difficult topic to dive in a…
But Rust does do that, match exhaustiveness, forcing the handling of errors and the type system enables things like CreuSAT [1] using creusot [2]
[1] https://news.ycombinator.com/item?id=31780128
[2] https://github.com/xldenis/creusot
> Creusot works by translating Rust code to WhyML, the verification and specification language of Why3. Users can then leverage the full power of Why3 to (semi)-automatically discharge the verification conditions!
Units of Measure, https://github.com/iliekturtles/uom
The base properties of the language enable things that can never be done in C++.
"Each method is defined on this Context type that carries some common state, and the methods tend to call one another." This is classically a problem of GUI systems, where you have a large number of interlinked on-screen objects constantly undergoing modification.
And hence the general recommendation of having a single direction in your input/render cycle: - wait for input - a dispatcher take any input and turn it into a queue of model update actions - pop queue to perform latest model updates. - trigger a full tree rendering, passing the new model - start again So: - the model is a dumb static data structure - the dispatcher is the responsible for model updates and is a singl…
I agree the Elm model makes it easy to reason about it.
Just because we pass "the state of the world" each time instead of mutating it, does not mean that we need a full tree rendering. That is an implementation detail.
We can update just the relevant part. If we think of it mostly as pure functions a lot of it is easier to memoize and — for same input — it is possible to return the same output straight away.