[HN Gopher] Embedded Rust in Production?
___________________________________________________________________
Embedded Rust in Production?
Author : michidk
Score : 190 points
Date : 2024-10-14 06:06 UTC (16 hours ago)
(HTM) web link (blog.lohr.dev)
(TXT) w3m dump (blog.lohr.dev)
| bpbp-mango wrote:
| nice pop-up that scrolls you to the top of the article
| 6r17 wrote:
| I was using brave and did not see that popup
| sshine wrote:
| Reposted:
|
| 2024-02-20 (3 comments):
| https://news.ycombinator.com/item?id=39446699
|
| 2024-02-04 (0 comments):
| https://news.ycombinator.com/item?id=39251131
| baq wrote:
| As expected, the people problem is the biggest factor. Turns out
| getting C folks to learn Rust is a difficult proposition (hello,
| lkml) but the other way around it isn't too much of a problem.
|
| I wonder how much of it is low-level experienced developers only
| ever using C fail to see that C is not the universally best tool
| (or, 'if all you have is a hammer, everything looks like a nail'
| question).
| dunefox wrote:
| > I wonder how much of it is low-level experienced developers
| only ever using C fail to see that C is not the universally
| best tool
|
| I'd say that's it. From my own experience with software
| developers, convincing some of them to learn something new is
| practically impossible.
| marcyb5st wrote:
| I generally speaking agree, but I would be more specific:
|
| If the person in question has a true passion for the craft,
| you can regardless of the age/seniority of the developer (at
| least in my experience). In fact, learning something like a
| new programing language is a big undertaking and if your work
| doesn't offer incentives/rewards the will has to come from
| the person him/herself and so that's why the passion bit I
| mentioned above.
|
| In my experience I also notice that more senior/older devs
| are more reluctant to learn new things, but I am unsure if
| that's due having their passion destroyed by many years of
| bullshit companies politics, pointless meetings/trainings,
| and adherence to the latest flavor of agile development every
| quarter or simply an age thing (I'm not there yet and so I
| can't tell first hand).
| Lanolderen wrote:
| Would this not also be partially connected to not wanting
| to throw away your 15 years experience with C for 1 year
| experience in Rust assuming the company actually ditches C?
| (or any other direct replacement language/tool scenario)
|
| Sounds like a way to replace yourself by 2 low pay students
| who also have 1 year of Rust experience.
| nsteel wrote:
| I'm genuinely surprised there are Rust developers out
| there that don't know C. Perhaps I'm showing my age, or
| my ignorance to how much CS education (even self-taught)
| has changed.
| Lanolderen wrote:
| It's still thought but it's mostly a pointer course from
| my recent experience. It's a low credit subject where you
| play around with arrays and strings, maybe there will be
| an overflow calculation as well. Whereas something like
| Rust you'd do in a high credit course project where you
| have freedom over the tech stack and actually produce
| something with functionality.
|
| Edit: My point with the replacement is not that juniors
| don't/won't have C on their CV but that a manager would
| be more willing to replace an experienced dev with 1 year
| exp in the current tool with 2 worse devs also with 1
| year exp in the current tool compared to replacing an
| experienced dev with say 10 years of experience in the
| current tool with 2 worse devs with 1 year experience in
| the current tool.
| nsteel wrote:
| I understood (and agree) with your original point. My
| comment about not having C experience/knowledge came from
| the article, where it really did sound like just that.
| jcgrillo wrote:
| I studied physics, not CS, so I can't really speak to the
| CS curriculum part. But I am someone who has written rust
| professionally for a few years so I'll describe how I got
| there. I think the most experience I've ever had with C
| was writing a fourth order Runge-Kutta routine and
| calling it from python for a college project. Maybe 20
| lines of C? In industry for the first 5yr I wrote lots of
| python and java code for web APIs and "big data" systems.
| Simultaneously around 2015 I started getting interested
| in rust because it seemed interesting, and like it would
| probably play a big role in the next 20yr--memory safety
| without a garbage collector is inherently compelling if
| you've spent time trying to make java GC act right.
| Eventually I got a job which was a full time rust gig.
| After about 3 years of that I ended up in a golang shop.
| So I've written some tens of thousands of lines of rust
| and only a few lines of C. I read C, but it would take a
| while for me to get comfortable writing it. But I
| wouldn't, probably, because I can use rust instead.
| marcyb5st wrote:
| I honestly don't see as throwing it away.
|
| The more you know the better software engineer you are
| with everything else being equal (IMHO).
|
| Also, if you need to gradually add rust to an existing
| codebase the C knowledge is extremely valuable.
| sgu999 wrote:
| That's really just being a Luddite, I understand the
| mindset but that's a very poor strategy if one cares
| about job security. A (good!) senior developer has a ton
| of value outside of the pure mastery of a language specs,
| not to mention that learning a language for 1 year with
| 15 years of prior knowledge really doesn't lead to the
| same level as a student who does the same.
| netdevnet wrote:
| That kind of value only matters as long as you can find
| an ecosystem of companies that can be convinced to pay
| you what you think that value is worth. Many companies
| can't be convinced to do so and the companies that can
| are overflown by candidates smarter than you that have
| regular contributions in top rated github repos if they
| haven't made super popular frameworks and libraries
| wmil wrote:
| The big problem with learning new programming languages is
| that you're going to suck at it for years until you reach
| the same level of familiarity with the new one.
|
| Suck here is more of an emotional thing. They can output
| high quality code fairly quickly. The issue is not knowing
| all of the quirks of the language and all development being
| slower and more difficult.
|
| Dropping down to simpler tasks while learning the language
| is a huge ego blow.
| baq wrote:
| And this is where LLMs help tremendously: you know
| exactly what you want to do, you don't know how to do it
| specifically like it should be done in the language
| you're learning, you query the latent space of the
| internet using plain english and you get an answer.
|
| It was a good argument literally a couple years ago less
| a few weeks before the chatgpt first release. Nowadays
| it's basically a moot point.
| dunefox wrote:
| I'm surprised at how useful the latest openai model is
| for me when it comes to either learn a python library or
| a new language, such as cl, for example.
| netdevnet wrote:
| When you learn a language, you don't just learn how to
| use the syntax of that language idiomatically. You also
| need to learn to use the different tools in that
| ecosystem
| netdevnet wrote:
| It's a RoI. Are you just telling them to learn something new
| or are you explaining the benefits and costs of learning Rust
| when they could be learning X?
| lawn wrote:
| It's surprising because I personally jump at an opportunity
| to try something new.
|
| Well, with some exceptions...
| fulafel wrote:
| The complexity of Rust is on another level, it's a huge
| language.
| baq wrote:
| It's a tradeoff. The ownership rules are mostly the same as
| C. The difference is that Rust enforces them at compile time.
| fulafel wrote:
| Hrm. These are the top level Rust ownership rules according
| to the book[1]: Each value in Rust has an
| owner. There can only be one owner at a time.
| When the owner goes out of scope, the value will be
| dropped.
|
| C has none of these. Or borrowing, etc.
|
| [1] https://doc.rust-lang.org/book/ch04-01-what-is-
| ownership.htm...
| baq wrote:
| To get robust software out of C you don't have many
| options other than to adopt these rules. You can have
| useful software which breaks all of these, but you don't
| want to maintain it.
| throwawaymaths wrote:
| Robustness is relative. You can certainly write a cli
| that does everything in an arena; your GC is the OS and
| so going out of scope -- who cares. doing nothing and
| eliminating whole classes of errors from consideration
| (UAF e.g.) is incredibly maintainable.
|
| Or, as the old tale goes, your GC might be the software
| literally exploding (it's in an air to air missile)
| zifpanachr23 wrote:
| It's widespread practice to notate who owns what in the
| comments in C code. "Ownership" as a concept comes from
| well established C best practices and a good C developer
| is going to understand exactly what you mean if you say
| something like "Caller owns the memory returned from this
| function" etc.
| wyager wrote:
| Using pointers correctly and safely in C basically
| requires tracking pointer rules substantially similar to
| the rust pointer rules, but in your head. Most people who
| don't do this just write incorrect code, although it
| might only rarely cause a serious problem.
| whazor wrote:
| Getting Rust developers to become Embedded Engineers is very
| interesting. Since it is easier to learn Rust than it is to
| learn C.
| wyager wrote:
| I think writing broken C is easier than writing correct Rust
| is easier than writing correct C.
|
| A lot of C(++) devs just like that they can mostly get away
| with writing broken code
| bboygravity wrote:
| How much of the embedded jobs are Rust? Maybe 1 percent?
| ndiddy wrote:
| The article says that the author wanted to hire someone who
| knows both Rust and C to maintain his company's embedded
| projects, but was unwilling to hire a C developer and wait for
| them to learn Rust. I'm not sure how this supports your point.
| I would argue that it's more that most companies aren't willing
| to let their employees spend a significant amount of time
| learning new skills.
| RandomThoughts3 wrote:
| The article is really light on actual details.
|
| Basically, this is a company who uses ESP32 to read serial data
| from batteries using UART and retransmits it in json over MQTT.
| They apparently had buggy C code to do that (for unspecified
| reasons) and successfully rewrote that in Rust.
|
| Conclusion, you can write ESP32 code in Rust. No information on
| what that actually entails sadly.
| sgt wrote:
| Yes I wonder what was wrong with the C code. Was it fixable,
| was it just a single loop code that ran or could they have used
| something like FreeRTOS to handle multiple tasks with less
| chance of bugs?
| RandomThoughts3 wrote:
| I would have liked to have more details because it's easy to
| have memory related issues when using a serial protocol in a
| memory constrained environment and I was wondering if somehow
| some feature of Rust helped them.
|
| I would guess that the more expressive type system is very
| nice but I don't expect memory safery features to be that
| useful in this context. Would like to hear from someone with
| real world experience on that.
| lsllc wrote:
| If you're parsing a serial protocol on an embedded system
| where you're only getting a byte-at-a-time (from a
| register), or possibly up to 8 at a time, then a parser
| combinator library such as nom should make it very easy to
| create a bulletproof parser.
|
| Definitely much easier than in C, where I've resorted to
| using Ragel for safely parsing serial protocols (and also
| in Go!) since it generates a single small dependency free
| source file containing the state machine and your
| "actions", but nom is much more expressive.
| RandomThoughts3 wrote:
| Deeply doubt so.
|
| Parser combinators are notoriously poor performance and
| memory-wise. They are somewhat nice to write if you like
| the style and don't mind the tax but we are talking about
| ESP32 here.
|
| Unless they are inexperienced, the issue is unlikely to
| be the state machine anyway and more likely to be in how
| they manage buffering of long message to avoid running
| out of RAM.
| usmanmehmood55 wrote:
| I was just about to point this out in my own comment but yours
| sums it up quite nicely. As an embedded software guy this
| article gives next to no specifics or details on what the bugs
| were and how they got solved with Rust.
| whazor wrote:
| Some more information on ESP32 on Rust. Espressif (the
| organisation behind ESP32) spent effort to properly support
| Rust on their chips, see their documentation: https://docs.esp-
| rs.org/book/
|
| Another nice resource for Rust embedded is https://embassy.dev/
| which also supports STM32, Nordic chips, and RP2040.
|
| IMO, the coolest feature about Rust embedded is that Async Rust
| works! This makes building a HTTP server for your embedded chip
| easy.
| qazxcvbnmlp wrote:
| Most embedded code is pretty bad at async - that could be a
| game changer.
| marmaduke wrote:
| I'm doing some C on esp32 currently, and wondered about switching
| to rust, and I understand that simple cases with Rust are solid.
| I'm definitely interested in trying it out.
|
| However we need to work with a lot of the hardware apis like
| twai, ble, lte, ota, etc. It seems like support is spotty or it's
| DIY.
|
| It's also worth keeping mind the remark about developer
| availability. I can generally answer questions about the C to
| someone who's not experienced in C, while Rust might be another
| story.
| j-krieger wrote:
| > It seems like support is spotty or it's DIY
|
| I can somewhat attest to this! I have a pretty extensive
| prototype of using Rust on ESP32 in production. I wrote a
| reference implementation for ESP32 platforms deployed via
| BRSKI, a secure remote key bootstrapping protocol which builds
| upon attestation keys and public key infrastructure.
|
| I'm largely using `esp-idf-svc` for most things, which is a
| Rust-native wrapper around ESP-IDF code. For anything closer to
| the hardware, I'm using `esp-idf-sys` which is just a thin
| wrapper around the the `ESP-IDF` SDK.
|
| You can see the project here: https://github.com/hm-
| seclab/open-brski
|
| Hope this helps! I'm by no means an expert but I sometimes help
| contribute to the Rust ESP32 ecosystem, so ask away if you want
| :)
| marmaduke wrote:
| Hi! Thanks for your reply. First time hearing about Brski,
| I'll have a look
|
| I guess your takeaway is that despite spotty support, the
| benefits of rust are net positive? I guess learning to call C
| from Rust is gonna be part of it too right ?
| dazzawazza wrote:
| Access to competant Rust developers can be a challenge even for
| large companies.
|
| I recently finished a contract at a (very large game dev) company
| where some tools were written in Rust. The tools were a re-write
| of python scripts and added no new functionality but were
| slightly faster in Rust.
|
| The reality was that these tools were unmaintainable by the rest
| of the company. Only the author "knew" Rust and it was hard to
| justify a new hire Rust developer to maintain this small set of
| tools.
|
| The only reason these tools were written in Rust was because the
| dev wanted to learn Rust (a big but common mistake). I pointed
| out to the Technical Director that this was a big mistake and the
| teams had taken on a large amount of technical debt for no reason
| other than the ego of the wanna-be-rust-developer. Since I "knew"
| Rust he wanted me to maintain it. My advice was to go back to the
| Python scripts and I left.
| meindnoch wrote:
| >Only the author "knew" Rust [...] because the dev wanted to
| learn Rust
|
| Many such cases. Recipe for disaster.
| rob74 wrote:
| a.k.a. "resume-driven development"
| makeitdouble wrote:
| Typically, devs polishing their resume instead of
| prioritising business metrics probably means the overall
| org is on the down slope.
| mytailorisrich wrote:
| Perfectly normal for people to want to develop their
| skills and to enhance their value.
|
| The thing is that this is not a developer's decision,
| this is a management decision. The developer might pitch
| for Rust or even start developing in Rust but if that is
| not right for the org then their manager should say 'no'.
|
| So ultimately this is a red flag about management.
| ndndjdjdn wrote:
| Slightly disagree.
|
| Needing the managers permission is more of a "wartime"
| mode.
|
| For peacetime the management should set a culture of peer
| review and data and logic driven discussion. The culture
| would ideally have a Rust lover sit there and think
| "would love to do this in Rust but...." because they know
| their peers will be affected by this decision.
|
| The problem with management approval required is it
| usually meams no or bias towards management pressures. A
| management veto that is occasionally used may be better.
|
| Disclosure: not a Rust programmer but pretty neutral on
| it. It is on my radar if I get a problem Node or Go can't
| solve.
| ndndjdjdn wrote:
| Or the dev wants more money
| ahoka wrote:
| I think the rule of thumb should be that if you wouldn't
| write aomething in C++, then you shouldn't use Rust.
| j-pb wrote:
| That's a horrible rule of thumb, because C++ adds a ton of
| complexity with little reward except for speed. Rust adds
| less complexity (still a lot ofc), but it also gives you
| awesome tooling and dependency management (much better than
| python for example), and and extemely powerful typesystem
| and functional programming features, that make writing
| correct code extremely easy.
|
| Rust is a complex but overall good language for writing
| solid software, C++ is making a deal with the devil in
| exchange for speed.
| ttfkam wrote:
| If a garbage collected language can easily do the job,
| choose the garbage collected language. I like Rust, but
| it is NOT the fastest language to develop in.
|
| Typescript, Python, Go, Swift, and even Bash depending on
| the situation are all quicker to code in than Rust.
|
| If any of those languages are inadequate for the
| requirements whether they be memory-bound, CPU-bound, or
| sensitive to gc pauses, Rust is an excellent option that
| is far superior to C++ in 2024 and beyond.
|
| The notion of "one true language" has always been and
| will always remain a fool's errand.
| j-pb wrote:
| I write most of my stuff in a combination of Python,
| JS/TS and Rust these days with some form of Interop
| between them. I.e. mostly Python Marimo notebook with JS
| visualisations, and PyO3 Rust bindings.
|
| Tbh I don't find myself to be "slow" in rust. Sure for
| quick exploratory stuff the notebook-environment and
| introspection capabilities of a dynamic language are
| definitely nice (e.g. when taking apart some unknown JSON
| data format), but especially when it comes to complex
| logic and refactorings Rusts type system is really making
| a big positive impact on productivity.
|
| Sure TypeScripts type system is also powerful, but Rust
| is consistently better at infering types from closures
| and function calls, and the existing types and tooling
| story is miles ahead of TS. (and I've never encountered
| an easier to setup/use model checking language
| integration than Kani)
|
| For one-offs where correctness doesn't matter, sure throw
| $SCRIPTING_LANG at it. But once you want correct
| software, I'd still choose Rust in a heartbeat.
| cozzyd wrote:
| You missed the point of the rule of thumb. Maybe
| rephrasing it as if 15 years ago you would have written
| it in C++ would help.
| j-pb wrote:
| Nope. C++ has mostly downsides, Rust has significant
| upsides.
|
| A good rule of thumb would be: is correctness and code
| confidence more important than learning curve and compile
| times? If so Rust, otherwise JS or Python (with possibly
| parts in Rust).
| physicsguy wrote:
| Embedded developers that know Rust is an even smaller pool than
| Rust developers in general. It's almost two non-intersecting
| groups of people since embedded in general is less well paid in
| many countries and so doesn't attract people interested in the
| latest and greatest hyped up language.
| Seattle3503 wrote:
| As a Rust dev looking for a new job, this is my experience. I
| filter out the embedded jobs because knowing Rust only half
| the equation for those roles.
| gwd wrote:
| This question of "what tools / languages" should we use was
| introduced to me (during an interview, actually) as "technical
| strategy". There is more to the choice of language or tooling
| than whether it's fast or slow or reliable at one instant in
| time -- you have to ask how you will grow and maintain things
| going forward.
|
| That said, obviously all languages were in that state at some
| point. Twenty-eight years ago you might have said the same
| thing about Java. Twenty-four years ago, Perl might have looked
| like a better choice than Python; now it's clearly the
| opposite. XenServer took a gamble and wrote their main control
| stack in OCaml in 2008; on the whole that has had some
| benefits, but the number of OCaml developers has not
| significantly grown, and it's not easy to hire people.
|
| That said, I think Rust is much more likely to follow Java's
| trajectory than OCaml's: My prediction is that it's only going
| to be easier and easier to find Rust developers.
| devsda wrote:
| I wish and I'm sure Rust will get there some day but is there
| a no-brainer usecase today where it's really important to use
| Rust, one important enough to overlook the initial learning
| curve, developer scarcity and evolving ecosystem?
|
| If there's a killer open product out there where the primary
| supported language is Rust(Linux kernel might as well be it
| someday), or if a big company launches a successful product
| in Rust then adoption may accelerate. For now its mostly
| limited to cryptocurrencies, performance critical paths or
| rewrite of hidden core components but nothing flashy.
|
| "Nobody ever gets fired for buying IBM". Unless teams can say
| the same about their choice of Rust, people are going to be
| risk averse and prefer using safest choice as long as its
| good enough.
| ttfkam wrote:
| Another use case is when you need a systems language for a
| user-facing app (even if not directly connected to the
| internet) and would have reached for C++ previously.
|
| Memory corruption bugs are no joke. If you've got staff
| that already knows C++, their ramp up time for Rust will be
| much shorter compared to typical devs working only in
| Python, JS, etc.
| psychoslave wrote:
| I don't know about your later claim. To my shallow knowledge
| of Rust, it doesn't try to compete on the same segment as
| Java.
|
| For the latter it's still kinda of "everybody can write some
| code that will run everywhere". The former is more like "you
| can have performance, consistency and correctness in a
| shallowly-C-like syntax", which is more likely to tease the
| average HN reader, but probably not the average programmer
| who is in to earn some descent money or as a way to start
| before moving up in the businesses hierarchy.
|
| And you see there are some people which enthusiast to push
| Rust into the Linux kernel, while I doubt that in Java
| projects of similar size there is that much ardor for even
| introducing it in some part of it, let alone propose a full
| rewrite.
| Seattle3503 wrote:
| > I don't know about your later claim. To my shallow
| knowledge of Rust, it doesn't try to compete on the same
| segment as Java.
|
| I don't think the origin lame was that it would compete for
| the same segment, but that it would reach the same level of
| ubiquity. It could do that by opening up a new non-existent
| segment, eg smart contracts on the block chain. Or it could
| take a little from multiple domains.
| pyrale wrote:
| > descent money
|
| When you want a decent paycheck, but instead get a descent
| into computing madness.
| psychoslave wrote:
| haha, nice catch, thanks for the smile. :)
| sshine wrote:
| > _Rust is much more likely to follow Java 's trajectory than
| OCaml's_
|
| I'd rather compare Rust to Haskell and Kubernetes.
| Haskell: - Dozens of handfuls of experts open to remote
| work. - Lots of aspiring juniors who see no way to
| enter the market. - Most employers are R&D-heavy
| academic consulting environments. Kubernetes:
| - Wildly hyped and cherished among people who don't have the
| complexity to warrant the purchase. - Eventually
| criticised for being overly complex and suitable only at a
| certain size and setup.
|
| > _it 's only going to be easier and easier to find Rust
| developers._
|
| I imagine it's never been easier to find Haskell developers
| and Kubernetes developers, either.
|
| Yet, one's wish to code Haskell professionally does not
| necessarily align with one's market value.
|
| It seems like there's a lot more open for Kubernetes, so Rust
| could go that way.
|
| Unlike Haskell, Rust seems to gain industry acceptance.
| pdimitar wrote:
| Haskell and OCaml have a lot of what Rust has (namely
| exhaustive pattern matching + sum types, typeclasses and
| the like) but Rust has stellar tooling.
|
| Had both of these languages' ecosystems and communities not
| dragged their feet and go full elitist on newcomers then
| Rust might not have ever been created.
|
| So sure, Haskell and OCaml are great but after I spent half
| an afternoon trying to bring in a dependency in a little-
| more-than-hello-world Haskell program and then spending the
| other half on trying to do the same in OCaml I just threw
| my hands in the air and said "frak this, there has to be a
| better way".
|
| Hence I landed on Rust. You and others can always say
| "skill issue!" but that's hugely missing the point; I want
| to use my skills on solving the actual problem, not on the
| logistics. We're not in the 1970s anymore and a weirdly
| huge number of people still haven't gotten that message.
| rixed wrote:
| I do have one ear for that argument that "everything
| ought to be simpler". But what I've observed over and
| over is that many systems tends to become more complex as
| the result of people wanting to make them more newbie
| friendly.
|
| That's certainly true of the last 10 years of Ocaml
| tooling evolution.
| pdimitar wrote:
| I guess you could argue both ways and it depends on your
| starting point. I did not mean to say "make it newbie
| friendly", I meant "I want adding a dependency to my
| project to be a 10 seconds job, not a week-long
| endeavor".
|
| If we both start from that point then I think we might
| find a common ground.
| rixed wrote:
| Yes it does very much depend on your starting point.
|
| For instance, coming from C Unix programming, it took me
| 2 hours to try OCaml 15 years ago or so, because Ocaml
| tooling, at that time, was the same as C. Basically, I
| made a generic rule for my makefiles to call ocamlopt
| instead of gcc and I was good to go. Installing a
| dependency was just the usual "./configure && make
| install"
|
| This was simple for me, but not for students with no Unix
| background. In that context "opam install" was simpler,
| although it's objectively more complex as it adds a few
| additional layers on top of the same process.
| pdimitar wrote:
| Yep, it's about your background.
|
| I moved away from makefiles long ago and I don't regret
| it, for a multitude of reasons that are well explained in
| many places.
|
| `cargo add ...` is great and I wish every language
| offered a tool like that.
| rixed wrote:
| Even when i use cargo or go or node, make is still needed
| to build everything that's not just code.
| pdimitar wrote:
| If you say so. There are plenty of tools that can do more
| or less the same without having to remember weird bash-
| isms and pattern expansion rules.
|
| I use `just` for project tasks, but there are many
| others.
| sshine wrote:
| > _make is still needed_
|
| You mean: I still need make
|
| For example, build.rs replaces some uses of a makefile.
|
| > _build everything that 's not just code_
|
| Have you heard of: Just, Nix, Bazel, Helm, Terraform?
|
| Depending on the situation, there are many things you can
| build that aren't strictly code where you can use a bunch
| of other tools than make.
| sshine wrote:
| > _Rust has stellar tooling_
|
| I came for the job opportunities.
|
| I stayed for the tooling.
|
| > _Haskell and OCaml are great but after I spent half an
| afternoon trying to bring in a dependency in a little-
| more-than-hello-world Haskell program_
|
| I had a similar experience trying to make Haskell's LSP
| work in test files. After ten years of using Haskell for
| academic and hobby projects, I still couldn't make the
| red squigglies go away in test files. With Rust I
| struggle similarly when dealing with cross-compilation
| and a complex set of feature flags on Nix. But at least
| this is not "Hello World!" failing.
| pdimitar wrote:
| Well to be fair to Rust, Nix can drive anyone crazy. I
| tried that one too and figured they sniffed way too much
| of their own drugs, if you pardon the expression. In the
| meantime I learned `just` in 10 minutes.
|
| Sure, not the same usage patterns, I get that of course,
| and I love the idea of Nix but they could have went about
| it very differently with a much better UX / DX... and
| they refused.
|
| Side topic though, sorry for the digression. Main point
| was that if you use Rust normally without any weird and
| not fully accounted for wrappers then everything works
| fine. I just fired Neovim in a personal project I haven't
| touched in a year -- 20-30 seconds of LSP compiling stuff
| and I saw my project-wide compiler warnings immediately
| after.
| acomjean wrote:
| I don't love Perl, but we have 10+ year old Perl scripts at
| work that work fine.
|
| The python scripts of the same vintage have to be reworked
| because python versions and importantly supporting libraries
| have changed.
|
| This is mainly because Perl hasn't changed, with the failure
| of perl6 to launch. But it's an interesting comparison.
|
| I'll agree Rust will be like like Java.
| pdimitar wrote:
| RE: scripts, I find Golang better and better for this
| nowadays. Uber-fast compilation, to the point of it being
| acceptable to just instead do `go run your_thing.go` even,
| and you have access to a very solid runtime and many
| libraries for most of what people usually need.
|
| I don't argue with the portability and longevity of Perl
| but it too has its problems.
| fredrikholm wrote:
| The longevity of Go is also a thing. I have not
| encountered a single Go project that used to compile but
| now doesn't because it hadn't been touched.
|
| Go is in many ways leap years ahead of most AOT languages
| I've used in anger. Yes, sometimes you miss XYZ, but
| seldom is that an issue outside of personal preferences.
|
| What you do get though is amazing tooling and little-to-
| no downtime. Builds basically don't take any time, tests
| run past, pipelines are quick.
|
| _go test . /..._ finishes faster than you can print
| _Determining projects to restore..._ to the screen. It 's
| a very liberating experience that is hard to go back
| from.
| pdimitar wrote:
| Agreed 100%.
|
| I have my very real pet peeves with Golang -- lack of sum
| types and thus no exhaustive pattern matching is the top
| one -- but I can't argue with results. Every time I
| wanted to whip up something quickly, Golang has gotten
| the job done and then some.
| fredrikholm wrote:
| I've gotten far with type switching on an interface that
| amounts to a single function that does nothing.
|
| Unfortunately it does nothing in terms of exhaustiveness,
| but it effectively gives you sum types which IME are so,
| so much easier to work with than state pattern or other
| inject-an-object-abstractions. Not having to design an
| API (that later leaks) is rewarding enough.
|
| It's strangely efficient as well. I've experimented with
| implementing sum types via tagged C-style unions and at
| every (ad hoc, micro) benchmark I've tried them against,
| type switching on an interface comes out on top.
| pdimitar wrote:
| Can you point me at an article that demonstrates Golang
| type switching? Does not ring bell at the moment for me
| so I'd love to see the code.
| assbuttbuttass wrote:
| https://go.dev/tour/methods/16
| pdimitar wrote:
| Thanks, for some reason I never stumbled upon this. Very
| valuable, I am bookmarking it.
| pjmlp wrote:
| Still leaves a lot to be desired versus Object Pascal
| from Apple/Borland days, or Delphi afterwards.
| tashmahalic wrote:
| What makes those better?
| pjmlp wrote:
| The language features, designed for full stack systems
| programming, IDE tooling, the frameworks bundled with the
| compiler, first class support for binary libraries
| ecosystem, no culture against modern times...
| gwd wrote:
| > I don't love Perl, but we have 10+ year old Perl scripts
| at work that work fine.
|
| I'm not talking primarily about Perl as a technology in and
| of itself, but as a long-term technology choice in terms of
| being able to find people to maintain and improve it.
|
| The Xen Project has a bunch of support stuff (automated
| testing and tooling around doing security work) written
| Perl. It was just about a reasonable decision when it
| started to be written 10-15 years ago; Golang was too
| young, Rust wasn't written yet, and Python had its
| downsides. But when the author of the code left the project
| 2-3 years ago, and there was 1) nobody with a similar level
| of expertise to maintain it, 2) nobody particularly wanted
| to gain that expertise, and 3) it wasn't easy to find
| someone else to pay to do maintenance.
|
| If you've managed to find people who can maintain those
| perl scripts, more power to you; but it unless perl5 can
| get some momentum back, it seems like it's going to be
| harder and harder to find replacements.
| adamc wrote:
| I dunno. Java was pretty easy to learn for its first
| decade. Eventually, the complexity of Java and, especially,
| its toolchain ballooned. By then there were already a lot
| of Java developers, though.
|
| Rust is a different beast, much more complex from the
| outset, and not trivial to learn (as Java was). It will
| grow if that's where the best jobs are, but I don't think
| it is going to grow in the way Java did, because the
| difficulty and dynamics are different. There was a good
| stretch at the beginning where Java was both very helpful
| on your resume and really easy to learn.
| netdevnet wrote:
| The kind of people that recklessly move from shiny language
| to the newest shiny language in town are the same kind of
| people that believe that you could kick out a dev writing
| systems in Java and stick a dev whose experience has only
| been Haskell and O'Caml and have the new dev hit the ground
| running
| pyrale wrote:
| > you have to ask how you will grow and maintain things going
| forward.
|
| The typical answer is "The jobs market will provide".
|
| The issue with that method is that you end up competing with
| everyone and, usually, your company is not the top employer.
|
| OTOH, some companies decide to use technology and invest in
| knowing the community, by hosting events or meetups, by
| frequently sending their devs to conferences on company time,
| etc. Usually, the people hired are above average, and are
| also able to train juniors if the market dries up. These
| companies typically are the safest in terms of ability to
| maintain their stack, but have to account for the fact that
| alienating their existing devs becomes a big risk.
|
| The real harm comes for companies that choose niche tooling
| but believe the market will provide.
| gwd wrote:
| Right -- you can choose a niche technology, as long as
| you're willing to commit to the additional costs of doing
| more training, being involved in the community, and so on.
| Those additional costs (and/or the risk of not doing so)
| need to be factored into the decision to use a technology.
| stonemetal12 wrote:
| If a company chooses non standard tools then they are doing
| it with the knowledge that they will have to train new hires
| in it. Random employee using non standard tools without the
| company making the decision to pivot to embracing it, aka
| training existing\new employees in that tool, is just making
| stuff that your company will have to throw away and redo.
|
| So XenServer embracing OCaml is nothing like Random Gamdev
| writing some scripts in Rust without the team deciding to
| embrace the change.
| AnimalMuppet wrote:
| But 28 years ago with Java, it had a clear edge in a certain
| space. It came with a ton of libraries, so you didn't have to
| write a bunch of code. And it had garbage collection, so a
| bunch of problems just went away. For code that didn't have
| to be close to the metal, it was clearly superior. And it was
| pretty easy to learn for C++ developers.
|
| Rust may have an advantage in certain places (no segfaults is
| a definite win). But replacing working Python scripts is
| almost certainly _not_ that place. Also, for a C++ developer,
| Rust isn 't as easy to learn as Java.
|
| Rust may get there. But don't use Java's success to predict
| Rust's trajectory.
| Keyframe wrote:
| Java had a lot of things going on for it. Huge marketing
| push, whole set of everything both language and lib-wise,
| and killer domain which was SIM and mobile which if you
| wanted to do it was your only choice. Rust has no such
| things at the level Java had when it rose. It's more of an
| organic grassroots movement certain companies have started
| to pick up.
| tcmart14 wrote:
| Yea it did, and its important when making comparisons to
| not glaze over it. Java with the, write once and run
| anywhere mantra due to the JVM was a huge deal. Granted,
| in some ways it didn't pan out as well as advertised
| (embedded Java), but for an enterprise desktop
| application, it was definitely a huge win for the time.
| pjmlp wrote:
| Apparently there was something to it, otherwise we
| wouldn't have every other day a WebAssembly startup being
| upvoted.
| geodel wrote:
| > I think Rust is much more likely to follow Java's
| trajectory than OCaml's:
|
| This looks like pipe dream of those Rust devs who usually
| claim that Rust borrow checker is easiest thing since heating
| HotPocket in microwave.
| adamc wrote:
| Twenty-four years ago, Python already looked better to me. I
| maintained a big Perl 5 app. Yuck. The problem wasn't that
| you couldn't write it, the problem was that you had to be
| able to read widely differing styles of Perl... and if you
| wanted to read library code, it was a huge pain. I quit
| maintaining that system in 2005, and it has barely changed
| since, from what I'm told.
|
| Viability of a language is certainly a consideration, but the
| characteristics of the language also matter.
|
| What you couldn't really predict about Java in, say, 2000,
| was how much the complexity of its ecosystem would grow. In
| 2000 (or 2005) it was fairly easy to move in and out of Java
| from project to project. That is not true today. My fear on
| the Rust front is that it's going to be another C++, where
| the complexity is considerable and requires more or less
| full-time expertise.
| atoav wrote:
| As a Rust/Python dev I previously decided against Rust in a
| work context as I deemed it would make me the sole person who
| knows what is going on, while python feels much more like a
| lingua franca of programming nowadays.
|
| I would decide this on a case by case basis tho, Rust is
| different, but if e.g. what you wrote derives most of its
| business logic from its configuration, or the usecase is so
| generic changes aren't gonna be a thing for a while, why not.
| Rust is different, but unless you want a complete rewrite or
| new complex features any developer should be able to get into
| it if you give them a little time.
|
| And the strictness of Rust makes it unlikely that they break
| things in a bad way, which is good.
| dijksterhuis wrote:
| > but if e.g. what you wrote derives most of its business
| logic from its configuration, or the usecase is so generic
| changes aren't gonna be a thing for a while, why not
|
| there's also the fairly easy cross compilation to bear in
| mind.
|
| i built a container entrypoint binary via python to stick in
| all our containers at last job.
|
| getting that to cross compile was going to be a bunch of pain
| i wasn't willing to go down for a simple "download files from
| S3, run a sub process, upload files to S3" pre-execution
| wrapper.
|
| digital ocean infra + self hosted gitlab --> no readily
| available windows instances.
|
| so everyone had to use linux to dev these containers with
| wine+mono.
|
| being able to cross compile would have been brilliant here. i
| made the decision to not do this in rust for future
| maintenance reasons. but then people avoided using this thing
| because they couldn't run on windows :/
|
| (i know there's that paid for package but the license fee is
| mind boggling from what i remember).
| hu3 wrote:
| perhaps Go could have been a good solution for simple,
| cross-compiled code.
| dijksterhuis wrote:
| from what i looked at, go was a bit more complicated than
| rust for cross compilation. but it was still a lot less
| complicated than sorting it out for python. dunno. was at
| least two years since i looked at it, but i remember rust
| coming out on top in my mind.
|
| unfortunately the same maintenance issue applied -- it
| was a python / R shop so no-one else would have been able
| to change the code once i left.
| hu3 wrote:
| AFAIK Go has one of, if not the easiest cross compilation
| stories.
|
| This is all it takes to build a linux arm64 binary:
| env GOOS=linux GOARCH=arm64 go build your_program
|
| You can even run that from Windows and it will just work.
|
| This is how you list all possible targets:
| go tool dist list
|
| If you want to generate binaries for many linux distros,
| you can even use a simple bash script:
| #!/usr/bin/bash archs=(amd64 arm64 ppc64le ppc64
| s390x) for arch in ${archs[@]} do
| env GOOS=linux GOARCH=${arch} go build -o
| your_program_${arch} done
| dijksterhuis wrote:
| thats definitely not the commands the guide i looked at
| had lol
|
| looks on par with rust then. go is the next one for me to
| dive into when im doing fiddling with rust audio stuff.
|
| regardless, wouldn't have worked at last job as no-one
| knew go either. would have been easier probably to get
| someone in, but i spent a year trying to get one new hire
| to no avail, so doubtful.
| realusername wrote:
| What concerns me even more than the talent pool is that Rust is
| a language that isn't straightforward to learn.
|
| I can be confident to teach any average developer about Go
| without any prior experience relatively quickly, I'm not so
| confident I could do the same with Rust.
| amelius wrote:
| Go is also a more productive language for many use cases.
| jcgrillo wrote:
| My experience is the opposite. I spend a lot more time in a
| debugger when I work with golang than when I'm working with
| rust. Sure, there's a learning curve with rust's borrow
| checker, but once you figure out how to use it I find rust
| to be a much more "flow state" development experience, with
| less interruptions of the form "what is this program
| actually doing and why?"
| amelius wrote:
| You forget that a lot of projects benefit greatly from
| generalized GC.
| jcgrillo wrote:
| No. I didn't forget. It has not been my experience that
| not having a garbage collector in rust was a problem in
| practice.
| sunshowers wrote:
| On day 1, yes, a newbie to Go would be able to be more
| productive.
| ramon156 wrote:
| These comments make it seem like it's impossible for people
| to learn Rust. I have to admit that it takes a fair bit
| longer than other languages, but so is c/c++. Is there a bias
| towards not using Rust by other devs? Is it a scary language?
| realusername wrote:
| I'd put the same concerns for C and C++ to be fair. The
| learning curve just isn't the same as most other mainstream
| languages.
| ttfkam wrote:
| I'd put even more concerns on C++. All the same concerns
| plus all the concerns that arise from the compiler not
| helping you nearly as much. It's easy with C++ to be
| lulled into a false sense of security because it
| compiles, and your trivial happy path works. Under load
| or with unforeseen input, the chance for memory
| corruption is massive even for experts let alone
| beginners because it only takes one to bring down a whole
| process.
|
| C++ is better than it used to be, but it was truly
| atrocious in that regard for decades. It was simply the
| least worst option for those decades.
|
| I do not consider it the least worst option anymore.
| ttfkam wrote:
| A garbage collector really takes away a huge amount of
| cognitive overhead. In doing away with it, Rust requires
| that you understand the borrow checker and lifetimes, even
| if minimally due to extensive use of .clone() in your early
| code. This ties into all of the different kinds of strings
| in Rust from str to string to vec[u8], etc.
|
| Unlike Go that only really requires experience in general
| programming to become rapidly productive, Rust basically
| requires that you read The Book in its entirety before you
| even think about applying that knowledge in production.
| There are just to many interdependent concepts to hand wave
| away the prep time. It all (mostly) makes sense once you've
| familiarized yourself with the basic concepts, but it's a
| training step you simply cannot skip without inflicting a
| fair amount of pain on yourself and others.
| oneshtein wrote:
| It doesn't match my experience with Rust. How much code
| you wrote in Rust?
| steelegbr wrote:
| Indeed. The few times I've encountered Rust in the wild it's
| been for a project that didn't need it (web or IO bound
| applications) and someone's "My First Rust Project". It's
| difficult or even at times beyond the budget of smaller
| organisations to then hire a seasoned Rust dev to unpick
| whatever mess you got in to.
|
| Don't get me wrong, Rust has a niche where it's the right
| choice. But being a popular language of the day, it's getting
| used a lot in the wrong places.
| 6r17 wrote:
| Project that does not need rust "Web, or IO" -> What would
| you actually choose to make an API then ? Python ? Ruby ? Did
| you compare benchmarks from rust server to python servers ?
| Did you actually feel the difference ?
| wmil wrote:
| Most web servers aren't doing anything computationally
| complex and there's a lot of tech to help you scale to
| multiple servers, so single server performance usually
| isn't really critical.
|
| Web stuff is about developer speed. So familiarity,
| libraries, and tooling. There are plenty of good options.
|
| Anything that needs to be performant can go in it's own
| service.
| smolder wrote:
| I will say that a rust service, even when doing
| relatively simple stuff, can scale well in the cloud due
| to small memory footprint, fast startup time when auto-
| scaling in containers, and no need for a JIT to "warm up"
| before it has high throughout and consistent low latency.
| Building something with these qualities on a framework
| like Rocket is pretty straightforward, IME.
| 6r17 wrote:
| Building a web app with rocket is like using a fine BMW
| to go on highway. It just feels right- I love Guards and
| what not he added in his framework ; absolutely
| refreshing work !
| 6r17 wrote:
| Have you heard of something called climate change ?
| hu3 wrote:
| > What would you actually choose to make an API then ?
| Python ? Ruby ?
|
| Python, Ruby, Go, PHP, C#, Java, TypeScript, Elixir.
|
| Performance benchmarks when writing APIs as 1st concern?
| Really? 99% of the cases this should be the last criteria.
|
| Monthly reminder that a good part of instagram still runs
| on Django/Python.
| j-krieger wrote:
| > Only the author "knew" Rust and it was hard to justify a new
| hire Rust developer to maintain this small set of tools.
|
| There are two dialects of Rust. One can be written immediately
| by beginners, the other is for experts.
|
| I make sure to write scripts in the first dialect. It uses
| `clone` all over the place, does not make use of any async
| runtime, and makes extensive use of "anyhow" for error creation
| and logging.
|
| I advise all my peers to do the same, if they find a need for
| Rust in tiny scripts or applications.
| sshine wrote:
| > _There are two dialects of Rust. One can be written
| immediately by beginners, the other is for experts._
|
| I believe it's more like a spectrum.
|
| I'm 3 years into my Rust career.
|
| I started with .clone() everywhere.
|
| Then I moved on to write highly async code with tokio and
| std.
|
| Now I'm somewhere entirely unfamiliar, writing highly
| portable no-std Rust for bare-metal and wasm.
|
| It takes some time to know the difference between std and
| core.
|
| It takes some effort to write modular, allocation-free code
| (static allocations only).
|
| It takes some rediscovery of what crates will work for you.
|
| It's a steep curve, and I don't imagine everyone likes it.
| throwawaymaths wrote:
| Strong "only use this subset of c++" energy
| iknowstuff wrote:
| except using a different set of rust is not gonna allow
| RCEs or leak your data to the internet
| throwawaymaths wrote:
| Eh. An enterprising young developer could build an ECS
| style system with references as u32 indices and all bets
| are off.
| nicoburns wrote:
| > I recently finished a contract at a (very large game dev)
| company where some tools were written in Rust. The tools were a
| re-write of python scripts and added no new functionality but
| were slightly faster in Rust. > The reality was that these
| tools were unmaintainable by the rest of the company. Only the
| author "knew" Rust and it was hard to justify a new hire Rust
| developer to maintain this small set of tools.
|
| I can believe this, but it's funny because I work on a project
| where the main product is written in Rust, and it's the build
| tools written in Python that are the technical debt that nobody
| really wants to touch! In our case I suspect rewriting them in
| Rust will end up being the right thing to do (if/when we can
| justify the switching costs).
| Seattle3503 wrote:
| That makes sense, as the bulk of your developers are probably
| Rust devs. Homogeneity favors Rust in this case. Also Rusts
| existing build system is (unsurprisingly) built around Rust,
| so it makes sense to keep with it.
| cypressious wrote:
| I really enjoy projects where the project and the scripts
| around it use the same language.
| bsnnkv wrote:
| > I can believe this, but it's funny because I work on a
| project where the main product is written in Rust, and it's
| the build tools written in Python that are the technical debt
| that nobody really wants to touch!
|
| Oh hi! You must be my teammate!
|
| I joined a team like this and just started a personal
| build/dev/ops tool repo in Rust for things that I needed but
| were not automated. Over time it has become an "official"
| repo and renamed to be blessed with an official "org" package
| prefix.
|
| When I started this project and people were interested, I was
| asked why I didn't just add to the Python repo; I said that
| others are free to rewrite them if they want to, but I can't
| justify spending days messing around with Python to achieve
| what I can in less than 30 minutes with Rust when I need to
| quickly automate a tedious task.
|
| Edit: A lot of downvotes on this, but in case it wasn't clear
| - the team is happy that someone took the time to scaffold a
| repo in Rust that everyone feels more confident in
| contributing to, since the overwhelming majority of the
| codebase is written in Rust and the Python tools repo is full
| of annoying runtime errors that could be trivially caught at
| compile time.
|
| The end result is more people feeling more empowered to
| automate repetitive and tedious tasks which can easily be
| fudged when executed manually instead of suffering with them
| because someone who isn't even here anymore decided to start
| a tools repo in Python for a team that almost exclusively
| writes code in Rust.
| 6r17 wrote:
| I switched up from python to rust for some processing pipeline
| at work - rust has a lot of advantages over it specifically for
| typing and speed, the work itself it a little bit longer to
| develop. But the quality output is not even comparable, the
| code itself is way more readable and explicit than in python
| code.
|
| There is not a lot you can do to make your python code as good
| in terms of reliability or clarity of intent. I'm sorry to hear
| that you did not have a good experience with it, but frankly
| speaking, I cannot look at python code anymore because of the
| inherent "hidden" work that it creates, variables being passed
| trough without much care for their exact meaning, hidden "bugs"
| that make the overall job way more annoying to debug.
|
| Python is like that person that tells you everything is fine
| but is mostly wrong and won't even tell about that. Whereas
| Rust will just straight up tell you what's wrong in the draft.
|
| I prefer the honesty and the little additional overhead work to
| getting lost in debugs for weeks bc some person has inputed the
| wrong shape for some vals or whatnot.
|
| The peace of mind is saving me a ton on maintenance as well.
| (project is a 2years on with distributed python pipeline with a
| bunch of IA processing - switching up to rust was not the
| easiest thing to do considering some parts had to stay in
| python because of code ownership being someone's else - the
| stack is a rust/python stack now with some parts being left out
| in python depending on the actual needs of update)
|
| I understand very well that some people do not want to code in
| rust, specifically because they might not have the time or the
| will to do so. But objectively these people do not have to
| define the pipeline execution except for the actual order of
| execution, nor do they need to maintain every part of the code
| because it's just not their job.
|
| Now if you are to compare the exact benefits of rust vs python
| for a company, the server pricing will just speak itself and
| the choice will be made depending on the cost of production,
| the lifetime of the code, and the actual benefits.
|
| If I was to do some API today, I'd 50000% go for rust and I DO
| think of python as the `no-coder coder` thing. I initially
| learned C, switched up to Python for jobs, and the code quality
| of python is just downright bad. It does not push me in the
| right direction AT ALL.
|
| The fact that we used a scripting language with no typing for
| tools that need any kind of guarantee for years does not mean
| it's the best way to do it.
|
| Also to answer the problem concerning `rust` dev's being non-
| existant on the market, and no job being open is really simple
| : even tough rust has 10 years on the developer market on this
| is really young and need to learn.
|
| You need 3 years of practice to get 3 years of experience with
| rust. There is no way around that. And there is just not enough
| experienced people with this language yet to make it a shift.
| I'm not saying there is none, i'm saying it's not yet
| democratized.
| physicsguy wrote:
| > You need 3 years of practice to get 3 years of experience
| with rust.
|
| This is the major barrier. It's a difficult language to learn
| for people who've worked with a compiled, strictly typed
| language with manual memory management. That barrier is much
| higher for people who've only ever used a dynamic,
| interpreted language.
|
| I'm on-the-fence about orchestration of pipelines with Python
| since I've experienced a lot of the issues you're talking
| about, but you can just abstract the Python algorithm parts
| in to APIs that your pipelines call and separate out those
| two concerns. Then it's clear who has maintenance
| responsibility, it separates out the algorithms from data
| collection + calling, and it doesn't introduce a big barrier
| next time someone wants to implement something that depends
| on the latest and greatest algorithm written in Python, which
| writing in Rust inevitably does.
|
| To me though, I don't really understand the use of Rust in
| non-systems programming. For a lot of the use cases people
| talk about, Go seems like a better fit with a lot less of the
| pain since it's a much simpler language. When teaching people
| a language I'd much rather do that with Go than Rust, and
| that matters in an environment where developers who know
| either are not really that commonly available (at least here
| in the UK).
| 6r17 wrote:
| I can 100% understand your take on `go` and will probably
| think of it more often !
| ttfkam wrote:
| > This is the major barrier. It's a difficult language to
| learn for people who've worked with a compiled, strictly
| typed language with manual memory management.
|
| This was not what Google and others found when they studied
| it.
|
| https://www.theregister.com/AMP/2024/03/31/rust_google_c/
|
| > More significant, Bergstrom said, is the comparison of
| rewrites of C++ code into Rust.
|
| > "In every case we've seen a decrease by more than 2x in
| the amount of effort required to both build the services in
| Rust as well as maintain and update those services written
| in Rust," he said.
| robertlagrant wrote:
| > The fact that we used a scripting language with no typing
| for tools that need any kind of guarantee for years does not
| mean it's the best way to do it.
|
| You can add typing tools now, though? CI pipeline runs mypy
| and that gets you a long way.
| FridgeSeal wrote:
| 100% this. Well put.
|
| The Rust codebase I've built on run faster, don't crash, are
| more correct, and take only marginally longer than the first
| python version. They're easier to maintain, they're easier to
| upgrade their dependencies, I'm more confident about
| asserting guarantees from the codebase, and it's an easier
| time onboarding people and having them meaningfully
| contribute. There's no more death-by-a-thousand-cuts that I
| experienced with Python codebases. I don't have to worry
| about my Rust codebases blowing up at 2am because of some
| random exception.
|
| I am defs not going back.
| otabdeveloper4 wrote:
| > Access to competent developers can be a challenge for
| companies.
|
| Fixed it for you. You wouldn't believe the quality of the
| average applicant for a basic standard Python position if I
| told you.
| isoprophlex wrote:
| At least you can pretend you've hired someone that's going to
| solve your python problens. And to mgmt, that's sometimes the
| only thing that matters.
|
| Greasing the wheels of the corporate meatgrinder with Rust is
| almost impossible, actual work quality notwithstanding.
| goodpoint wrote:
| > Access to competant Rust developers can be a challenge even
| for large companies.
|
| Huh? There's tons of good developers looking for jobs right
| now, more so in Rust.
| FridgeSeal wrote:
| God I feel like I'm taking crazy pills when I read these
| threads.
|
| Can I hire 1000 Rust devs at the drop of a hat off the street?
| Well, no. Have I ever struggled to find competent Rust devs, or
| high level people who were happy to learn? Nope.
|
| I would absolutely not be afraid to use it because of "hiring
| concerns". If your current devs can't or won't learn anything
| new, they're not very good at their job. If you can't or won't
| hire because you can't find a super-senior at the drop of a
| hat, well, your hiring process is broken and no language will
| really help there.
| jcgrillo wrote:
| The underlying (absurd) assumption is that the sum total
| potential of a developer you hire to do a job is statically
| determined by their past experience at interview time. This
| is the problem with "Human Resources" thinking, it fails to
| account for all the, well, human stuff.
|
| Case in point from the article:
|
| > it is not viable (for us) to retrain a C developer to Rust
|
| What? Why the hell not?
| the8472 wrote:
| If it's just a few tools that are essentially scripts and they
| don't even warrant a full-time dev then wouldn't a random
| senior dev do?
|
| I have had to touch things in languages I'm not familiar with
| and initially it's slow due to having to look things up, but
| plenty knowledge still does transfer. Opening a file is still
| opening a file, updating dependencies is still updating
| dependencies. Plus python devs should be used to changing
| tooling all the time ;P
| marhee wrote:
| Did you not offer to rewrite it in Python? I was a techical
| director at a company where we worked a lot with frontend
| contractors. Some loved typescript others were fans of vanilla
| js. When the balanced tipped there were rewrites from one to
| the other (ts to js to ts again), the first one two months full
| time, the second was interspersed with feature development. Of
| course the developers were very happy they could do it; it
| improved the solutions and afterward they both had 1) extreme
| product ownership 2) excellent company problem domain
| knowledge. So, a win-win for everyone. So I think, especially
| as it is a smaller part, than translating back in to Python
| would be warranted (provided you like it and would stay a
| while), not a big deal and a quite natural option.
| melodyogonna wrote:
| I don't think it needs rewriting if the original version was
| in Python. What you need to do is return the original Python
| version
| mellosouls wrote:
| _The only reason these tools were written in Rust was because
| the dev wanted to learn Rust (a big but common mistake)._
|
| While they should get wider buy-in first then if the choice is
| technically justified within reason, its perfectly appropriate
| (and normal) for devs to pick up new languages in this way when
| existing expertise is not available on staff. No competent dev
| will accept their skills atrophying due to overly rigid
| political/tech choices.
|
| That's how skills are built, its always been thus in such
| environments, and thats ok.
| hu3 wrote:
| Sorry but employees are not entitled to get paid to learn
| whatever technology they want during work.
|
| And I say that as an employee.
|
| There's some flexibility to choose tooling but with autonomy
| comes responsibility.
|
| Replacing a bunch of working Python scripts with Rust is not
| just irresponsible, it's disrespectful and isolating towards
| coworkers.
| mellosouls wrote:
| _Sorry but employees are not entitled to get paid to learn
| whatever technology they want during work, in their own
| special ivory towers._
|
| rather different to my
|
| _While they should get wider buy-in first then if the
| choice is technically justified within reason, its
| perfectly appropriate_
| hu3 wrote:
| My point is about this:
|
| > No competent dev will accept their skills atrophying
| due to overly rigid political/tech choices.
|
| Competent dev to me is one that delivers value. I say
| that as a dev but I'm pretty sure stakeholders would
| agree.
|
| It's perfectly reasonable to hone your skills outside of
| paying hours if you chose to expand to new technology
| outside of your employer's stack.
| mellosouls wrote:
| Fairer, but that's probably the point and tone you should
| have quoted with then. ;)
|
| I would probably concede that it depends on context - for
| devs paid at the top of the market to simply churn stuff
| out factory-style there is less justification for self-
| improvement on work time.
|
| For the majority though there is always give and take
| between responsible employees and employers, and building
| skills as discussed is normal.
| whatshisface wrote:
| You're not likely to be paid top of the market at a firm
| whose biggest concern is that you might be more flexible
| and a faster learner than anyone else they were able to
| hire.
| givemeethekeys wrote:
| No one has the "right", as you put it. The learning of and
| using Rust was approved by the employee's superiors.
|
| If anything, companies expecting employees to know their
| specific tech stack on day 1 of the job is much less common
| an expectation outside of Software engineering.
| cmatza wrote:
| "competent" is a bit of a word there, there are very few shops
| right now that are willing to hire actually junior rust devs.
| The jobs are out there but they're all for mid level at a
| minimum roles in the Rust ecosystem specifically.
|
| Tons of people would jump ship to be able to use Rust, it has a
| lot of love in the community.
|
| "Being totally unwilling to accept anyone junior, or who is new
| to the stack" is a disease in this industry, and it's really
| apparent when some 200 person+ company is only hiring principal
| level rust devs.
| tokinonagare wrote:
| > some tools were written in Rust. The tools were a re-write
|
| Some memes just write themselves.
| ram_rar wrote:
| > The reality was that these tools were unmaintainable by the
| rest of the company. Only the author "knew" Rust and it was
| hard to justify a new hire Rust developer to maintain this
| small set of tools.
|
| Only If I had a dollar for everytime this happens. Choosing a
| language for the company is a business decision. we have a
| similar issue with Elixir and now the entire team is spending a
| quarter just to get rid of it. For anyone building startup on
| LLMs , this is one killer application I would pay for. The
| generated code doesn't event have to 100% correct, just right
| enough for devs to tweek would go a long way.
| serial_dev wrote:
| While I get most of your points, I believe some companies
| sometimes can or maybe even should experiment with new
| languages, and see what benefits it brings them.
|
| The important part is evaluating the experiment and having the
| courage to say "well that didn't work out, let's go back to the
| original version".
|
| They should have evaluated what is "slightly faster", how much
| money it saves and how much it will cost extra to maintain it.
| cesaref wrote:
| The problem I have with articles like this is that if we were to
| substitute anything in for 'Rust', it would read the same. I
| imagine if they had re-written it in C it would also be better
| than before. If it was an advert for anything, it might be
| chucking away a dodgy prototype and starting again (which is
| surprisingly rare).
|
| Anyhow, on the other side of the coin, it's good to see newer
| languages getting a proper outing in real world situations.
| Proving stuff is 'up to it' can be a bit of a long haul, so every
| data point is useful.
| simon_void wrote:
| > Rust takes longer to write than C
|
| > but spent basically zero time debugging
|
| that's the difference to rewriting it in C
| nicce wrote:
| One could argue that when the program is finished without
| bugs, then it is maybe completed. So does it take actully
| longer to write with Rust?
| pornel wrote:
| It depends how proficient you're in Rust. Once Rust itself
| is not a difficulty for you, there's a lot of productivity
| gained from having a modern language with many
| conveniences, and great tooling.
|
| Rust moves more bugs to compile time, so you will
| technically spend more time getting the code to compile,
| but in my experience in 99% of cases it's a time saving.
| And it lets you be more confident about a program correct
| by construction, rather than merely fuzzed and not observed
| to crash. The 1% of counter-examples is trying to be too
| clever with generic interfaces and hitting Rust's limits.
| culebron21 wrote:
| The author complains there are few developers available to
| maintain Rust code.
|
| I see very few job postings, and almost all of them are either
| cryptocurrencies (I don't want to waste my life on this), or "3
| years professional Rust development in production" (disqualifies
| self-learners).
|
| Given that nowadays most applications are not replied, it makes
| little sense to spend time even browsing the postings.
| rapsey wrote:
| There really is a strange dichotomy. Plenty of Rust developers
| have trouble finding jobs and apparently companies have trouble
| finding Rust developers.
| pytness wrote:
| For being a relatively new language, there are almost no
| "entry level" positions.
|
| Just take a look at https://rustjobs.dev/. Most of them are
| well paid remote jobs, but they are asking for +3 years of
| "professional experience" with rust, "with a proven track
| record of building and deploying production-quality code",
| and more. Hell, iirc, i saw one asking for proof of
| contributions to the rust repo (eg, being a core maintainer).
|
| edit: to be fair, i saw one position a while ago asking to be
| willing to learn rust
| FridgeSeal wrote:
| > For being a relatively new language, there are almost no
| "entry level" positions.
|
| Isn't this a fairly well-known phenomenon though?
|
| - new language makes waves. The people who picked it up
| early do some impressive stuff.
|
| - early early adopter companies either snap them, or
| internally make the choice to learn it too. In turn, they
| do some stuff with it.
|
| - gets a reputation for being the hot new thing. Other
| companies "want in on it"- they want to be able to do the
| fancy cool things the other places did, but they don't have
| the patience, time or culture to grow it themselves so they
| aim to hire out seniors and everyone with lots of prior
| experience. <----- many orgs are here.
|
| - proliferates enough that it's well and truly mainstream.
| Also known as the "hire 1000 Java devs and throw bodies at
| stuff" stage of hiring and availability. Python, Node,
| Java, PHP, etc are here.
| IshKebab wrote:
| Yeah though bear in mind most job requirements are really
| job desirables. No skilled jobs say "0 years experience, no
| track record required".
|
| Asking for proof of contribution to the Rust repo is insane
| though.
| yawpitch wrote:
| This sounds like a matchmaking problem that could probably be
| solved by a competent Python developer, if we can find one.
| Seattle3503 wrote:
| As someone who has been searching for a Rust job lately, few
| rust roles are _only_ Rust. Many are Rust + another niche
| domain.
|
| - Must have 5 years of Rust and 8 years of embedded experince
|
| or
|
| - Must have 5 years of Rust snd 10 years of writing SQL
| engines.
|
| or
|
| - Must have 2 years Rust experience and 5 years with Linux
| kernel development.
|
| etc...
|
| If you are looking to hire someone with specific domain
| experience, it makes more sense to compromise on the Rust
| language side of things. A developer can learn Rust on the
| job, but it is harder to learn to write a production SQL
| engine on the job. But that means you aren't hiring Rust
| devs.
|
| Developers who just specialize in Rust are behind their peers
| who are domain experts when it comes to looking for a job.
|
| IMO that means Rust will "win" not when a bunch of
| undifferentiated developers learn Rust, but when the domain
| experts learn Rust. e.g. Kernel maintainers.
| netdevnet wrote:
| Salary and job conditions. Companies want low salary and
| worse conditions. Candidates want the opposite. An
| equilibrium is not necessarily reached
| nicoburns wrote:
| > 3 years professional Rust development in production"
| (disqualifies self-learners).
|
| It doesn't necessarily. Very few jobs postings that require "N
| years of experience in language A" actually require that. Most
| will accept N years of total experience and some smaller amount
| of experience (not necessarily professional) in language A.
| rty32 wrote:
| Chances are that recruiters just ignore your resume without
| even thinking about it.
|
| Especially if there are other candidates who _do_ have that
| much experience in a specific language. Even if you are a
| better candidate overall (whatever that means), you need to
| pass the resume screening first.
| nicoburns wrote:
| > Chances are that recruiters just ignore your resume
| without even thinking about it.
|
| That's why should always try to avoid recruiters and apply
| direct if possible!
|
| > Especially if there are other candidates who do have that
| much experience in a specific language.
|
| True. But the context of this discussion is that there are
| not very many candidates with the (nominally) required
| experience (i.e. several years of professional Rust
| experience). And that's often the case as job specs often
| have unreasonable requirements.
| _proofs wrote:
| this is the ideal but does not appear to really be the
| practice -- regardless of whether you're applying direct or
| not.
| DecoySalamander wrote:
| Solvable by launching your own startup, using rust and running
| it for 3 years.
| EasyMark wrote:
| I see postings occasionally for FAANG and Microsoft jobs, and
| very randomly and rarely from small shops.
| blae wrote:
| I hate how prevalent AI "art" has become on articles like these.
| augustk wrote:
| https://www.reddit.com/r/Phobia/comments/webj9b/ai_generated...
| ndndjdjdn wrote:
| It is soo cheesy. The crab is even pulling a YT thumbnail face.
| myrmidon wrote:
| A very important point that the article neglects is that for a
| lot of embedded platforms, you have to heavily rely on the
| hardware manufacturers libraries and tooling. All of that stuff
| is typically gonna be targeted at C.
|
| Without this, using even very simple hardware interfaces (like an
| SPI/I2C bus) is gonna be a huge pain, because you'll have to comb
| through reference manuals and register descriptions for your
| processor and piece everything together yourself instead of just
| calling a few API functions (this is also very error-prone and
| using Rust is not really gonna help one bit).
|
| The only chance to get even halfway decent rust integration is to
| pick one of the like 3 most popular hardware platforms among
| hobby enthusiasts (think ESP32, raspberry pico), which is simply
| not viable for a LOT of embedded applications.
|
| So I still think its probably a really bad idea for a typical
| embedded-shop to fully go for rust right now-- the downsides from
| lacking tooling/libraries, reduced developer pool and the need to
| train extant devs appear very hard to overcome to me.
| alex_suzuki wrote:
| Not a Rust dev, but couldn't you use FFI to call the C routines
| from Rust? Of course you'll have glue code which is seldom
| pretty, and depending on the amount of Rust actually involved
| at runtime it might be questionable to do in the first place.
| myrmidon wrote:
| Absolutely! But this is a huge amount of complexity in build
| system/linker setup/debugger that you are gonna have to stay
| on top of. The gains from using Rust need to be overwhelming
| to justify a setup like that.
|
| Also consider that calling those FFI APIs from Rust is not
| gonna do anything for you by itself-- you are basically just
| calling C functions with extra steps... To actually get
| anything out of it, you'll then likely have to wrap the whole
| hardware interface in a "rustified" API (which, again, you'll
| probably have to write and maintain yourself...)
| acomjean wrote:
| Many years ago, our project had a library that would link
| our Ada code to the low level operating system calls that
| are in C (network, shared libraries etc).
|
| Once it was written the code was stable, but you bring back
| not so pleasant memories of building / testing. It might
| just be our make files were unnecessarily complex or we
| were building libraries not executables...
| leoedin wrote:
| > A very important point that the article neglects is that for
| a lot of embedded platforms, you have to heavily rely on the
| hardware manufacturers libraries and tooling. All of that stuff
| is typically gonna be targeted at C.
|
| If you have a reference implementation in C it's not such a big
| job to set up something like an I2C or SPI peripheral. At it's
| core, you're making a sequence of writes to some memory
| locations. Most of the manufacturer libraries are quite low
| quality, and very easy to misuse. In my experience trying to do
| anything that pushes the hardware, you will end up combing
| through the reference manuals anyway.
|
| I've done a bit of embedded rust, and the huge benefit - just
| like on desktop - is that code which compiles tends to do what
| you intended. Obviously there's still scope for logic errors,
| but that takes away a huge amount of debugging time.
| danhor wrote:
| For some complex peripherals (especially wireless) this may be
| the case, but in my experience it's often much easier to write
| small abstractions for what you need in the mode you need it in
| (for serial, timers, IO, DMA, ...) than relying on manufacturer
| SDKs, which are often so poorly documented that you need the
| reference manual anyways to understand the peripheral to then
| understand the abstraction, which is often much more complex to
| use than it needs to be for my use cases. With abstractions in
| Rust or, for something quickly thrown together, in uPython
| you're at least getting "you're holding it wrong errors".
|
| Interfacing with the peripheral registers themselves is also a
| bit simpler with Rust in my experience, as a proper .svd
| already contains bitfield setups with enums and R/RW/W1
| information to at least set the bits you want instead of the
| Macro-Hell in C some manufacturers throw at you.
| stefan_ wrote:
| The irony in this article is that even the much lauded ESP32
| integration is essentially all of the important stuff like WiFi
| continuing to run and live in the C world, while they have a
| little Rust frontend for all the hipsters to believe their
| great bugfree Rust code is making the world spin.
| vvanders wrote:
| Even with the vendor libraries last time I had to poke at a CAN
| bus I ended up having to go to that same level because the C
| helper libraries omitted key features of the interface.
|
| There's a number of micros these days where the same libraries
| are provided using SVD[1] that will generate interfaces which
| is handy.
|
| [1] https://docs.rs/svd2rust/latest/svd2rust/
| wyager wrote:
| Rust solved this by autogenning code from mfgr published device
| xml descriptors. Eg https://embassy.dev/
|
| Better than any C(++) embedded hal I've used
| EasyMark wrote:
| I think it's a pretty mixed bag, but yeah no one really has a
| lot of support for rust, but c++ support is quite common and
| "good enough" for lots of things where you'd like more
| complicated but zero-cost abstractions. RAII, getting rid of
| pointers, maps, vectors, etc
| Do123 wrote:
| Didn't they just have a shitty implementation written in C (could
| have been any other language...it's not the language!) and than
| learned from the past mistakes and written a new implementation
| in Rust(could have been any other language)? And now the author
| tries to attribute it's success to Rust?
| alex_suzuki wrote:
| Maybe. But them the dev wouldn't have been able to add
| ,,Completed a migration of legacy C codebase to Rust with zero
| issues in production" to their resume. Also might have been
| easier to get budget for ,,build something new to replace old
| thing" than ,,fix pesky bugs in somewhat-working existing
| thing".
| diggan wrote:
| Not to mention it could also be more fun, something that
| sometimes can be more important than we think :)
| alex_suzuki wrote:
| For the dev, absolutely:)
| zifpanachr23 wrote:
| Given the difference in availability of jobs and the amount
| of code out there, unless you are working in startup world or
| on web dev, this would be a major red flag on a resume in a
| lot of cases. Even the use of the word "legacy" is a problem.
| Like, this isn't "legacy" you asshole, this is our companies
| highest revenue product with a decade of hard work behind it
| and we don't want somebody that is going to be constantly
| trying to shill rust when we hired you to help maintain an
| important C codebase that is part of the foundation of the
| business. We need you to get good at C, despite all its flaws
| and issues, not complain.
|
| This kind of attitude only works in an exceedingly small part
| of the software world that just happens to be
| disproportionately represented on sites like HN. Elsewhere,
| it's not a good luck to be using words like "legacy" on a
| resume without a lot of explanatory text about why exactly it
| really was legacy and deserved a full rewrite.
| ryandrake wrote:
| "Legacy" is just the tech industry's passive aggressive
| euphemism that means "it's old and I haven't learned how it
| works."
|
| I have the same sense as you: when someone tells me they
| rewrote their company's "legacy" code, my spidey sense
| perks up. Now I'm wondering if there was really a good
| reason or if he just refuses to learn an existing code
| base.
| pornel wrote:
| I've done many rewrites of C in C, and C in Rust, and there is
| a big difference that is directly attributable to Rust.
|
| The safety of references, no raw malloc, no null pointers,
| compiler-checked thread-safety of types, consistent and
| enforced error handling help a lot to make robust programs, and
| allow making bigger refactorings without fear of screwing
| something up.
|
| The Turing Tarpit means that theoretically everything you can
| write in Rust you could have written in C, but in practice Rust
| enables things that wouldn't be worth the risk/effort in C,
| even when doing a ground-up rewrite.
| skwee357 wrote:
| As someone who is using Rust in production for a year now [0],
| albeit in a different industry -- webdev, I really like the
| language. Sure, the first steps were rough, but eventually DX
| became decent, and the safety guarantees of Rust allow me to have
| a safe mind when developing and deploying (something I can't say
| about other popular dynamic languages).
|
| Having said that, I agree with one of the commenters in this
| thread: Rust is essentially a solution looking for a problem. It
| is a great language, but it fails to find its niche. Rust
| developers are nowhere to be found, companies are not hiring Rust
| developers (except if you want to work in crypto).
|
| [0]https://yieldcode.blog/post/one-year-of-rust-in-production/
| wanderingbit wrote:
| It has definitely found a niche in the crypto space,
| specifically with the node clients and the underlying new
| cryptography libraries they use. For instance, the more
| efficient Ethereum devs can make their node clients, the
| cheaper it is to run and the more people around the world can
| run it, which increases decentralization. Rust makes this
| possible without compromising on stability and maintainability.
| skwee357 wrote:
| The problem is that I still see all crypto as "scam", thus
| choosing Rust makes a non-viable choice for career
| progression. But I don't care about career progression
| anymore, so :shrug.png:
| physicsguy wrote:
| There's a guy who I work with who went to work for a crypto
| place that then exploded (as they all tend to do). He had
| quite a difficult time finding a new position, and was
| asked multiple times about working for a scammy company. So
| perhaps don't underestimate the negative effect it can have
| career wise...
| kalaksi wrote:
| I think it solves many problems regarding safety in lower level
| languages and with some great language features, so I can't
| really understand your take. Sure, C++ is more established with
| the benefits that entails, but that's not because of the
| language.
| skwee357 wrote:
| I don't disagree with you. My comment was merely to agree
| with another commenter who said that there is a catch-22:
| Rust developers can't find jobs, while companies who are
| looking for Rust developers can't find candidates, because
| Rust can't really find its place in the industry outside the
| crypto world.
| kalaksi wrote:
| Ah, right! I think rust will find more use but it takes
| time. Many existing technologies and languages are probably
| good enough for most suitable projects with historical
| baggage. Maybe crypto industry is just in a good position
| to try new, safer languages for new projects, who knows.
|
| Nowadays, Linux kernel also has some drivers written in
| rust so I'm hopeful.
| pornel wrote:
| If you wouldn't write your program in C or C++, then it's not
| the problem that Rust is trying to solve.
|
| Rust has some nice high-level features and tools, so it gets
| used in other areas like web dev too, but in the end, it is a
| systems programming language. It is a low-level language, even
| though it may not feel like that a lot of the time.
| skwee357 wrote:
| I disagree.
|
| Let's say I want to use a real type-safe language to write
| web applications. So rails/python/JavaScript/php is out of
| the window. I'm left with two big options: Java/Kotlin and
| C#. If I want to avoid Microsoft, I'm left with Java. And in
| fact, this is the industry standard for "real" web
| development: financial, enterprise, etc.
|
| But Java is cumbersome. It's very
| `FizBazBarFooAbstractInterface` type of cumbersome. Kotlin
| makes it nicer, but Kotlin didn't get much adoption in the
| web industry. C/C++ is too low level for web development.
| Rust is the perfect language, in my opinion of course, to
| fill this niche.
|
| Oh, there is also Go. Which is, by the way, also a system
| programming language. But nobody argues that Go shouldn't be
| used to write web services.
| baq wrote:
| Please excuse me for pointing out you don't disagree with
| the post you're saying you're disagreeing with.
| skwee357 wrote:
| My disagreement was referring to the statement that Ruts
| should be used only in-places where you'd consider C/C++.
| creata wrote:
| Besides popularity (not denying that popularity is
| important!) is there a reason you'd prefer Rust over OCaml?
| skwee357 wrote:
| Never considered. I grew up coding in C, so always wanted
| to come back to something similar. After being spoiled by
| PHP/JS, couldn't go back to C/C++. Rust offered me a
| modern, C-like language, so I just learned it and applied
| forcefully wherever I could.
| creata wrote:
| Makes sense, thanks.
| wyager wrote:
| The niche is anywhere C or C++ is used, which it excels at
| nsoonhui wrote:
| I'm ignorant about Rust, but to me it's just static type language
| akin to C#. And C# has IOT library which seems to target Rust
| most usual use case, namely on embedded platform. C# also has
| memory safety just like Rust.
|
| So why do we need Rust at all? What's the use case for it?
|
| Anything that I'm missing?
| 15155 wrote:
| > Anything that I'm missing?
|
| C# is garbage collected. This is a no-go in many/most embedded
| software applications.
|
| C# also grants you poor explicit control over heap/stack
| allocation: this is essential for embedded development.
| nlitened wrote:
| Is it really true though? I don't have much knowledge about
| embedded development, but as far as I know, Java has been
| used in many embedded systems, and was running on phones'
| SIM-cards. Please correct me if I am wrong.
|
| I think that most modern embedded systems are nowadays more
| powerful than my first desktop computer -- is it really still
| worth for the majority of embedded projects to count every
| byte at the expense of developers' productivity (and overall
| project success, as a result)?
| leoedin wrote:
| SIM cards are a weird exception because they have a
| hardware computer designed to run a subset of Java.
| Normally Java compiles to a bytecode which is run by the
| Java VM - in SIM cards the VM is a hardware implementation
| of the Java VM. That's super uncommon - most processors in
| the world have a different instruction set, like ARM or
| RISC or x86. Java can't compile to instructions in those
| languages. Rust can.
|
| Yes, you can run a VM on one of those processors in which
| you run a language like C# or Java. Look at MicroPython as
| a successful example. But the code which runs that VM has
| to be written in something. Typically that has been C and
| C++ - but Rust can also do it.
|
| You're right though - a lot of what we call "embedded
| computing" could be done using a modern VM interpreted
| language. There are some languages out there - MicroPython
| and Squirrel come to mind - which can run on the memory and
| storage constrained environment of a microcontroller. The
| mainstream implementations of Java and C# use way to much
| memory - they've been optimised for desktop environments.
| Microcontrollers often have 64 - 1024 kB of RAM.
|
| You could ship products with application processors like
| the Raspberry Pi, running an OS, and write your application
| in whatever language you like. But that costs 1-2 orders of
| magnitude more money. A cheap microcontroller is $1. By the
| time you've added the RAM, flash and supporting power
| rails, a cheap application processor is $10+. Then you have
| to maintain an OS - that's a lot of engineering time.
| Sometimes it's worth it, sometimes it's not - the tradeoff
| depends on the product.
| psychoslave wrote:
| Not sure how well it fits reality, but it's also to a large
| extend how dramatic can be the result of a fault of your
| system.
|
| If it's embedded in a coffee machine, maybe all cost-
| effective taken into account it's ok to have an over-
| bloated software stack maintained by the cheapest folk the
| manager could found.
|
| Now if you are working on embedded software for some
| vehicle like a critical part of a car, a train or a
| spaceship, considerations of safety for both ethic and
| legal reasons might lead to different tradeoffs and
| conclusions.
| unnouinceput wrote:
| I would argue that using JSON in embedded, especially on
| ESP32, is another no-go. I'd wage that using a binary format
| and later on, after you're out of ESP32, convert it to JSON
| would be a bigger performance gain than the evangelic tone of
| this article vis-a-vis of Rust.
| neonsunset wrote:
| C# is the language with the _best_ degree of control over
| allocation among all GC-based languages. You can write code
| that is completely allocation-free including abstractions.
| Most "data processing" APIs in the standard library do not
| allocate at all or allocate once for initializing e.g. lookup
| tables.
|
| The actual issue is existing selection of runtimes for
| embedded platforms is limited: https://nanoframework.net/ and
| https://www.wildernesslabs.co/device (to be fair, a friend of
| mine uses the second one for automating his lab for his
| microfluidics devices research project, so it _is_ useful).
| 15155 wrote:
| > C# is the language with the best degree of control over
| allocation among all GC-based languages.
|
| It's the best, but if I can't say: "never heap allocate
| under any circumstances," it's a problem.
| neonsunset wrote:
| You can :) It just requires going out of your way a bit.
| It effectively works as C with better type system and
| generics (C++ lite if you will), that can be either JIT
| or AOT compiled (statically linked too). For example
| https://github.com/bflattened/bflat has a target flavour
| that does not support GC at all.
|
| I'm not saying it's an optimal choice for embedded, only
| pointing out that you can write allocation-free code with
| confidence. Patterns that allocate are known -
| predominantly boxing and closures. You can easily avoid
| both, you can also declare your structs as 'ref struct'
| which completely prohibits placing them on the heap,
| either as a box or as a part of heap-allocated memory
| inside some other object/struct.
| leoedin wrote:
| Rust compiles to native machine code. C# compiles to bytecode
| which runs in a runtime environment. That adds a huge amount of
| overhead, and means you don't have direct access to the
| hardware registers. The .net IoT framework is targeting
| computers running operating systems.
|
| When you compile rust for an embedded target it's running "bare
| metal" - there's no operating system, the microcontroller
| literally just starts running the instructions your compiler
| put at memory address 0. If you want anything an operating
| system offers - task scheduling, memory allocation, file system
| access, network access etc - you have to compile it into the
| binary that's loaded into the microcontroller.
|
| Only languages which compile directly to machine code are
| really suitable for that - C, C++, Rust (plus a long list of
| less common ones - this list of languages which can compile
| using LLVM is a good place to start https://github.com/learn-
| llvm/awesome-llvm?tab=readme-ov-fil...)
| neonsunset wrote:
| - https://nanoframework.net/
|
| - https://www.wildernesslabs.co/device
|
| Here are examples where C# is successfully used as a language
| for an embedded target.
|
| In addition to that, compiling to bytecode is just one way to
| execute it out of many, and the statement does not correspond
| to reality. I'm not arguing C# is a good language for IoT.
| I'd personally use Rust for that in almost every situation,
| but the amount of false claims in this discussion is
| disheartening.
| lionkor wrote:
| You're missing that Rust has safety in terms of multithreading,
| which C# doesn't have. Writing a data race in C# is the
| default, writing thread safe code takes work. In Rust, the
| default is that it's safe, you have to jump through a lot of
| hoops to try to make it not thread safe. The same is true for
| async, which in C# is also a problem.
|
| In all C# codebases I've seen, you have threads and tasks, and
| you often run into multiple threads or tasks holding a mutable
| reference to the same data. That's not legal in Rust without
| synchronization/locking.
|
| If you don't believe me, just spin up a new main.rs file and
| write code that has a data race.
| neonsunset wrote:
| This was recently discussed:
| https://news.ycombinator.com/item?id=41801124
|
| While it is true that Rust is a strictly superior option for
| highly concurrent systems code, it still leaves areas where
| you can make a mistake regarding lock management and other
| advanced forms of synchronization.
|
| In addition to that, .NET as platform is fairly tolerant to
| misuse and calling the code that is not thread-safe from
| multiple threads concurrently usually leads to logic bugs or
| "stop modifying this collection concurrently, please"
| exceptions but not to catastrophic memory safety issues like
| it happens in C/C++.
|
| You can read more on its low-level memory model here: https:/
| /github.com/dotnet/runtime/blob/main/docs/design/spec...
|
| > The same is true for async, which in C# is also a problem.
|
| Now, this one is strictly not true. Async primitives are
| thread-safe. In Rust, you _must_ synchronize because at the
| very least you must deterministically deallocate memory used
| by shared state between the tasks. In C#, this complexity is
| handled for you by a GC (ironically, you get negative
| sentiment towards async from people having experienced Python
| 's async or Rust's async complexity, assuming the same
| applies to C#). In some scenarios, it is also a throughput
| optimization since it reduces memory contention by not
| modifying the cachelines shared between the cores, lending
| itself into better performance on many-core systems - the
| memory is modified/reclaimed when it's no longer in use,
| while the actively shared data is placed elsewhere.
| throwawaymaths wrote:
| Easy. Decide to use an ecs system because of its lower memory
| footprint. Pass around integer indices. Use two threads. Data
| race.
| fwip wrote:
| I think the thing you're missing here is that "Internet of
| Things" usually means machines way beefier than "embedded."
|
| IoT is roughly equivalent to a Raspberry Pi - the thing will
| usually have an operating system that you're running on top of,
| and most of your existing knowledge about computers will port
| over.
|
| Embedded is the chip in a happy meal toy, or your microwave in
| 1995. There is no "operating system." Your code is the only
| code running on the machine.
| buescher wrote:
| That kind of embedded work, like connect-the-dots pcb layout
| work, went overseas 15-20 years ago. The typical new embedded
| project in the US today has minimally a not-particularly-
| resource-constrained 8-bit processor with gobs of fancy
| peripherals, something like the PIC Q10 series or the ST
| equivalent. The median would be a 32-bit ARM Cortex M.
|
| Typical IoT SoCs are a step up from that but it's not huge.
| The ESP32 is pretty representative but there are significant
| other options - see what Amazon supports in FreeRTOS as a
| starter.
|
| It's a big leap from small IoT SoCs to SBCs like the Pi.
| goodpoint wrote:
| Really? https://join.com/companies/stabl/12642327-initiative-
| applica...
| goodpoint wrote:
| > Since Rust, and especially embedded Rust (lots of FFI &
| unsafe), is quite hard to learn, it is not viable (for us) to
| retrain a C developer to Rust.
|
| Rust does not need a phd in quantum physics. Anybody can learn it
| with a bit of patience.
| pixelfarmer wrote:
| I remember looking into Rust for a personal project, on embedded,
| in 2016. After poking through all of it I decided against doing
| that because it was clear I'd be spending a lot of time getting
| Rust working at all instead of doing anything for the project
| itself. So C it was.
|
| The thing I have to say in the context of the article is this:
| There is no way to know whether a complete rewrite in C would
| have yielded similar results to Rust. The phrase "C prototype"
| made me squirm, even more so when reading that in the context of
| critical infrastructure. It is known by now (or should be) that
| such prototypes live on like zombies, so unless it is really some
| throwaway (from the point of architecture!), these things tend to
| live on for longer than most feel comfortable with. And, being so
| critical in function, maintainability is one of the primary
| concerns.
|
| Yes, Rust will, eventually, at some point, maybe? the go-to
| language we use in the embedded field, but we are talking not
| just about a language replacement, we are talking ecosystem
| replacement. That is not going to happen overnight.
|
| That said, as some mentioned Java, Perl, and such things: I
| revived a personal Perl 5 project not too long ago that was more
| than 20 years old by that point. Needed a small change because
| the latest installment of Perl 5 is a bit more restrictive with
| some borderline syntax things (good), but other than that it just
| worked. In the larger context of the project there is also some C
| code for binary file processing, also >20 years old. Needed a
| renaming of a POSIX function (arguments and functionality all the
| same, though), and then it worked, even compiled as native 64 bit
| code. Granted, there are not that many dependencies beside POSIX,
| and the code was even back then written to a level of quality
| that allowed it to run on all sorts of (POSIX) platforms already.
|
| Which is why "C prototype" sounds to me like "we cobbled
| something together", and all sorts of bugs are no surprise then.
| You can cut only so many corners before it becomes an issue,
| especially in software that is used all the time and in a
| critical place of a system. This needs to be done right, else you
| will waste a lot of time (and money!) afterwards.
| lnsru wrote:
| Imho Rust will be not much further in embedded world in 2026
| than it was in 2016. I managed to get in the role where I have
| hiring decisions to make. From this perspective I need somebody
| to be able to work with existing projects in C from the 2006
| instead of knowing cool new language. There is no single
| advantage for a company selling products to change the language
| used. Transition will only cost money.
|
| Regarding C prototype. I wrote it. 6000 lines of code, works
| nicely, 4200 lines of code were Xilinx driver calls to move
| data between the hardware blocks. So changing the language will
| not really bring any benefit. Maybe even opposite - one must
| study the register calls and read data sheets to create
| equivalent functions in other language. The code wasn't
| beautiful, was created as "prototype" and was at the end the
| version shipped to a client.
| wyager wrote:
| I made this with rust in 2020 http://yager.io/vumeter/vu.html
|
| The embedded rust ecosystem has invanced a pretty insane
| degree since then. I have an ongoing embedded project and I
| have had to use C FFI calls a total of zero times in a
| ~100kloc codebase. There are native rust HAL libraries
| autogenerated from manufacturer published device specs that
| are insanely good, and take advantage of rust type system
| features to offer vastly superior APIs compared to mfgr
| provided C libs
| jnordwick wrote:
| TL;DR we had some buggy C code and fixed the bugs then rewrote it
| in Rust and wow we didn't have as many bugs... that we already
| fixed.
|
| Rewriting something is not the same as the first effort. Try
| green fielding see how long it can she develop it once you
| already had the first basic C code it's pretty trivial to convert
| it to rust most of the time especially just using other
| libraries.
|
| And imagine that. You fixed all the bugs in the prototype and the
| second rewrite didn't have as many bugs. That's his nothing about
| the second versions language it just says you fixed all the bugs
| in the prototype.
| dextrous wrote:
| I am a C/C++ dev learning Rust on my own, and enjoying it. I am
| finally starting to enjoy the jiu jitsu match with the
| compiler/borrow-checker and the warm "my code is safe" afterglow
| ... but I have a question for the more experienced Rust devs out
| there, particularly in light of the OP's observation about "lots
| of unsafe" in the Rust embedded realm (which makes sense).
|
| If your Rust project leans heavily on unsafe code and/or many
| libraries that use lots of unsafe, then aren't you fooling
| yourself to some degree; i.e. trusting that the unsafe code you
| write or that written by the 10 other people who wrote the unsafe
| libs you're using is ok? Seems like that tosses some cold water
| on the warm afterglow.
| danhau wrote:
| Yes, safe Rust is only as safe as the underlying unsafe code
| is.
|
| The power of unsafe is that it's opt-in, making the surface
| area of ,,dangerous" code smaller, more visible and easier to
| reason about.
|
| As long as the unsafe parts are safe, you can rest assured that
| the safe parts will be safe too.
| iTokio wrote:
| Another way to see the benefit of this approach is that if
| you have a memory violation, then you only have to look in
| the unsafe blocks.
|
| So, yes the less numerous they are, the more you gain from
| it.
| throwawaymaths wrote:
| > As long as the unsafe parts are safe, you can rest assured
| that the safe parts will be safe too.
|
| That is not true. It is possible to have two pieces of
| validated unsafe code that are "safe" in isolation but when
| you use them in the same codebase, create something unsafe.
| This is especially true in embedded contexts, where you are
| often writing code that touches fixed memory offsets, and
| other shared globals like peripherals.
| Ygg2 wrote:
| > If your Rust project leans heavily on unsafe code and/or many
| libraries that use lots of unsafe, then aren't you fooling
| yourself to some degree
|
| That's why every unsafe block needs a SAFETY block.
|
| Is using vec.get_unchecked(6) safe? No. Is it safe for a vector
| that will under all circumstances (i.e. invariant) have exactly
| 64 element. Yes.
|
| As long as for all possible inputs in safe function your SAFETY
| block holds, that code is considered safe.
| n8henrie wrote:
| ESP32. ESP-IDF, not no_std.
| Dowwie wrote:
| If you're going to try using rust for esp32 development, you'll
| use the wrapper libraries that Espressif maintains. When things
| don't work correctly, you'll be dealing with a larger problem
| space as you try to figure out whether the problem is your
| implementation / logic, the lower-level libraries, or the wrapper
| libraries. I don't know what benefits you're gaining using rust
| if you're not using a native rust (to the metal) stack of
| libraries.
|
| If only Oxide found a need for esp32 modules, perhaps they would
| be up for the task?
| priio wrote:
| Has anyone tried Nim in embedded systems? I wonder how it went.
___________________________________________________________________
(page generated 2024-10-14 23:02 UTC)