5 ms·
I have done lots big corp projects, and came to accept the fact that using async I/O or reactive streams or whatever technology it is that is currently en vogue
by MrBuddyCasino 5y ago
I have done lots big corp projects, and came to accept the fact that using async I/O or reactive streams or whatever technology it is that is currently en vogue is only very loosely related to actual requirements, because lets be honest those are pointless for an internal backend with at most 10 concurrent connections. This is usually due to two factors:
- people lack understanding of fundamentals, thus buying into the hype, and are bad at weighing the trade-offs because they often can't see the downsides, especially regarding complexity
- engineers are curious and want to play with $latest_tech, and then construct a post-hoc justification for it to which they are sometimes unaware themselves
Or put differently, its either incompetence or mismatched incentives (principal-agent problem). There is some justification for playing with new tech as in "it helps motivation and retains talent", but sometimes the resulting complexity is far out of proportion.
That being said, tech ecosystems have different cultures, and I can understand why Rust is the way it is. It attracts idealists that tolerate complexity in the pursuit of the optimal solution. They have already produced more useful software than eg Haskell, and this is ultimately the yardstick of success. Lets see how Zig will do in that regard.
- zozbot234 5y agoI'm not sure that tolerance for accidental complexity is all that idiomatic in Rust. Rust async is a lot less complex than what Go does under the hood. Rust as a whole is even less complex than C++, with essentially no loss in useful featureset.
- MrBuddyCasino 5y agoThe lang team is very careful in designing new features, and I agree that they don't introduce accidental complexity lightly. Rust is an impressive achievement and a step forward over C++.
- ibraheemdev 5y agoThat's a good overview similar to my experience. > those are pointless for an internal backend with at most 10 concurrent connections I'm also arguing that the benefit of async over threads at 10 _thousand_ concurrent connections is still unclear. Yes memory usage will be less, but memory is cheap. Context switching overhead may be less, but a lot of it is still there because of readiness-based I/O. We don't see new, high-scale systems built on blocking I/O perhaps not because they can't be, but because async has become the norm, at the cost of _a lot_ of complexity.
- the__alchemist 5y agoMy experience as well with embedded rust, in two areas: Async, and typestates. Typestates are popular in OSS embedded rust. The idea is that the compiler catches errors, and your program is safer. In practice, it leads to verbose type signatures, and inflexibility. I think the reasons for this are both the idealism you mentioned, and being used to build infrastructure, without applying to practical problems. (ie, the examples you'll see for these libs are "hello world" style, for a given peripheral.
- MrBuddyCasino 5y agoI like the RTIC programming model, but jesus christ the typestates for accessing peripherals etc are annoying. I agree they went overboard here.
- the__alchemist 5y agoThe typestates are in issue with the libs that implement them; not with RTIC directly.