[HN Gopher] The Adoption of Rust in Business
___________________________________________________________________
The Adoption of Rust in Business
Author : xrayarx
Score : 116 points
Date : 2023-02-07 07:40 UTC (15 hours ago)
(HTM) web link (rustmagazine.org)
(TXT) w3m dump (rustmagazine.org)
| pella wrote:
| backup: https://archive.md/Aiz5q
|
| original markdown version:
|
| https://github.com/RustMagazine/rustmagazine/blob/main/conte...
|
| ---------------
|
| And check the Github issues:
|
| https://github.com/RustMagazine/rustmagazine/issues
|
| check:
|
| - Call for editors #4
|
| - Call for articles #5
| blub wrote:
| Or directly from the source:
| https://github.com/RustMagazine/rustmagazine/blob/main/conte...
| pella wrote:
| Thank you! I found it in the meantime!
| azubinski wrote:
| If someone asks me what "almost perfection" is, I will answer:
|
| "In 2016, Meta (formerly Facebook) adopted Rust as its "new
| secure programming language for blockchain""
| spicyusername wrote:
| 404
| pphysch wrote:
| I would put more money on C++ seeing a resurgence contingent on
| C++ modules getting solid support, than Rust displacing C++ in
| the enterprise.
|
| C++ has a legendary ecosystem, and many great modern language
| features for writing safe maintainable code, but the antiquated
| approach to header files makes it painful to learn and
| unproductive.
| bryanlarsen wrote:
| I'd take the other side of that bet.
| cmrdporcupine wrote:
| Unfortunately I think C++ modules are too little too late. It
| will take a decade for it to propagate fully through the C++
| ecosystem, and even then it will remain fragmented in terms of
| build systems, packaging, coding styles/standards, etc.
|
| I'm not expecting C++ to go away, and in fact I actually like
| working in both C++ and Rust (though prefer Rust) so don't much
| care. But I don't think the addition of modules is going to
| lead to a resurgence in the language overall.
| pphysch wrote:
| Sure, it will take forever for modules to get everywhere, but
| you only need a few solid frameworks/libraries with module
| support for it to matter.
|
| And the big win IMO is just that it makes it easier to get a
| MVP off the ground, whether or not it is backed by module-
| compatible external libraries. The C++ dependency/build story
| is not that miserable nowadays with modern CMake, git
| submodules, vcpkg, etc.
| ZeroCool2u wrote:
| One of primary reasons that Rust adoption has been stifled at an
| org I work with is that the cloud provider we use (GCP) doesn't
| support Rust with client libraries or SDK's. We know there are
| 3rd party providers, but they're not willing to go without GCP
| official support and I can't blame them.
| ekidd wrote:
| Honestly, when we automate GCP from Rust, we use a thousand
| lines of hand-written client code and a normal HTTP client.
| Auth we do using a library.
|
| We've also tried the open source GCP client libraries, but they
| were huge didn't support async at the time.
|
| (Still, I'm much happier hand-rolling some HTTP wrappers than
| using the official Google Python bindings. Those pull in tons
| of fragile dependencies.)
| lucidguppy wrote:
| http://scihi.org/frederick-great-potato/
|
| To increase rust adoption you need to cultivate FOMO - create an
| aura of "rust is a secret weapon", which it is in certain cases
| (safety critical performant code).
|
| Rust isn't really meant for prototypes. So don't expect Rust
| adoption to be in the range of Python or JS/TS. Expect it to max
| out in C++/Java adoption.
|
| It needs a champion web framework like django, rails, or phoenix.
| Don't give adopters an overabundance of choice, or they'll
| recoil.
|
| It already has a better packager than most languages.
|
| If Rust shows that its 10x better than Java and C++ in terms of
| productivity - it will have no problem getting adoption. Just
| need more promotion on how much easier it is to work with than
| C++
| jeremychone wrote:
| I think Axum has the potential to be the top web framework. Not
| too high, not too low, very well designed and complete, and
| well maintained with healthy momentum. It has become our web
| framework for web services and web app backend.
|
| Not sure we will ever see a "rails" like framework in Rust (for
| the better IMO)
| likeabbas wrote:
| Axum, Tonic, Serde, and Tower are extremely powerful
| together. They make building APIs so straight forward. I do
| wish we could add a few features for free, such as interning
| JSON strings (which you can do easily via a new library) but
| this set up is so pleasant to use that I believe it will stay
| for a long time.
| josephg wrote:
| I've been writing rust full time for the last 2 years, and I'm
| going to make a bold prediction: I don't think rust will
| displace Java at all.
|
| Rust is a gorgeous language and I love it, but it optimizes for
| making good binaries over being easy to learn and use. Java
| shops don't use Java because it's clever, clean or fast. They
| use Java because it's a known quantity, it works, it'll outlive
| everyone and it's easy to hire for. Java is popular precisely
| because it's _not_ new or shiny. Because there isn't a new
| framework every week that you need to learn to stay on top of
| things. Java is a language for late adopters, who said no to
| Scala, Clojure and Kotlin. Why would they switch to rust?
|
| If rust displaces anything it'll be systems languages - C and
| C++ in web browsers, databases, Linux, embedded systems and
| some video games. And safety critical systems like helicopter
| control systems. It remains to be seen if it makes any serious
| inroads in web services. I can still throw web services
| together in nodejs dozens of times faster than I can in rust.
|
| Rust isn't trying to be the world's most productive language.
| Rust would rather complex syntax and fast binaries than simple
| syntax and slow binaries. So it'll always be harder to learn
| than Go, Java, C# or Swift. I honestly think Swift - if it had
| rust's tooling and ecosystem - is a better language for general
| purpose computing.
|
| Rust is a lovely language, but like every other language, it's
| no magic bullet. Add it to your toolbox, but don't throw out
| your other tools.
| zozbot234 wrote:
| Back in the mid-1990s, Java was the first type- and memory-
| safe language to be widely adopted in the enterprise. It was,
| in a sense, the Rust equivalent of its day when compared to
| the previous standard of C++. It may have been a lot slower
| and clunkier than C++ back then or Rust today but this
| mattered less in the 1990s when if anything, its unique
| cross-platform development story would've made it feasible to
| seamlessly deploy it on high-performance servers and midrange
| machines. Sure, today Java/C# are mostly adopted as a matter
| of convenience but this wasn't always the case.
| stcroixx wrote:
| Totally agree. Java shops don't have the memory safety issue
| Rust solves. Without that benefit, why bother switching?
|
| C++ and Java don't overlap much in the domains they're used
| in in my experience. Rust may totally replace C++, where the
| memory safety issue exists and high performance is critical.
| 62951413 wrote:
| I thought Rust was to C++ what Scala was to Java. Which
| implies two communities which don't overlap much. I loved C++
| 20 years ago but I'm not going back to manual memory
| management. I'd rather hold my nose and use golang if the JVM
| languages don't keep me employed anymore.
| zozbot234 wrote:
| Rust is more like Kotlin compared to Scala. Except that C++
| also has plenty of footguns, in addition to the accumulated
| complexity.
| lucidguppy wrote:
| Very good points - I agree. Kotlin and other Java++ languages
| would be their goto rather than rust.
| marcosdumay wrote:
| We need better ABI standards (or any at all).
|
| I do agree that Rust is prone into displacing C (and very
| simple C++, any C++ that needs the ++ part was already
| displaced by now), but I do think it will make inroads into
| plenty of places it shouldn't be. That's because the
| foundational tools will get written in it, and this leads
| people into consuming those tools in Rust code too, to avoid
| incompatibilities.
| allochthon wrote:
| I'm an experienced Ruby web developer, and I'm starting to
| learn Rust. You mentioned Java and Nodejs, but I still wanted
| to chime in on the topic of languages in web development more
| generally, and the applicability of Rust to web development.
|
| After tackling the refactoring of a complex Rails app that
| has a rules processing engine implemented on top of
| ActiveRecord, the true cost of Ruby's lack of static typing
| has become apparent to me. It's clear now that you can get a
| web app up and running quickly in a framework like Rails (as
| one example of a convenient, low-friction framework). But
| once you need to turn it inside out and make significant
| changes to the implementation, you're walking on egg shells
| and relying on previous devs to have built out good test
| coverage. A web app written in Rust would be easier to
| refactor in important ways at this point in the life of the
| app. It is clear there was a cost to using Ruby, but also
| that it was deferred.
| HideousKojima wrote:
| I'll give another reason: the typical Java (and
| JS/Python/whatever) developer doesn't have the knowledge,
| dedication, and interest to learn it. And companies don't
| care about maximizing performance in most cases, they want
| good enough for cheap enough, and a decent Rust dev is going
| to cost more than a decent Java or .NET dev
| zozbot234 wrote:
| Dedication and interest among developers will grow when
| compelling stuff starts to be written in Rust. Same as Java
| in the 1990s, .net, Python and Ruby in the 2000s or JS in
| the 2010s.
| HideousKojima wrote:
| No, I'm saying the typical dev doesn't have any interest
| in learning _anything_ new beyond what they already know,
| and some hot new thing in Rust isn 't going to change
| that. The level of mental effort needed to learn Rust is
| greater than the typical dev is willing to expend on
| anything.
| Animats wrote:
| > (Rust) champion web framework
|
| As I've said before, Go is more appropriate than Rust for web
| back end work. The libraries are well debugged, because Google
| uses them internally. The "goroutine" approach gets rid of the
| thread/async problem. Garbage collection means not having to
| think too much about memory management.
|
| Rust is harder. I write mostly in Rust (36,000 lines in the
| last two years) but for something hard, a high-performance
| metaverse client. It's overkill for your shopping cart.
|
| (I suspect that the next generation of "champion web framework"
| will be something that you talk to in English and it generates
| routine web front and back ends. Probably as a service.)
| eldruin wrote:
| For those getting a 404, here the article in MarkDown:
| https://github.com/RustMagazine/rustmagazine/blob/main/conte...
| [deleted]
| TrackerFF wrote:
| The organization (gov.) I work for recently took over a product
| where the entire back-end was written in Rust. Basically the
| product was developed by a bunch of Rust enthusiasts in a R&D
| group, and the product was wholly financed by gov. grants. When
| that money dried out, they were faced with either just shutting
| it down, or trying to sell or give the product away. Some higher-
| ups decided this could be a great internal tool, and got it for
| free.
|
| The product works great, but the codebase is around 400k LOC of
| Rust, and we don't have any budget to hire Rust developers. And
| when we had a budget in November, it was really hard to find
| anyone local (work requires a high security clearance, and remote
| is not possible for this kind of work due to said security
| issues).
|
| So we're kind of stuck with just keeping it around until better
| times, or just re-writing the entire back-end in something we
| know better. Not to sound like a downer, just an example of what
| Rust adaption could look like from the other side.
| wongarsu wrote:
| Yeah, while there is a decent market of remote Rust developers,
| hiring locally can be very challenging.
|
| Maybe training a C/C++ developer in Rust is an option for you?
| Of course it's not a language you get fluent in in a single
| weekend, but Rust also isn't extraordinarily complex.
| FpUser wrote:
| >"Maybe training a C/C++ developer in Rust"
|
| I think any senior level developer with C++ experience should
| have no problems grasping Rust on their own. Examples and
| docs are plentiful.
| carlmr wrote:
| As a C++ dev that is very Rust enthusiastic. Rust is quite
| easy to learn if you have a decent grasp of C++.
|
| The biggest thing you need to unlearn is the paranoia.
| pclmulqdq wrote:
| And that most things you used to do with pointers (linked
| lists, graphs, etc.) need to be done with something else.
| pkolaczk wrote:
| Typically those things would be enclosed in libraries
| providing safe and convenient APIs. Sometimes you might
| need to use a bit of Rc<RefCell> here and there. At
| worst, you are not any worse than in C++: use unsafe.
| pclmulqdq wrote:
| If I had $1 for every time someone told me that Rust had
| a "safe and convenient" API to do something that I wanted
| to do which didn't actually do the thing correctly or
| conveniently, I would have a lot of money. This line
| really needs to be dropped from the Rust sales pitch.
|
| If I did it myself in another language which also has a
| ton of libraries (eg C++, Java, Go, etc.), there is no
| reason why I would want to reach for a library for that
| piece of code in Rust. There's usually a good reason why
| I didn't use a library.
| adgjlsfhk1 wrote:
| in c++ often the reason is just that c++ dependency
| management sucks
| pclmulqdq wrote:
| I actually don't find that to be the case, since most of
| the things you need are in one of the mega-libraries from
| Google or Facebook and the alternatives are often easy-
| to-find github repos.
|
| The convenience of npm and cargo is offset by the fact
| that the documentation for most libraries is nonexistent,
| the creators inject their idiosyncrasies, and lots of
| library code has not actually been tested very well. Not
| to mention that the dependencies can change for the worse
| underneath you, and if you want the old features you had,
| you have to give up all new developments.
| ReflectedImage wrote:
| You are not suppose to spamming Rc<RefCell> :p
|
| It's called Single Ownership.
| pjmlp wrote:
| Regarding paranoia, it will go well if the C++ developer is
| coming from "security matters", instead of "turn
| performance to 11" mindset.
| jokethrowaway wrote:
| That paranoia is healthy, it gets you thinking about memory
| and efficiency.
|
| You can be inefficient with Rust as well.
|
| The good thing is that you're less likely to get a null
| pointer or other silly mistakes / security incidents
| waiting to happen.
| rowanG077 wrote:
| If you have 400k LOC why are you even considering rewriting it?
| It would take way less time to learn Rust then to rewrite
| something like that.
| gemstones wrote:
| Are you guys C or C++ programmers? (I'm not.) Here's why I ask.
|
| I started with Ruby. Since then, I've branched out to a bunch
| more, including Rust. Most are fairly easy to pick up.
|
| There is, however, a class of languages I'm totally scared to
| try and pick up. They're C, C++, and PHP. It's not because
| they're bad languages, or I couldn't learn them - it's just
| that all those languages have a reputation for making security
| holes easy by default. There will be a learning curve where I'm
| an actively dangerous programmer to be around. I'm gonna just
| stay away.
|
| If I started with C++, and not Ruby - my perspective would be
| quite different. I would assume there are dangerous footguns
| lurking in every other language as well. Learning any language
| would be a scary thing.
|
| I would try to learn Rust. Its compiler won't prevent every bug
| or hole, but it's hard to screw things up as you're learning.
| There's really only one rule, to avoid using unsafe unless you
| really can be intentional about what you're doing. If it's
| uncertainty that keeps you from learning - most languages are
| far more forgiving than what you're used to. And if not, none
| of these points apply, I guess.
| nevi-me wrote:
| That sounds like a good opportunity to learn the language. I've
| had to learn things under duress in my career, often rhat 'low-
| code' platform whose app is now broken or needs some change,
| that COBOL system being migrated, whose rules were written
| before I was born, etc.
|
| Most of what I learn ends up being throw-away, done out of
| necessity. However, I feel like something written in a popular
| and growing language like Rust, with an opportunity to learn,
| maintain, change and improve, would be a net positive.
|
| I'm biased because I learnt Rust in ~2018 and have enjoyed it,
| however if this were say Scala or Go before I learnt them, I'd
| feel the same way.
|
| Yesterday I was in a jam session with a colleague, we
| prototyped something quick and dirty, got it to work, and then
| refactored it into something neat and clean. This was such a
| pleasure, because I feel like the language empowers me to make
| large refactors mostly without introducing breakages (at least
| when you're shuffling code and types around).
| matwood wrote:
| > I've had to learn things under duress in my career
|
| This is how I've learned most things in my career :D
|
| For something like Rust (or other languages like go or objc)
| though, I could see how it would be hard for someone whose
| only background is in js or python. There are concepts
| completely missing or hidden from the programmer that they
| now have to deal with.
| freilanzer wrote:
| > There are concepts completely missing or hidden from the
| programmer that they now have to deal with.
|
| Hence the part about learning.
| ekidd wrote:
| > _I could see how it would be hard for someone whose only
| background is in js or python._
|
| As someone who has trained several Rust programmers, I've
| seen people hit two major snags:
|
| - Like TypeScript, Rust is a strongly-typed language that
| gently encourages functional programming.
|
| - Like C/C++, Rust is a language where you need to know
| about references vs values, and the stack vs the heap.
|
| Someone who's comfortable in TypeScript and C++ will often
| take to Rust like a duck to water. But someone who's never
| called "map" or who has never worked with pointers may take
| longer. A pure C programmer might struggle as much as pure
| Python programmer, just from the opposite direction.
|
| That said, I love Rust precisely because it allows me to
| move between a TypeScript mindset and a C mindset as
| needed. When I want something fast, solid, correct and easy
| to maintain, it's my favorite tool. But for many team
| projects, Rust is overkill--garbage collected languages are
| often perfectly affordable. And there are many excellent
| choices!
| matwood wrote:
| > But someone who's never called "map" or who has never
| worked with pointers may take longer.
|
| When I wrote my comment I was thinking way back to when I
| was in undergrad and pointers were a huge stumbling block
| for many. Maybe things have changed, but if someone
| hasn't had to think about them ever, it could make
| learning a language with explicit pointers challenging.
|
| That's not say people can't learn, I'm just thinking
| about how long it takes someone to get up to speed.
| ekidd wrote:
| > _Maybe things have changed, but if someone hasn 't had
| to think about them ever, it could make learning a
| language with explicit pointers challenging._
|
| To be clear, safe Rust doesn't actually have pointers.
| (Well, it does, but only unsafe Rust can dereference
| them.)
|
| But Rust _does_ have pass by value and pass by reference.
| It has both stack allocation and heap allocation. And it
| has a notion of who "owns" something. These aren't
| technically pointers, but taken together, they're
| basically a safe interface to doing "pointer stuff."
| Conceptually, all these ideas should make sense to anyone
| who has worked with pointers and allocation.
|
| Similarly, Rust allows easy mutable state as long as only
| one piece of code can see the mutation happen. But many
| programmers are used to being able to share mutable state
| between widely separated bits of code. And this affects
| how you design the architecture of your program! Anyone
| who has done functional programming will see the
| implications of this early: "Oh, I need build my
| architecture around immutable state!" So something like
| an old-school game engine where any entity can update any
| other entity is a huge headache in Rust. But a game
| architecture like ECS that carefully restricts mutation
| (like Bevy) works beautifully with in Rust.
|
| I don't want to trivialize this: Pointer stuff and
| mostly-functional architectures are both real skills that
| take time to learn. Rust is amazing for situations where
| you feel torn between TypeScript and C/C++. But lots of
| projects just need a nice GCed language and a good
| standard library, and Rust wouldn't be the right choice
| for many teams.
| mr_00ff00 wrote:
| Never heard this before but will now look out for it.
|
| I was always surprised when people said rust had a steep
| learning curve, yet it seemed relatively easy to pick up
| to me.
|
| My first language in school was C++ and my first language
| on the job was Typescript, exactly as you described. I
| knew both well and then heard about rust and tried it.
| _huayra_ wrote:
| I'm beginning to wonder if it's actually more difficult for
| C++ developers to learn Rust, at least speaking from
| personal experience. There are so many things I want to do
| in Rust when mapping from my C++ knowledge that are
| genuinely unsafe, e.g. copying around reference objects
| (including iterators) but convincing myself through
| rigorous testing that none of them ever dangle despite the
| somewhat unrelated lifetimes.
|
| Perhaps when one isn't trying to map some similar-ish
| knowledge onto Rust it becomes easier, as one doesn't have
| to drop preconceived notions.
|
| This very much feels like the time I tried to snowboard
| after having skied for a couple of decades; why can't I
| move my feet like before?!
| zozbot234 wrote:
| > copying around reference objects (including iterators)
| but convincing myself through rigorous testing that none
| of them ever dangle despite the somewhat unrelated
| lifetimes
|
| The underlying issue with this kind of informal assurance
| is that it may become incorrect in a large-scale project
| as it evolves. This is why "unsafe" in Rust is best used
| locally, as part of something that provides a safe
| interface to the rest of the code.
| nicoburns wrote:
| > I'm beginning to wonder if it's actually more difficult
| for C++ developers to learn Rust, at least speaking from
| personal experience.
|
| It seems to go one of two ways with C++ developers:
|
| - Some C++ developers were alsready hyper aware of object
| lifetimes and were effectively enforcing Rust's
| constraints on their own code manually anyway. They find
| Rust the easiest of anyone
|
| - Some C++ developers were blissfully unaware of object
| lifetimes and played fast and loose with them so long as
| it worked. Those C++ struggle with Rust more even those
| with no previous low-level experience.
|
| > There are so many things I want to do in Rust when
| mapping from my C++ knowledge
|
| As someone who came to Rust from JavaScript, I can attest
| that with a few exceptions the opposite is true for JS
| knowledge: basically everything I was used to being to do
| from JavaScript I can do in Rust.
| marcosdumay wrote:
| Oh, there are plenty of idioms you can use in C++ that
| are easy to make safe (as long as you don't make a
| mistake on some very small amount of code) that Rust will
| make a nightmare to implement.
|
| Just like there are plenty of idioms you can use in
| Haskell that are easy to make simple that Rust will make
| a nightmare to implement.
|
| At the end of the day, Rust is neither of those. It is a
| safe low level language, and that comes with plenty of
| restrictions. The language is amazing for how little
| restrictions it actually has when compared to a naive
| estimate, but there are still plenty of them.
| zozbot234 wrote:
| The problem is that very few idioms are both safe and
| _compositional_ (which you need if you want your
| development approach to scale to the largest projects).
| Rust focuses on these as a sensible default, for
| everything else there 's unsafe.
| Ygg2 wrote:
| > Oh, there are plenty of idioms you can use in C++ that
| are easy to make safe (as long as you don't make a
| mistake on some very small amount of code) that Rust will
| make a nightmare to implement
|
| Like? I know double linked lists and graphs are harder to
| get right, but aren't impossible.
|
| But on the flip side getting Optional and Send/Sync to
| work in C/C++ and not to rely on people using best
| practices is downright impossible.
| nevi-me wrote:
| The simpler parts of Rust feel like TypeScript, let's say
| as long as you're doing simple things as a start and don't
| worry about threading.
|
| Rust was probably also a lot easier to learn pre-async-
| await, because one would have to explicitly opt in to
| multithreading through std::thread.
|
| My first productive language was JavaScript via NodeJS (I
| learned PHP first, but it was a mess). I did so much with
| it that by the time I learnt other languages on my own, it
| was out of necessity.
|
| From a language syntax and concept angle, I'd say Java +
| Scala were difficult to grok at first. Java for the
| boilerplate, Scala because I could never understand what
| the underscore is for.
|
| Kotlin became a breeze and pleasure, then Rust after that.
| I learnt each language by converting my projects from a
| previous language to a new one. So that helped me limit the
| concepts I'd introduce.
|
| Mostly do some calcs, interact with a DB and expose stuff
| via gRPC. By the time I started with futures, channels and
| threads, I had gotten far enough programming against a
| single core.
|
| I often advise people starting out to be gentle with
| themselves and stick to what they know first. Like other
| complex languages, one might remain a learner for very
| long.
| Animats wrote:
| > Rust was probably also a lot easier to learn pre-async-
| await, because one would have to explicitly opt in to
| multithreading through std::thread.
|
| Worse, you can use both in the same program, which, while
| safe, is really complicated.
|
| There's a lot to be said for Go's green threads for
| routine web back end stuff. They avoid the async/thread
| distinction, because they're both lightweight and can
| block.
| jackmott wrote:
| [dead]
| MuffinFlavored wrote:
| > The product works great, but the codebase is around 400k LOC
| of Rust
|
| At a high level, what does the codebase do that it took 400k
| LOC? CRUD REST endpoints? /s
|
| How long did it take how many engineers to end up with 400k LOC
| codebase?
| xwolfi wrote:
| Yup it's why the language shouldn't be too integrist with its
| theories or too particular with its syntax, because when time
| comes to find an intern to survive a few month and they're all
| swimming in Java and Javascript, you're fucked and you cant
| even beg a C/C++ oldie to come out of retirement.
|
| Rust might be okay but even Python I would hesitate. I and my
| team all converted quickly to being efficient java+js+C# devs
| coming from either of each and I cant imagine working in a
| company when not only the business and the tools are
| particular, but the frigging language as well. It's overloading
| for new comers.
|
| And imagine in 20 years, which is the age of the software I
| maintain: you d rather fight a Java or C# spaggheti or a Rust
| spaggheti ? It will be a spaggheti, you can't escape it and
| last 20 years being profitable.
| LoganDark wrote:
| > Rust might be okay but even Python I would hesitate
|
| These languages are not even on the same spectrum.
|
| -Emily
| mderazon wrote:
| From the individual developer point of view, learning something
| new while getting paid for it is the best thing. So if your
| organization is up for it, I would take that chance without a
| doubt.
|
| From the organization POV, yeah that sucks
| IshKebab wrote:
| Just hire C++ developers who want to learn Rust. There are tons
| of Rust developers desperate for non-crypto Rust jobs.
| solidsnack9000 wrote:
| How can I learn more about the project and your situation? I
| use Rust at work and enjoy working with it; I've also done some
| work for .gov in the past and like to see technology projects
| in the public sector be successful.
| rcarr wrote:
| There seems to me like there is a clear third option here which
| is for the organisation to buy an online rust course or select
| some of the (many) free materials online and pay a few existing
| employees (or new employees with previous programming
| experience but no rust experience) to do nothing but study
| those resources for two months before making them the senior
| devs/tech leads of the codebase. What is it with organisations
| refusing to pay to train and upskill employees nowadays? It is
| such short minded thinking to not invest in your own people.
| huijzer wrote:
| How would you like it to hear that you'll be a Rust
| programmer tomorrow if you have been a happy X programmer
| working on system Y for, say, 10 years?
| rcarr wrote:
| Tbh mate I think this is a bit of a daft contrarian take.
| Clearly you would offer it to existing employees to see if
| anyone was interested then, if not, hire new employees like
| I said in the comment. If you've still failed to find an
| employee (who is going to get paid to do nothing but learn
| a brand new language and then be senior dev/tech lead for
| it which would be a pretty sweet gig for a lot of people)
| you would then do the heavy handed approach of forcing an
| employee to learn it. At the end of the day you can't have
| a critical piece of organisation infrastructure completely
| unmaintained and if you have to, then you'll have to strong
| arm someone in to it, but you should always aim to do that
| as the complete last resort. And if you are going to do it,
| you can probably sweeten the deal with a pay rise or other
| perks. But I seriously don't think you'd have to because if
| you were a junior/intermediate dev and someone offered you
| an opportunity like this to both learn a new language
| whilst getting paid and rise a rank in position and
| compensation you'd be mad not to take it.
| karmakurtisaani wrote:
| Sign me up!
| Keyframe wrote:
| Kind of the same as with "here's legacy VB/php/ruby/nodejs
| shit to take care of", but better?
| ekidd wrote:
| Honestly? I do the job that's in front of me. That has
| included everything from pre-STL C++, to 90s-era PHP and
| even Visual Basic for Applications. And a few things even
| more obscure than that.
|
| I do sympathize with agency's situation--I have actually
| put Rust into production and been responsible for mentoring
| programmers to work on it. I like Rust! But I almost
| certainly wouldn't have chosen Rust for a government
| production system without making sure that all the
| stakeholders understood the tradeoffs. Although, it sounds
| like this was an abandoned R&D prototype that was
| voluntarily picked up by another team, so I don't
| necessarily blame anyone involved here.
| brightball wrote:
| Personally, the most important trait I look for when hiring
| programmers is desire to learn. It's a natural proxy for
| both motivation and problem solving.
|
| It's one thing if we are talking about a Dilbert-level "we
| are going to rewrite our system in X" but learning
| something new to support an existing system that performs
| well? At worst it's good resume material and at best it
| should be interesting enough to expand how you think about
| coding.
|
| Not wanting to learn it at all would be odd.
| erik_seaberg wrote:
| I volunteer as tribute. Rust is on the list of stuff I'd be
| excited to learn and use professionally, more so than other
| stuff I've only learned by necessity.
|
| I'm just not sure how often it's worth the effort, compared
| with the runtime cost of GC and immutability or mutexes.
| blub wrote:
| If you look at the Rust community, it's split between those
| that consider Rust appropriate for systems level programming
| and those that want to use Rust for everything. The back-end
| Rust comes from the latter part of the community and my
| impression is that it's fighting an uphill battle, because the
| language is not a good match for such software when compared to
| Java or even Go or Python.
|
| 400.000 lines also sounds huge for a web project.
|
| Contrary to other commenters I don't advise learning Rust just
| for this project. In general maybe it's worth it, but web Rust
| is new, has an uncertain future and likely no job market value.
| If it was a research project there's no telling what horrors
| lie in that code base :-)
| kouteiheika wrote:
| > The back-end Rust comes from the latter part of the
| community and my impression is that it's fighting an uphill
| battle, because the language is not a good match for such
| software when compared to Java or even Go or Python. > >
| 400.000 lines also sounds huge for a web project.
|
| I maintain a 180k+ line of code back-end web project and I
| use Rust. Best decision I've ever made.
|
| I serve over half a millions of HTTPS requests per day.
| Everything hits the backend, no CDNs or caches of any kind.
| Average CPU usage on a cheap VPS? ~3%. Hugs of death? No such
| thing for me. It just runs itself without any supervision for
| months uninterrupted, so I can sleep at night and not get
| woken up by an outage. And refactoring is a breeze due to a
| strong type system, plus all other niceties that Rust has.
|
| So for a complex project that you're going to maintain long-
| term? Rust is absolutely the right choice, even for backend
| web-dev. A throwaway CRUD e-commerce website made by a random
| webdev consulting company on the cheap? Okay, yeah, maybe
| here you're right, and I probably wouldn't pick Rust there
| either.
| pipe_connector wrote:
| 500,000 requests/day is ~6 requests per second.
| goodpoint wrote:
| You could handle that with Ruby on a raspberry 1
| kouteiheika wrote:
| If you're just sending static pages, sure. Not if you're
| doing significant processing like I do. It's also an
| issue of scaling, where I could probably serve at least
| ~1000x more traffic on a _single_ machine (and I know I
| 'll never hit that much traffic). And if you don't need
| high availability (although I haven't had a single outage
| is over two years, thanks to Rust's reliability and focus
| on correctness) this simplifies your architecture and
| your deployment significantly, because now if you're on a
| single machine you don't have a distributed system, you
| don't even need caches, you don't need load balancers,
| you don't need to administer multiple machines, you don't
| need Kubernetes, backing everything up is very easy, etc.
|
| (But of course, I'm not saying this is how everyone
| should do it. I'm just saying what the benefits are _for
| me_ because Rust 's so fast, so it allows me in my
| particular case to do this, which I wouldn't be able to
| do with e.g. Ruby because it'd be too slow.)
| pc86 wrote:
| > _The product works great, but the codebase is around 400k LOC
| of Rust, and we don 't have any budget to hire Rust
| developers._
|
| So learn Rust? You've already said the product works great so
| it doesn't seem like a reasonable rewrite candidate.
|
| The vast majority of software doesn't need to be super cutting
| edge, doesn't do anything particularly difficult, and isn't
| written by geniuses. Honestly, any developer worth being hired
| should also be good enough to pick up another language during
| the work day over the course of a few months.
|
| Rust in particular has a bit of a learning curve, I'll give you
| that (so I've heard, I don't know it well enough to write
| production code in it). But "it's hard" doesn't seem like a
| particularly good reason to throw out a perfectly good 400k
| line codebase.
| goodpoint wrote:
| > the codebase is around 400k LOC of Rust, and we don't have
| any budget to hire Rust developers
|
| That's what you get with hype-driven development.
| exDM69 wrote:
| > Basically the product was developed by a bunch of Rust
| enthusiasts in a R&D group
|
| This is not a great starting point for any project, never mind
| the programming language. It could've been C++ enthusiasts, or
| Haskell, Scala, Lisp or any other language that appeals to
| enthusiastic programmers.
|
| I've recently been involved in two projects with the same
| problem - initially developed by a small team of enthusiast
| level programmers in language X (not Rust). Other people in the
| team (competent programmers) have trouble being productive as
| the enthusiasts had gone to the deep end with language features
| which were not strictly necessary to complete the task at hand.
| kazinator wrote:
| However, according to grandparent, it "works great".
| zozbot234 wrote:
| How does "a small team" end up writing 400k LOC? My guess is
| that the count may be inaccurate - it probably includes a
| whole bunch of vendored code that got added to the project
| because of the high-security environment. Rust and Cargo make
| it challenging to develop a project in a fully "secure"
| fashion, C/C++ has a better story there.
| exDM69 wrote:
| > Rust and Cargo make it challenging to develop a project
| in a fully "secure" fashion, C/C++ has a better story
| there.
|
| Complete absence of dependency management and a myriad of
| incompatible build tools is a "better story"?
|
| You can have this "story" in Rust by just disabling
| crates.io centralized registry. Which still leaves you in a
| better position than C++ because you can use the build tool
| and dependency management locally and do whatever you're
| used to doing in C++ land (put 3rd party code in your repo,
| install them via some other packaging tool etc). Or if you
| insist on going the whole way, you can invoke rustc via
| your favorite flavor of make.
|
| On a more realistic note, if you're working with in a very
| safety/security conscious environment, and still depend on
| 3rd party code: you could set up your local package
| registry and have people vet the 3rd party dependencies.
| Yes, it costs time and money but at least you get the tools
| to do it from the language ecosystem.
|
| I've been professionally involved with the C/C++ way of
| doing things for decades and I find the Rust build and
| dependency management tooling a huge improvement.
| dgs_sgd wrote:
| Would a full rewrite in a language the devs know better
| actually be faster than using that time to ramp up on rust?
| schneems wrote:
| It's a huge learning curve but it's worth it. I came to Rust
| from Ruby and after a few years of practice now I'm at a spot
| where I would generally prefer using Rust over Ruby.
|
| I recommend rustlings for interactive tutorials to do alongside
| the rust programming language book. I also just heard a
| rustacean station episode featuring a pakt author who wrote "
| Rust Web Programming" it sounded good.
| tdudzik wrote:
| Why not just train developers you have instead of hiring new
| ones?
| yazaddaruvala wrote:
| I feel like it took me 2 weekends to "learn Rust" enough to
| make feature changes, and another 2 weekends to really "get it"
| enough to build basic abstractions.
|
| I feel like it would take another week or two to learn some of
| the UnsafeCell/Pin/Generators type stuff, but none of that is
| needed for 95%+ of Rust code.
|
| I think if you and your team just started learning Rust week by
| week, you'd find in 3 weeks that you're equally productive in
| Rust than your current languages. Especially given the code
| base already exists. Even just starting to learn Rust by
| writing tests (if there aren't) would be sufficient to improve
| that system rather than wait to hire or re-write it.
| ekleraki wrote:
| I'd add that this is a great opportunity for OP to treat it
| as akin to "rustlings" or a possible analogue, where they
| break different functions that they know work, and building
| it up again s.t. the tests pass fine.
| bin_bash wrote:
| As a counterpoint, I'm a senior engineer at FAANG with 15
| professional YOE. I've mostly used scripting languages in my
| career though.
|
| It took me probably more like 1-2 months to really understand
| how to code in Rust. I do not think a typical team of
| JS/Python devs would be productive in 3 weeks. I think it
| would be more like 3 months. Developers with C++ experience
| seem to pick it up much quicker.
|
| Also, at this point I'm pretty proficient in rust but I'm
| still far slower than I would be in a scripting language. So
| I don't think anyone would ever reach "equally productive"
| unless they're comparing themselves to another compiled
| language.
|
| I like Rust, but it's challenging, and it's certainly not a
| language for rapid development.
| LoganDark wrote:
| > It took me probably more like 1-2 months to really
| understand how to code in Rust. I do not think a typical
| team of JS/Python devs would be productive in 3 weeks. I
| think it would be more like 3 months.
|
| Our very first Rust project (to learn the language) was a
| path tracer that was done (fully functional) in 2 weeks. I
| doubt it would take a team 3 months to become productive in
| Rust. There's always more to learn, but "being productive"
| is quite a low bar if they already know basic programming
| concepts.
|
| With that said, "typical JS/Python devs" might not even
| know said basic programming concepts, so maybe you're
| talking about those? Regardless, 3 months is an extremely
| conservative estimate.
|
| -Emily
| FpUser wrote:
| >"With that said, "typical JS/Python devs" might not even
| know said basic programming concepts"
|
| If Python / JS is all they've ever used they most likely
| have gaping holes in regards to many general concepts of
| computing and some might not be able to grasp those for a
| loooong time.
| Thaxll wrote:
| Pather tracing / ray tracer are very easy to implement
| because it requires basic programming concept. It's all
| about the math not really programming. You can copy paste
| from one language to another.
| toyg wrote:
| I cannot hear you over the sound of your massive
| humblebragging.
| LoganDark wrote:
| I actually decided _not_ to say "maybe we're
| particularly smart but..." for this reason. (I'm trying
| hard _not_ to make it "humblebragging".) Regardless of
| that, we definitely don't feel smart due to ADHD.
|
| Really all I'm saying is that I can't fathom how someone
| could take 3 months to be productive in Rust, that's a
| massive over-estimate.
|
| -Emily
| pclmulqdq wrote:
| A lot of people have a different understanding of what
| "learning a language" means. Your example of a path
| tracer doesn't show a lot of understanding of the deep
| parts of Rust (algebraic types, async, etc), while the
| guy who spent 3 months may have been trying to learn a
| lot more than just the basics to write a path tracer.
| LoganDark wrote:
| Ah, async is indeed the beast. We haven't really put a
| bunch of effort into understanding futures and reactors,
| but we understand them to be state machines (which is
| unfortunately glossed over by a whole ton of reference
| material?).
|
| AFAIK it shouldn't take 3 months to pick a crate off the
| shelf like tokio and use futures effectively, but it
| could take at least that long to understand them deeply
| enough to the point where you can make your own reactor
| from scratch (like tokio) if you're also trying to pick
| up the rest of the language in parallel.
|
| Most of the two weeks was indeed slaving away at math and
| not necessarily learning the language better. I think it
| wouldn't take longer than a few weeks to complete the
| official book and the nomicon if you're determined to
| learn the language. And then you'd use the remaining time
| to get acquainted with the ecosystem... but probably not
| 3 months of time.
|
| -Emily
| jcelerier wrote:
| A path tracer is a classic classroom project example. I
| really do not think knowing how to write one is even
| remotely related to "knowing a programming language" at
| least in the way it's expected in a professional setting
| zozbot234 wrote:
| > It took me probably more like 1-2 months to really
| understand how to code in Rust. I do not think a typical
| team of JS/Python devs would be productive in 3 weeks. I
| think it would be more like 3 months.
|
| This is actually a very fast learning curve. Imagine a
| typical Python/JS developer becoming proficient with real,
| production-quality C++ in 3 months? The very notion seems
| ludicrous to even think about. So the Rust folks are not
| wrong when they point out that Rust is about empowering
| developers and enabling higher quality software across the
| board.
| pletnes wrote:
| I've done C++ in some projects and still think 3 months
| re-training might be necessary for new language features,
| and old foot-machine-guns for that matter! C++ is a
| dangerous beast if I ever saw one.
| bin_bash wrote:
| You're correct. I actually spent the summer before I
| learned Rust learning C++. While that definitely helped
| learning Rust I was barely capable of writing anything in
| C++ after 3 months. (Though that wasn't 3 months full-
| time)
| friedman23 wrote:
| Fair point! I've tried to learn and failed c++ 4 times (I
| knew C, python, typescript, java), I learned rust in a
| month after reading a 700 page book.
| ReflectedImage wrote:
| It's 692 pages, I did it in 5 days, 12 hours per day.
| galangalalgol wrote:
| I have 30 years in c++, and yeah, rust was easy, but I'll
| still admit I'm more productive in matlab or julia or
| pytorch. And I'm still in that phase where I have to check
| the internet every 10min in python. But deploying in those
| languages has throughput and/or latency impacts that may or
| may not be ok depending on the situation. The reliability
| is also a thing. Assuring correctness in a dynamic language
| takes a lot more time, more unit tests are needed. It is
| still faster to iterate to a solution in abdynamic language
| though. But rather than write all those tests and live with
| constraints, I usually rewrite in a non dynamically types
| language.
| danjac wrote:
| It also depends on the larger ecosystem. If you know
| Python, it's not just Python the language, but the
| frameworks, libraries and tooling around it that boost
| productivity in specific tasks: for example Django and
| Pandas. Rust may have rough equivalents but they may or may
| not be as well developed and supported for all the edge
| cases.
| bryanlarsen wrote:
| "equally productive" is misleading. IME Rust is slower to
| write but faster overall because you spend much less time
| debugging and maintaining the code.
|
| "If it compiles it works" happens often to me, which is why
| I'm such a fanboy.
|
| For this reason I'd be much more comfortable jumping into
| an unknown Rust code base than anything else.
| mcronce wrote:
| I agree with this. I may not be able to have a non-
| working prototype that crashes on its first input as
| quickly with Rust as with Python, but I can create a
| _working_ prototype more quickly, and that prototype will
| transform into production code far more quickly.
|
| Scale up a bit, and you end up with far fewer (often
| zero) subtle bugs when other people change other parts of
| the codebase, or when you do a significant refactor -
| some of these being the kinds of bugs that are difficult
| to test for.
|
| I would call that "more productive", personally.
| pkolaczk wrote:
| > For this reason I'd be much more comfortable jumping
| into an unknown Rust code base than anything else.
|
| Rust also promotes simple control flow and acyclic data
| structures by making writing complex control flow and
| cyclic data structures extremely hard. Its tpe system is
| also very explicit about who owns what and about sharing.
|
| Imagine you see the following Python function for the
| first time: def foo(x: Bar):
| foobarize(x)
|
| Although you're lucky that someone included the type
| annotation for x, and you might know what Bar really is,
| you still can have no idea whether e.g you can safely
| modify x in this function. Because maybe something else
| holds another reference to this very same instance and
| will be confused if the object suddenly changes here.
|
| In Rust if you encounter: fn foo(x:
| Bar) { foobarize(x); }
|
| you know there is nothing else holding x, and this
| function can do whatever it likes with it. You can very
| quickly deduce who owns what, what is shared and what is
| not shared. IMHO this helps understanding complex systems
| very much.
| bin_bash wrote:
| I thought this is what would be the case but the reason
| it is slow for me is not because it takes me a long time
| to get to compilation. (It's true but it's a small
| factor.)
|
| The reason is most things are immutable. Frankly I'm just
| not used to writing code in that way (even though most of
| my scripting code is functional and not imperative). I
| find that when I refactor my Rust it requires significant
| work.
|
| In mutable code I can just modify a class/struct when
| something needs to change but when it's mostly immutable
| those changes often require significant redesigns.
|
| Perhaps this is just because I'm new to Rust, but that's
| just proving my point that it's hard. I'm better setup to
| learn a new language than the majority of programmers for
| sure and it's been a real struggle.
|
| At this point I would probably be struggling as much in a
| language like Haskell I suspect. My issue isn't the
| borrow checker, it's immutability.
| zozbot234 wrote:
| Rust only prevents _shared_ mutable data by default. You
| can always mutate things in a local context (i.e. objects
| that are either owned or uniquely borrowed) or use the
| "cell" constructs to opt-in to shared mutable state.
| mcronce wrote:
| > You can always mutate things in a local context (i.e.
| objects that are either owned or uniquely borrowed)
|
| You do have to explicitly declare them mutable, though,
| and will warn you if you have a mutable variable that you
| never mutate. This is helpful for avoiding surprises.
| FpUser wrote:
| >""If it compiles it works" happens often to me, which is
| why I'm such a fanboy."
|
| This completely ignores domain / logic /algorithmic
| errors which in my experience completely dwarf types of
| errors Rust is supposed to take care of.
| pdw wrote:
| I think you underestimate memory errors. In large C and
| C++ projects, ~70% of discovered security vulnerabilities
| have memory errors as their cause. Source:
| https://alexgaynor.net/2020/may/27/science-on-memory-
| unsafet...
|
| On the other hand, Google reports that "to date, there
| have been zero memory safety vulnerabilities discovered
| in Android's Rust code." Source:
| https://security.googleblog.com/2022/12/memory-safe-
| language...
| jokethrowaway wrote:
| If you use the type system well you rarely get wiring
| issues you would normally get at runtime (wasting an
| entire "programming cycle" of writing code and trying it
| out).
|
| But overall I agree: you need tests for business logic.
|
| Another thing that Rust gets right is that you're
| incentivised to write some tests right in the same file
| where you're writing the implementation (it just works
| out of the box with cargo test), so even complex logic is
| easy to test out.
|
| You don't have to go through the "oh, let me setup mocha
| to add a test... never mind I won't bother right now"
| FpUser wrote:
| >"If you use the type system well you rarely get wiring
| issues you would normally get at runtime (wasting an
| entire "programming cycle" of writing code and trying it
| out)."
|
| I assume this goes for scripting languages with weak / no
| typing.
|
| >"You don't have to go through the "oh, let me setup
| mocha to add a test... never mind I won't bother right
| now""
|
| Same thing.
| bryanlarsen wrote:
| Rust is fabulous at avoiding those types of errors. Use
| rich types to avoid domain errors, use Rust's enum's to
| hold state data and then use exhaustive match etc to
| avoid logic and algorithmic errors, use wrapping_add et
| al to avoid arithmetic errors.
| FpUser wrote:
| These features are helpful no doubt but would in no way
| guarantee "if it compiles it works" promise.
| bryanlarsen wrote:
| It only has to help infrequently for it to be a win. And
| it helps more than infrequently.
| pdw wrote:
| Nobody made a promise. The comment you're reacting to
| said "happens often to me".
| mcronce wrote:
| It's not a promise, it's an observation
| FpUser wrote:
| lets call it a lure.
| mcronce wrote:
| You can if you want, but it sounds a lot more like FUD
| than anything else.
| smaddox wrote:
| > IME Rust is slower to write
|
| For a backend webservice prototype, that's probably true.
| It's not true for everything, though. Especially if there
| are performance requirements or you need to handle errors
| properly.
|
| I've found Rust to be extremely productive for
| implementating interpreters, for example, thanks in no
| small part to algebraic data types and pattern matching.
| It's not quite as ergonomic as Haskell/OCaml, since you
| can't currently match under Box's, but hopefully that
| feature will get stabilized soonish.
|
| I also have used it for computationally intensive apps,
| such as a poker odds calculator. Going from a single
| threaded ~24 hr runtime to a ~15 min runtime on 96 vCPU
| took a few minutes, thanks to rayon. Of course C/C++ with
| openmp loop annotations is similarly quick for trivially
| parallel problems, but Rust's built in unit testing and
| package management make me far more productive for things
| like this than in C/C++.
| sidmitra wrote:
| >"equally productive" is misleading.
|
| You're right... but just to add.
|
| In any Enterprise project involves a lot of talking to
| other systems(think Salesforce, Netsuite, Slack) or
| implementing existing protocols(SAML, OAuth,LDAP) and
| other such things. Python being popular for very long
| means there's prior work in almost every area. I believe
| this can be one definition of "productive", basically re-
| using something existing and spend your time on other
| better things. In a lot of the same projects performance
| at the CPU level might not be a bottleneck because you're
| stuck waiting 10 seconds for an API call to Salesforce.
|
| I'm more excited about PyO3 and other Python+Rust
| advances, where it seems you can offload lot of CPU
| intensive stuff to Rust but keep the Python layer and its
| ecosystem.
| bryanlarsen wrote:
| In Rust it's easier for me to use the web API's than it
| is in C++, and in Rust it's easier for me to use the
| C/C++ API's than it is in scripting languages.
|
| Of course in most projects one or the other usage
| dominates so my glib response isn't particularly
| compelling, but in my current project we do use a similar
| amount of both.
|
| But we still have some Python Django code and will
| probably end up with C in driver code.
| zozbot234 wrote:
| Yes, the key thing about being productive with Rust is
| that it heavily nudges you towards designs that compose
| well, avoiding shared state and enforcing a clear, RAII-
| based lifecycle for every object. There are facilities
| that you can use when you need something a bit more
| general than that, but you should only use them when
| appropriate - ideally, you'll want to document the reason
| for their use.
|
| It's a very compelling thing about Rust that problematic
| designs are clearly marked with boilerplate, so you know
| exactly what to look for and perhaps refactor. There
| isn't really a close equivalent to this in other
| languages, e.g. in C++, the "modern" facilities you're
| supposed to use have the heaviest syntax, and this is
| often true in Python, Ruby, JS etc.
| galangalalgol wrote:
| I really think c++23 and future releases should adopt
| cpp23{} to designate code where the compiler is allowed
| to break old stuff in the name of enforcing modern
| practice.
| andrewstuart wrote:
| "voted the most popular programming language for the seventh
| consecutive year, with 87% of developers expressing a desire to
| use it."
|
| And yet where I live, it has extremely minimal adoption. There's
| more rust jobs at panel beaters than doing software development.
|
| Rust has to fix itself or remain popular but essentially unused.
| nindalf wrote:
| The article makes a mistake here in interpreting the results of
| the StackOverflow survey
| (https://survey.stackoverflow.co/2022/#technology-most-
| loved-...). Here's the summary with respect to Rust
|
| - 9.3% of respondents use Rust (#14)
|
| - 87% of respondents who already use Rust would like to
| continue using Rust. (Most loved)
|
| - 17.6% of respondents who don't already use Rust would like to
| try out Rust (Most wanted)
|
| While I generally agree with the sentiment that Rust can,
| should and probably will improve I don't see the survey results
| or your anecdotal experience as cause for alarm.
|
| It's far from the most popular language (JS 65%) or most
| popular language without a runtime (C++ 22.5%). But that's fine
| because it's relatively new. The survey indicators a big
| appetite for trying out Rust among developers who haven't tried
| it out already, indicating that the language could continue to
| grow in popularity.
| pclmulqdq wrote:
| It's worth noting that Rust is about the same age as most of
| the modern C++ paradigms that you see all over C++ codebases
| these days. C++11 came out at around the same time as the
| Rust project reached bootstrapping, and C++14 came out less
| than a year before Rust 1.0.
|
| It would not be an exaggeration to say that most of the C++
| you use today is about the same age as Rust.
| nindalf wrote:
| So even while working with modern C++, only 48% of
| developers want to continue working with it? And only 7.6%
| of developers want to learn it?
| pclmulqdq wrote:
| Pretty much, and for a few good reasons:
|
| - Most C++ projects are not greenfield, and C++
| programmers are often working with 10-20 years of cruft
| in their codebases.
|
| - Most of those codebases are also somewhat object-
| oriented, and thereby tained with "enterprise Javaness."
|
| - C++ has a number of high-profile detractors who are
| well-liked in the programming world, like Linus Torvalds
| and (in this sphere) Bryan Cantrill. Most of these
| detractors haven't touched C++ in 15-20 years and are
| still railing against the monstrosity that was C++03 and
| the thickness of the C++ spec (without actually using
| it).
|
| - C++ is widely used, and often not in places where it is
| appropriate or useful. When people use something, they
| see its rough edges.
|
| - C++ isn't "cool" in programming spheres.
| karmakurtisaani wrote:
| > Most of these detractors haven't touched C++ in 15-20
| years and are still railing against the monstrosity that
| was C++03 and the thickness of the C++ spec (without
| actually using it).
|
| Keep in mind that C++ standard is backwards compatible,
| so every monstrosity added is still there. You might not
| use it, but your (ex-)colleagues might have, and you
| might end up maintaining such code. Let's just say it
| doesn't exactly make it more appealing.
| HideousKojima wrote:
| I imagine that, at least for younger devs, game dev would
| be the only real motivation for learning C++
| scruple wrote:
| Or old (-ish, I'm early 40s). I'm back around to C/C++,
| haven't touched it since C++03 and C++11, having recently
| accepted a Senior+ role in gamesdev and moving away from
| a decade of backend work.
| galangalalgol wrote:
| You have been quite fortunate. Most of the c++ I come
| across is c++98. Or at best c++11 features sprinkled into
| c++98 code.
| jeremychone wrote:
| That is a very good way to look at it.
|
| Now, I am not a C++ dev, but how much effort would it be
| for a team to pick up C++ 20 if they only had worked with
| was C++ 11?
| wongarsu wrote:
| Developer desire to use it outpacing industry adoption seems
| like a sign of a well designed language to me. Developers can
| switch languages much faster than entire projects or companies
| can, so having more developers than jobs signals a language
| that people want to use.
| dividedbyzero wrote:
| Their reasons to want to use it may not be aligned with the
| interests of businesses (or managers) though.
| galangalalgol wrote:
| Businesses still view security issues as a cost center.
| Developers like it because it lets us worry less about the
| easier mistakes that we all sometimes make and focus more
| on the deep logical errors that can lead to the same
| problems.
| MrBuddyCasino wrote:
| The reason it is popular is that the developers who are working
| with it right now have most likely chosen to do so, as those
| are greenfield projects. There simply aren't enough old
| projects written in Rust around to have people be forced to
| work with them due to sheer market inertia.
|
| Companies need people to maintain codebases that were started
| 20 years ago, this is simply not the case for Rust.
| Jweb_Guru wrote:
| We've been hearing this theory since Rust was a _much_
| smaller percentage of the total responses. With an order of
| magnitude more developers using the language, you 'd expect
| this high "loved" rating to have slipped considerably, at
| least behind less commonly used languages, but it hasn't. So
| I no longer really buy this theory; I think it's centered in
| the idea that real improvements to programming languages
| aren't possible, and familiarity / enthusiasm trumps
| everything.
| allo37 wrote:
| There has been a desire to use Rust where I work, but it's
| _really_ hard to make a business case for "Hey, see this C/C++
| code that's worked well for years if not decades? Let's rewrite
| it in a whole new programming language!". I wonder if it's the
| same story elsewhere?
| biorach wrote:
| In general rewriting a well functioning, battle tested C/C++
| codebase in Rust is probably a bad idea.
| nindalf wrote:
| In general rewriting a well functioning, battle tested
| codebase is probably a bad idea.
|
| But sticking to "battle tested" means a local minima at
| times. For example, there's no shortage of CVEs in
| OpenSSL's past or future. It's definitely "battle tested".
| And yet, that doesn't mean someone shouldn't try to write
| something better.
| marcosdumay wrote:
| Well, you said it was battle tested, but you didn't care to
| mention the battle results.
|
| It may be a good idea to replace, or not. We don't have
| enough data to decide.
| Ygg2 wrote:
| I disagree.
|
| Even if Rust wasn't able to eliminate whole swath of errors
| in C(++). And it is (Nulls and data races).
|
| Rust has way better package manager, and actually works on
| Windows.
|
| For example coreutils got rewritten in Rust. And got
| adopted by Yocto.
| galangalalgol wrote:
| Just this week we were porting some old c++ over to rust,
| stuff from the 90s probably. It was relying on the last
| element of an array being zero due to null termination.
| It used that value in its computation. That sounds crazy
| but fine, except it wasn't an array of bytes, so if it
| wasn't aligned and padded to 4bytes that last value might
| not be all zeroes. I don't know a common arch outside of
| microcontrollers where it wouldn't work, but still!
| scruple wrote:
| What uC? I'm interested in learning which vendors are
| shipping rust toolchains for their chips.
| galangalalgol wrote:
| not using it on a uC, it did work in c++. Bounds checker
| caught it in rust. I was just postulating it might not
| work in c++ everywhere.
| scruple wrote:
| Ahh, gotcha.
| nickelpro wrote:
| Cargo is not de facto better than vcpkg. That Rust has a
| blessed package manager instead of community of competing
| package managers is a lateral, neither better nor worse.
| Ygg2 wrote:
| Vcpkg? Never heard of it. 90% of C++ project I saw were
| using make. Remainder were using cmake.
|
| > community of competing package managers is a lateral,
| neither better nor worse.
|
| While I understand your position, that's not my opinion.
| Having one way to build a package is a blessing. Having
| had to juggle Python's competitive package manager is a
| nightmare.
|
| https://imgs.xkcd.com/comics/python_environment_2x.png
|
| Each one has slightly different usages and they are
| mostly compatible but then you run into edge cases.
|
| -----
|
| And lack of blessed libs is something I am strongly
| against.
|
| Rust doesn't have standardized time lib and everyone is
| suffering for it.
| galangalalgol wrote:
| Except for grpc that uses bazel! I know two teams where I
| work, one uses vcpkg, but the other uses conan. Our
| company as a whole points to conan as the answer, but
| mostly everyone uses cmake and git submodules. That is
| why a single blessed package manager is better than many,
| none of them play well together. And that is ignoring
| hunter and meson. I don't know what the gp is talking
| about.
| hgomersall wrote:
| Fix itself? What would that even look like? We use Rust
| extensively and haven't regretted it for a moment. If other
| companies can't see the competitive advantage it offers us, too
| bad for them.
| Ygg2 wrote:
| How exactly do you expect language to increase adoption?
|
| It's a chicken and egg problem.
| DoingIsLearning wrote:
| Python grew organically. People will use whatever addresses
| their pains or allows them to solve their problems.
|
| More often than not the _perceived_ problem is not
| performance or memory safety.
| the_mitsuhiko wrote:
| > Python grew organically.
|
| As opposed to Rust?
| DoingIsLearning wrote:
| Rust has a huge online community but has not (yet) had a
| massive industry adoption. GP was asking how that can be
| achieved.
| the_mitsuhiko wrote:
| Which is what I would call "organic growth". The exactly
| same thing happened with Python originally too. It took a
| very long time for Python to show up in "the industry"
| and in many ways it never did because it only shows up in
| certain parts of it.
| DoingIsLearning wrote:
| Fair perhaps indeed it really is a matter of time.
| yazaddaruvala wrote:
| > but has not (yet) had a massive industry adoption
|
| Amazon, Microsoft, Google, Dropbox, Cloudflare, Meta.
| This is a list of companies I could think of quickly,
| that don't just "use Rust" they are "heavily invested in
| Rust".
|
| If this isn't "massive industry adoption", its not clear
| what is.
| Ygg2 wrote:
| I think that boils down to:
|
| A) Get lucky.
|
| B) Be the only choice.
|
| C) Get a massive corporation to back you.
|
| Otherwise you can't ride the network effect to the
| fullest.
| goodpoint wrote:
| > "voted the most popular programming language for the seventh
| consecutive year, with 87% of developers expressing a desire to
| use it."
|
| This only indicates the huge bias in the voting crowd.
| jmartin2683 wrote:
| We're hiring! Hit me up if you're interested in building tools
| around Polars and Arrow in Rust.
| pflanze wrote:
| How? You don't have a publicly visible address or company
| reference in your profile.
|
| Edit: you have answered that in
| https://news.ycombinator.com/item?id=34612364
| Aissen wrote:
| I loaded them before, so it might only be transitional, but many
| magazine article links are broken(404) for me (including the
| article).
___________________________________________________________________
(page generated 2023-02-07 23:02 UTC)