4 ms·
I don't mind who downboted this but it would help me to learn why? It seems to me that this comment is making a valid point, if only in a strong tone.
by vtesucks 8y ago
I don't mind who downboted this but it would help me to learn why?
It seems to me that this comment is making a valid point, if only in a strong tone.
- dbrgn 8y agoProbably because of snippets like this one: "the idea of putting "Embedded" on the front page and trying to advertise Rust as a useful embedded language isn't just laughable--it's dangerous. Rust is so far from useful in embedded that people who try to use it will NEVER come back" Embedded is still at its early development stages, just like WASM and just like asynchronous network programming. Still, all those are on the front page. WASM a year ago and wasm todays is a tremendous difference. A year ago, in my opinion, WASM was something for experimentation. Now, a lot of the ecosystem "just works" and is developing really quickly. You can write a working JS library and upload it to NPM without even touching a line of JavaScript code. Async (network) programming in Rust with async/await is promising but still in flux, so the ecosystem hasn't settled yet. Still, a lot of systems already use it in production. Embedded in Rust a year ago was mostly a list of blogposts, an early draft of HAL traits and some random register binding crates. You had to use nightly, and your code would frequently break. But in just a few weeks, you'll be able to use Embedded on stable, there is an active ecosystem developing around svd2rust, groups like stm-rs and lpc-rs are forming and a lot of device agnostic drivers have already been written. Combine that with a very promising preview of a new version of the RTFM framework. It's not production ready yet, but I'd estimate it will be within 2 years. See https://github.com/rust-embedded/awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust for a summary of the ecosystem. The problem with the post above is not that it's written in a strong tone. It's that it's uninformed, generalizing and unfair.
- bsder 8y ago> Embedded is still at its early development stages, just like WASM and just like asynchronous network programming. Still, all those are on the front page. That is more an indictment of WASM and asynchronous network programming than a vote of confidence for embedded... And I avoided commenting about things other than embedded explicitly because I don't have any background to judge those. > It's that it's uninformed, generalizing and unfair. You claim this statement is the problem: "the idea of putting "Embedded" on the front page and trying to advertise Rust as a useful embedded language isn't just laughable--it's dangerous. Rust is so far from useful in embedded that people who try to use it will NEVER come back" and then follow it with: "But in just a few weeks, you'll be able to use Embedded on stable" "It's not production ready yet, but I'd estimate it will be within 2 years." Ummmmmm ... I think you just made my case for me. I pull a bunch of the embedded Rust stuff about every 4-6 months and build a "blinky". I have an intern try this about every 9 months--I have yet to have an intern make any meaningful progress without me holding their hand every step of the way. Those same interns pull down Keil and fire off a blinky in about 4-6 hours without my help. Boards with their own environments like Silicon Labs or NXP are generally faster--about 2-3 hours to blinky--but are more annoying when you have to do something outside the "flow". I'd argue that experience makes me quite specific and informed and my comments quite fair. Thanks. If you point an embedded engineer at the Rust embedded ecosystem to evaluate, he will hand you your head on a platter. Embedded is NOT ready and putting it on the front page is going to get you a reputation for half-assed-ness. The problem is that Rust is moving "slow and steady" in an era where everyone wants "growth hacking". Or, if I'm feeling particularly nasty and snarky, Rust "thought leaders" outside Mozilla are annoyed that Rust isn't providing the revenue opportunities for speaking and consulting that languages like Go and Swift do (like Rails used to). Rust honestly doesn't have a marketing problem. Most of the people I know who might benefit from Rust are tracking it--even up to VP of Engineering levels (oddly, Rust appears to be better regarded than you would expect)--however these people are doing hard-headed cost analyses and don't find Rust to be coming out on the winning side most of the time. The issue is simply that most of the current languages are entrenched for various reasons and moving them aside requires that you be demonstrably better--and that implies i's dotted and t's crossed. See Theo de Raadt about Rust in OpenBSD: https://marc.info/?l=openbsd-misc&m=151233345723889&w=2 https://marc.info/?l=openbsd-misc&m=151233345723889&w=2 What Rust really has is a completeness problem. The lack of completeness in Rust reminds me of Lisp quite a lot--lots of libraries at 70%, very little at 99%+. Every time I try to use Rust for a project, some library isn't up to scratch or requires some odd combination that demands nightly, has some weird showstopper bug that will be fixed "Real Soon Now(tm)" that has been extant for 24 months, etc. Fortunately, Mozilla needs Rust to be up to scratch for Firefox, so at least certain core things get driven to completeness. I can contrast Rust at 8 years old (and I'm being generous) to Python at 8 years old (sigh, I'm now a greybeard ... "Back in my day, sonny..." <shakes cane>) Rust isn't convincing me to throw any of my languages away in spite of the fact that I really hate C. Python at 8 years old was good enough for me to throw Perl 5 away at roughly the zenith of Perl 5's popularity--now that's completeness. I like Rust, but people need to get comfortable with the fact that Rust has a long, slow, unsexy road ahead of it.
- vtesucks 8y agoI have to agree with you. While rust definitely is making progress, wasting peoples time by telling them things are ready is not done.