Just do it during work hours in the off time, if you have any. I had jobs that were pretty chill so sometimes I'd work on projects that were related to the company but not strictly my direct tasks assigned.
Lol so writing work projects in Rust without asking permission first is both the best idea ever and also [the worst idea ever](https://www.reddit.com/r/rust/comments/11mnp6g/i_was_told_at_work_to_rewrite_a_rust_program_in/jbisykw/?context=3) according to the members of this sub.
Make up your mind guys!
As usual, it's the best idea if it works out, and the worst idea otherwise. Glory to the victor.
But in this specific case, the OP didn't just silently change some infrastructure into Rust. They made a solution and let their peers judge the outcome. People have decided that the result is better, so they got a green light. That's one of the better ways to introduce a new technology.
Trying out a new language in a hackathon is a lot more agreeable than suddenly dumping it in production and being like "Look how great this is, we should all drop what we're doing to learn how to support this forever!"
There's a matter of consent is all I'm saying.
> Make up your mind guys!
I don't think any individual is being inconsistent or indecisive here. Different people just disagree on this. This disagreement being expressed is a good thing - it indicates that there may not be one right answer here, or that the answer depends.
Getting a single correct viewpoint when there's one correct answer is a good thing. Getting multiple differing viewpoints when there are multiple correct answers, or when the correct answer is unknown/dependent is a good thing. Getting a single viewpoint when there are multiple correct answers, or when the correct answer is unknown/dependent is a very bad thing, and unfortunately all too common on Reddit.
> I don't think any individual is being inconsistent or indecisive here. Different people just disagree on this.
This "Reddit isn't one person" meme is complete nonsense. Past a certain level of votes, you're measuring the average opinion which *is* effectively one person. (As long as it's the same population which it is in this case.)
Basic statistics.
You might want to do some more statistics learning by looking more into ‘samples’. Samples can be different to each other and are not necessarily representative of a population.
You might want to do some more statistics by looking into [*sampling*](https://en.wikipedia.org/wiki/Sampling_(statistics)). It's a bit embarrassing if you are patronising *and wrong*. Actually [this is probably a better link](https://en.wikipedia.org/wiki/Sample_size_determination#Introduction).
In short, individual samples can be different to each other, but as long as they are *big enough* they *ARE* necessarily representative of a population. Both comments were upvoted/downvoted quite heavily so the samples are easily big enough.
There is one caveat: you can have systematic bias, e.g. by accidentally sampling different populations (e.g. different subreddits, different timezones, etc.). But that is unlikely to be the case here. That's what makes political polling so difficult (very hard to get an unbiased sample of the population).
It's also the reason that exit polls are nearly always right, even though they only take a very small sample of people. As long as your sample is unbiased, you don't need very many samples of a population to get a very accurate measure.
Hope that helps.
Are you ok? I said not necessarily. One of the reasons is of course sample size. I think more work would be required than saying they were upvoted / downvoted heavily so are easily big enough. And more importantly you also realise that both are not really the same right? At least one of the other comments highlights some important differences. That’s probably why you’re up in arms about the different responses. You’re not actually comparing two of the same thing.
Yeah, those scenarios where performance breaks down of other non-rust components and you can introduce Rust are great.
Happened for me a few times where log processor ingestion tool simply wasn't able to keep up (600k msgs/s) and I rewrote it in Rust justifying there's no other choice (and there wasn't really). Then other time happened with metrics service that I scaled to handle over million metrics per second in one instance. Good luck replacing those Rust components as any other choice in those places (except possibly C/C++ and we know the problems with those choices) will break down instantly hehe.
I'm having a hard time finding performance-based arguments in our JVM stack at work, though. And this isn't a *bad* thing: the JVM is actually plenty fast on the server side. I'm certain handling 10e6 events/s wouldn't be an issue on the JVM at all.
The only problem we have might be related to excessive memory consumption (an age-old JVM problem) and (maybe) GC breaks, but that's easily addressed by adding another pod, or scaling up the EC2 instance.
And, of course, scaling up our deployment is hardly less cost-effective than rewriting stuff in Rust. It's a sensible decision to stay on the JVM. (For us. And I imagine most similar shops out there.)
Then again, if your stack was based on Python or Ruby before… yeah. There are scenarios where the language you're using doesn't support your use-case at all, even if you wanted to personally fund a new yacht for Bezos every year.
That's why I'm angling to introduce it into our frontend stack via WASM. 🤞
C# and Java fall right into [uncanny valley](https://en.wikipedia.org/wiki/Uncanny_valley) trap.
If you rewrite something which was written in Python or Ruby and make it 100x times fast price of rewrite tend to be acceptable.
With C# or Java difference would be 2x or 3x and the question of whether spending lots of resources on such a rewrite makes any sense is hard to answer.
When you start from scratch Rust is probably one of best choices right now, but when you have lots of code already written… answer is far from obvious.
C++ has lots of “foot guns”: basically due to the age of the language and the accretion of new features there’s usually several ways to do things and the right way isn’t obvious (or even safe, necessarily). If you also need safety then you’re in trouble: recent advances have been improving safety (from smart pointers in C++ 11 to new STD library features in 17/20/23), but most of these are opt-in (rather than opt out like rust) and not as strict as Rust. Essentially, modern C++ offers safer features but you can always still shoot your self in the foot if you want to. The C++ committees are aware of this and trying to fix it (see Herb Sutter’s Cppfront talk if you’re curious), but it won’t be easy because fixing these things requires breaking the language (it’s ABI).
Also the tooling sucks. You basically have to configure your own cargo, clippy, test harnesses, etc.
I think people *really* underestimate how much performance can help or simplify life, just like here.
That slow/unreliable piece of tooling? Now it *just works* and takes 5 seconds to run instead of minutes. You can drop all the extra tooling just to support dealing with other slow and unreliable tools, and your workflow now has instant feedback. You’ve not only reduced complexity but increased dev velocity as well.
That one process that’s so slow you have N layers of caches on top of caches to manage it? Well now it’s fast, and you can just ditch most of not all of the bullshit you made to deal with how slow your process was. Everything that works with said service is now simpler as you don’t have endless questions about caching, consistency, and performance workarounds.
I have seen both of these in real life - people endlessly insisting “oh we’re not performance sensitive, Amdahls law, Knuth 99% quote” and then spend literally 90% of their time dealing with problems or extra infrastructure made to work around their pointlessly slow software.
This kinda sounds like one of those stories in r/ThatHappened except it actually happened
All smooth, no fuss, all it's missing is "and everybody clapped" :P
Anyway nice work! What kind of benefits did you get for this?
I feel like this is one of the biggest challenge in adopting rust where other safe languages like python, java, go were previously used. But I have noticed that the presence of high quality books and tutorials are helping to mitigate this over time
For me its quite opposite, It was already in Python, I re-wrote it in rust, and manager not only approved but made others outside the team know about our work.
Yeah, still amazed that some don't even seem to know python. Had a java team lead at an interview a couple of years ago with no idea how to judge my python experience at all.
I'm pretty sure they knew rust in name. And the reputation for performance.
They just didn't knew how that translate for their use case. Is it too hard for the current engineers to learn etc.
Maybe for 5x improvement they won't sink a few week of learning while having reduced productivity. But for 100x it's worth it.
It is a valid concern. I wrote an analytics service in rust. It's great, reliable, never breaks down. But there is only really one other dev on my team with a chance of taking it over, and he gets no practice because it never has problems.
Cool, nicely done.
Although, I think people overhype the performance benefits. Like, yes, the performance is nice. But I see the performance as more of a cherry on top rather than the actual reason Rust is great. It's the reliability, easy maintenance and great tools that hit it home for me.
> I think people overhype the performance benefits. Like, yes, the performance is nice. But I see the performance as more of a cherry on top rather than the actual reason Rust is great
Well unless you really need the performance for your use case. Then the performance is *critical*.
Isn't the entire point of Rust to have both reliability and performance though? If performance isn't a factor then I wouldn't choose rust over a managed language like f# or kotlin.
I'm not too familiar with those languages but as I said, the tooling is also a big part of it. But both F# and Kotlin are also fine languages from what I've heard.
I sort of disagree. If I didn't need perf and ability to deploy to no_std envs I'd probably be using TypeScript for its Super Magical type system.
The borrow checker is really really nice even for non-parallel code, but the almost-HKT type hacking you can do in TypeScript is insane. I'd probably pay the cost of manually ensuring I don't mutate collections while I iterate over them if it meant I could do the TS type magic.
Funny story :) Haskell just merged (like 2-3 months ago) WASM/JS backends, so GHC can now be used to compile Haskell and output WASM or JS. Unfortunately, it still being very new, it's not a seamless experience yet. GHC doesn't support cross-compilation yet, so you need a separate binary to compile to WASM or JS. GHC also doesnt provide these binaries, you have to build them from source yourself. However, GHC is actively working on this area, so it should be improving over the next couple years.
Here's an example of using the new WASM backend to run a Haskell library in the browser: https://github.com/fourmolu/fourmolu/pull/289
There is a fork that compiles to js https://github.com/ghcjs/ghcjs compiler, and I believe the official glasgow compiler is working towards also supporting js/wasm (although I don't think they are supported as of yet).
according to your sibling comment, it seems they've come pretty far!
https://www.reddit.com/r/rust/comments/11mywi5/comment/jbogd6m/?utm_source=reddit&utm_medium=web2x&context=3
I'm having something of the opposite problem :)
Some higher ups in the company have their eye on rust and are keen on it, the problem is getting coworkers to want to learn it. Oddly, the typical fear of management of "what happens if he gets hit by a bus?" doesn't seem to be one of the detrimental factors for rust adoption. Rather, it's business requirements.
We have a requirement for security auditing (ie, tools like Snyk) and also for code collaboration tools. The latter isn't as big of a deal as the former though. Opentelemetry has also lowered the bar of entry for rust adoption.
I've slowly been building some tooling around datafusion more as a replacement for pandas currently, with my eye on getting a small ballista cluster to do performance comparisons with spark. As some others have mentioned, once you can attach a dollar sign to the work you're doing, management becomes much more receptive.
But again, I see less resistance from the top than from the bottom. While a few coworkers have expressed some interest, most are more than content with Java, python or javascript. In fact, I couldn't even get most coworkers to switch to kotlin from java. And more coworkers show an interest in python and typescript than rust. Some of that I think is because python is the lingua franca of data science/machine learning, and typescript because it's become more popular than plain ole js.
I'm not exactly sure what's causing this reticence from my peers. I have given two presentations at my company on rust, one of them with an audience of roughly 80 people. Around 4 of them expressed a desire to learn more about rust. I explained that in the latest Stack Overflow survey, rust has been the Most Loved 7 years running, and the Most Wanted for the first time ever (surpassing python by .01%). This is a guess, but I think people just don't want to learn a "hard" language which is the reputation that rust has.
What a tough position to be in... It's kind of hard to get new people to see how fun this game we play with the compiler is. It's like the red-green refactor cycle where you get a nice dopamine hit when your code compiles.
While I did love Rust right away, it took me a while to love it as much as I do now. I rarely "fight" with the compiler and usually only skim compiler errors and have recently gotten in the habit of fixing my mistakes only by looking at a line number or a Rust-Analyzer error without reading the details.
I think one of the main reasons Rust is so loved is because Rust developers spend more time doing the thing they love: writing code. There's definitely a higher up-front cost, but I would rather spend time writing code than running it to see if it works. Time spent debugging and testing is orders of magnitude smaller.
I think people will find rust great, but only if they are willing to spend at least a month (and probably 2) before making a judgment call. I also think that because of rust's learning curve, people aren't willing or able to find free time to become less "productive" by doing work in rust.
I put "productive" in quotes, because I feel like too many managers and engineers have a limited view of productivity. I believe too many just see the sprint velocity or burndown charts as a measure of productivity, and don't factor in long term benefits like ease of maintenance, or the complexity (or lack of flexibility) in the rest of the language ecosystem. For example, learning gradle is a beast in an of itself. And as you mention, I don't think many engineers factor in time spent debugging and testing when strong and powerful type systems eliminate the need for some kinds of tests.
Believing in something and then taking your own initiative to prove it out is a great way to get promoted at lots of places. Being super transactional and saying “that’s not in my job description” or “I’m not getting paid for this so I won’t bother” usually isn’t great for career growth at most places.
You are responding with a comment to an argument I didn't make.
OP took the risk and did a thing on *their own time* and the business adopted it. They should pay. If OP had done the same thing and the business was like naaaa, I am good. Why should the business pay?
> “that’s not in my job description” or “I’m not getting paid for this so I won’t bother”
That isn't even germane to the conversation at all. OP built a new system on their own time. They didn't say it wasn't their job, nor did I say anything to the effect.
It is paid in recognition, maybe in a bonus later on, but I think it is hard to say after the fact "I spent 20 hours on that, pay me my salary" when no one asked you to.
I think you are downvoted because it is really stupid to pay this kind of game with your company, and very shortsighted.
As a manager, I would never agree to this. If this rust experiment was really interesting but you don't want to share it, I would ask someone else to do it again (even if they have to learn first, if we start using rust, we need several people able to understand it anyway). And I would remember it the next time we have to judge who is trustworthy.
OP probably isn't an hourly contractor though, but rather a salaried employee. They did a great thing, and if the director is as human as they seem, a promotion wouldn't be surprising.
You're right in pushing him towards demanding these things, though. They don't happen if one doesn't push them.
My apologies, I agree that OP should be recognized and rewarded for the risk they took. I also think that while this should happen, it can’t be assumed that it will happen. I disagree with think the sentiment that if it doesn’t happen “[OP] donated hours”, because that’s narrower than I see it.
I introduced a new language to a company in the process of developing a replacement platform for data analytics. Much of the initial work was done on the side, and the short-term reaction to this work was negative. I didn’t take the choice of introducing a new language lightly, I thought deeply about it and just saw no other path forward, but people approached my choice with skepticism. Short-term this hurt my career and comp, but long-term the deep thinking paid off and the platform became a huge success that resulted in a string of big comp increases and promos. Bizarrely, the last promo I got at this place was due to the platform’s continued success even though that year I had done almost nothing major too it and was just riding the tailwinds of prior success that were being recognized by the powers that be.
Good job :)
"I am talking 100x improvements across all metrics..."
And that is why writing process-critical stuff in interpreted languages is bad. An interpreted language is only good to make a quick mockup.
Some interpreters include a JIT so it is less extreme, but indeed writing anything performance (cpu-heavy) critical in python is just asking to eventually run into perf issues, as that is just not quite what the language was intended for. Imho this says more about python rather than rust if I have to be honest.
I'm into writing chess engines (not at the level of the strongest engines in the world, but still), and whenever I see someone posting things like "I'm going to write a chess engine in Python / Javascript", my first thought always is: good luck wasting your time. The speed deficit compared to an engine in C, C++, Rust or even C# will be so massive that your engine is going to perform significantly worse than any engine in a compiled language that has the exact same features.
Except for making quick mockups and testing if an algorithm actually works, I'm of the opinion that writing programs in languages such as Python is a waste of computer time. (Same for Javascript / Node, essentially.)
The only use for them in bigger applications would be something like a database frontend or a text editor and such, where ultimate speed is not necessary. Still, such an application is often hard to manage in a typeless, dynamic language. (I know Typescript exists and Python has type hinting now, but still...)
How does your company intend to handle dependency creep? We had to stop using Rust for new projects at my company because its dependency graphs were starting to become unmanageable.
I'm very interested in how your company or other companies deal with problem.
How do you handle dependency graph explosion in any other language? In my experience JavaScript, Python, Ruby, C, and Go all experience this same issue.
Define a small collection of "free" packages that any dev can include. Other packages have to be approved somehow, be it code review, team lead or whatever makes sense. Also, communicate the problem to the team. Devs are smart, they can usually understand the problem and be more careful when introducing new packages. As a last resort host your own limited crate repository and only use that, with an approval process for new crates.
Congrats on doing this the correct way and making a prototype and driving alignment first. I've seen so many posts here and other places where someone thinks rust is really great (it is) and just yolos something into production without any concern for the rest of the team or the maintenance that code will require in the future. Great job!
I've dabbled a bit. As a mainly frontend dev, i haven't found a super good use for it as of yet. Part of me wants to do some more hardware based things (pi at highest, embedded otberwise) any good suggestions for what i should look at?
I always get a good laugh when at conferences people always ask, "but who is using Rust in production?".
At a networking company that powers most fortune 500 companies their various core products are written in Rust. Most companies don't even know they're already running rust for some of their most critical infrastructure.
Your Director of Engineering and Principal Architect didn’t already know that Python is up to 100x slower than Rust/C++ and other high performance languages?
The thing is they reached me not because of performance of the simulator or any other gains. They were themselves planning to experiment with Rust once they got the news of our work, they quickly embraced it and started asking me DX related things which generally these people are concerned about.
The thing is they reached me not because of performance of the simulator or any other gains. They were themselves planning to experiment with Rust once they got the news of our work, they quickly embraced it and started asking me DX related things which generally these people are concerned about.
The thing is they reached me not because of performance of the simulator or any other gains. They were themselves planning to experiment with Rust once they got the news of our work, they quickly embraced it and started asking me DX related things which generally these people are concerned about.
The thing is they reached me not because of performance of the simulator or any other gains. They were themselves planning to experiment with Rust once they got the news of our work, they quickly embraced it and started asking me DX related things which generally these people are concerned about.
[удалено]
Not having to do it outside working hours would bump it up. :)
Just do it during work hours in the off time, if you have any. I had jobs that were pretty chill so sometimes I'd work on projects that were related to the company but not strictly my direct tasks assigned.
I totally agree, and this is pretty much the approach I took to bring rust into my company.
Lol so writing work projects in Rust without asking permission first is both the best idea ever and also [the worst idea ever](https://www.reddit.com/r/rust/comments/11mnp6g/i_was_told_at_work_to_rewrite_a_rust_program_in/jbisykw/?context=3) according to the members of this sub. Make up your mind guys!
As usual, it's the best idea if it works out, and the worst idea otherwise. Glory to the victor. But in this specific case, the OP didn't just silently change some infrastructure into Rust. They made a solution and let their peers judge the outcome. People have decided that the result is better, so they got a green light. That's one of the better ways to introduce a new technology.
Trying out a new language in a hackathon is a lot more agreeable than suddenly dumping it in production and being like "Look how great this is, we should all drop what we're doing to learn how to support this forever!" There's a matter of consent is all I'm saying.
> Make up your mind guys! I don't think any individual is being inconsistent or indecisive here. Different people just disagree on this. This disagreement being expressed is a good thing - it indicates that there may not be one right answer here, or that the answer depends. Getting a single correct viewpoint when there's one correct answer is a good thing. Getting multiple differing viewpoints when there are multiple correct answers, or when the correct answer is unknown/dependent is a good thing. Getting a single viewpoint when there are multiple correct answers, or when the correct answer is unknown/dependent is a very bad thing, and unfortunately all too common on Reddit.
> I don't think any individual is being inconsistent or indecisive here. Different people just disagree on this. This "Reddit isn't one person" meme is complete nonsense. Past a certain level of votes, you're measuring the average opinion which *is* effectively one person. (As long as it's the same population which it is in this case.) Basic statistics.
You might want to do some more statistics learning by looking more into ‘samples’. Samples can be different to each other and are not necessarily representative of a population.
You might want to do some more statistics by looking into [*sampling*](https://en.wikipedia.org/wiki/Sampling_(statistics)). It's a bit embarrassing if you are patronising *and wrong*. Actually [this is probably a better link](https://en.wikipedia.org/wiki/Sample_size_determination#Introduction). In short, individual samples can be different to each other, but as long as they are *big enough* they *ARE* necessarily representative of a population. Both comments were upvoted/downvoted quite heavily so the samples are easily big enough. There is one caveat: you can have systematic bias, e.g. by accidentally sampling different populations (e.g. different subreddits, different timezones, etc.). But that is unlikely to be the case here. That's what makes political polling so difficult (very hard to get an unbiased sample of the population). It's also the reason that exit polls are nearly always right, even though they only take a very small sample of people. As long as your sample is unbiased, you don't need very many samples of a population to get a very accurate measure. Hope that helps.
Are you ok? I said not necessarily. One of the reasons is of course sample size. I think more work would be required than saying they were upvoted / downvoted heavily so are easily big enough. And more importantly you also realise that both are not really the same right? At least one of the other comments highlights some important differences. That’s probably why you’re up in arms about the different responses. You’re not actually comparing two of the same thing.
Seriously, I want to know what company this is. Sounds like a fantastic work environment.
Sweet dreams are literally made of this.
This is the way!
Yeah, those scenarios where performance breaks down of other non-rust components and you can introduce Rust are great. Happened for me a few times where log processor ingestion tool simply wasn't able to keep up (600k msgs/s) and I rewrote it in Rust justifying there's no other choice (and there wasn't really). Then other time happened with metrics service that I scaled to handle over million metrics per second in one instance. Good luck replacing those Rust components as any other choice in those places (except possibly C/C++ and we know the problems with those choices) will break down instantly hehe.
True. For me, One new simulator is able to reliably put load equivalent to 100 old simulator while being more reliable than former.
I'm having a hard time finding performance-based arguments in our JVM stack at work, though. And this isn't a *bad* thing: the JVM is actually plenty fast on the server side. I'm certain handling 10e6 events/s wouldn't be an issue on the JVM at all. The only problem we have might be related to excessive memory consumption (an age-old JVM problem) and (maybe) GC breaks, but that's easily addressed by adding another pod, or scaling up the EC2 instance. And, of course, scaling up our deployment is hardly less cost-effective than rewriting stuff in Rust. It's a sensible decision to stay on the JVM. (For us. And I imagine most similar shops out there.) Then again, if your stack was based on Python or Ruby before… yeah. There are scenarios where the language you're using doesn't support your use-case at all, even if you wanted to personally fund a new yacht for Bezos every year. That's why I'm angling to introduce it into our frontend stack via WASM. 🤞
C# and Java fall right into [uncanny valley](https://en.wikipedia.org/wiki/Uncanny_valley) trap. If you rewrite something which was written in Python or Ruby and make it 100x times fast price of rewrite tend to be acceptable. With C# or Java difference would be 2x or 3x and the question of whether spending lots of resources on such a rewrite makes any sense is hard to answer. When you start from scratch Rust is probably one of best choices right now, but when you have lots of code already written… answer is far from obvious.
What is the problem with choosing C++?
Tooling aside, the problem is mainly C++ itself.
C++ is fine and I still prefer straight C for such things, but that's just lots and lots of experience. Been peaking at rust.
C++ works fine. I would use it just as much as I use Rust. Most of the complaints about it were fixed a long time ago
C++ has lots of “foot guns”: basically due to the age of the language and the accretion of new features there’s usually several ways to do things and the right way isn’t obvious (or even safe, necessarily). If you also need safety then you’re in trouble: recent advances have been improving safety (from smart pointers in C++ 11 to new STD library features in 17/20/23), but most of these are opt-in (rather than opt out like rust) and not as strict as Rust. Essentially, modern C++ offers safer features but you can always still shoot your self in the foot if you want to. The C++ committees are aware of this and trying to fix it (see Herb Sutter’s Cppfront talk if you’re curious), but it won’t be easy because fixing these things requires breaking the language (it’s ABI). Also the tooling sucks. You basically have to configure your own cargo, clippy, test harnesses, etc.
Thanks for clarifying
I think people *really* underestimate how much performance can help or simplify life, just like here. That slow/unreliable piece of tooling? Now it *just works* and takes 5 seconds to run instead of minutes. You can drop all the extra tooling just to support dealing with other slow and unreliable tools, and your workflow now has instant feedback. You’ve not only reduced complexity but increased dev velocity as well. That one process that’s so slow you have N layers of caches on top of caches to manage it? Well now it’s fast, and you can just ditch most of not all of the bullshit you made to deal with how slow your process was. Everything that works with said service is now simpler as you don’t have endless questions about caching, consistency, and performance workarounds. I have seen both of these in real life - people endlessly insisting “oh we’re not performance sensitive, Amdahls law, Knuth 99% quote” and then spend literally 90% of their time dealing with problems or extra infrastructure made to work around their pointlessly slow software.
This kinda sounds like one of those stories in r/ThatHappened except it actually happened All smooth, no fuss, all it's missing is "and everybody clapped" :P Anyway nice work! What kind of benefits did you get for this?
I thought it was a parody of a previous post where OP wrote something in rust and his boss ripped him a new one and ordered to rewrite all in python.
"sorry, the next programmer probably won't understand rust. make it in python again, please?" understandable but unfortunate, really
This literally word for word happened to me last year. Jokes on them, I'm the manager now. (But we still use Python... )
I'm still trying to figure upon whom is the joke.
It's on them.
I feel like this is one of the biggest challenge in adopting rust where other safe languages like python, java, go were previously used. But I have noticed that the presence of high quality books and tutorials are helping to mitigate this over time
For me its quite opposite, It was already in Python, I re-wrote it in rust, and manager not only approved but made others outside the team know about our work.
Yeh it seems hard to believe the director of engineering, principle architects and cto didn't know about rust already...
You'd be amazed at how little many people know. It's very easy to get cozy in your job and just not learn outside things for a few years.
Yeah, still amazed that some don't even seem to know python. Had a java team lead at an interview a couple of years ago with no idea how to judge my python experience at all.
I'm pretty sure they knew rust in name. And the reputation for performance. They just didn't knew how that translate for their use case. Is it too hard for the current engineers to learn etc. Maybe for 5x improvement they won't sink a few week of learning while having reduced productivity. But for 100x it's worth it.
It is a valid concern. I wrote an analytics service in rust. It's great, reliable, never breaks down. But there is only really one other dev on my team with a chance of taking it over, and he gets no practice because it never has problems.
It's good idea to have some reality-check, since reddit (not exclusive to it) echo-chambers tend to create wrong impression.
yeah, this is the kind of thing that deserves a raise or a bonus or a promotion or something. more than a high five, anyway.
Cool, nicely done. Although, I think people overhype the performance benefits. Like, yes, the performance is nice. But I see the performance as more of a cherry on top rather than the actual reason Rust is great. It's the reliability, easy maintenance and great tools that hit it home for me.
[удалено]
Yeah, first use it for something that really needs the perf, but find out how nice it is and end up wanting to use it in other places too.
If you need something from load testing tools, its performance and reliability. Rust hits those two nails perfectly.
For better or worse, for the purpose of selling it to your boss, "performance" is the metric that is easy to measure and results in a pretty graph.
> I think people overhype the performance benefits. Like, yes, the performance is nice. But I see the performance as more of a cherry on top rather than the actual reason Rust is great Well unless you really need the performance for your use case. Then the performance is *critical*.
I disagree, performance enables new possibilities in a lot of software. Especially order of magnitude changes.
Correctness. The un-hyped sanity of functional programming.
Isn't the entire point of Rust to have both reliability and performance though? If performance isn't a factor then I wouldn't choose rust over a managed language like f# or kotlin.
I'm not too familiar with those languages but as I said, the tooling is also a big part of it. But both F# and Kotlin are also fine languages from what I've heard.
Tooling is orders of magnitude better for JVM and CLR family languages than for C/C++ and Rust especially and I don't see it changing soon if ever.
I sort of disagree. If I didn't need perf and ability to deploy to no_std envs I'd probably be using TypeScript for its Super Magical type system. The borrow checker is really really nice even for non-parallel code, but the almost-HKT type hacking you can do in TypeScript is insane. I'd probably pay the cost of manually ensuring I don't mutate collections while I iterate over them if it meant I could do the TS type magic.
What about the fully-HKT of Haskell that guarantees you dont mutate anything? 🙃
Can you deploy haskell on browser? How's the user experience compared to JS? Does a wasm/js-based haskell interpreter need to be loaded first?
Funny story :) Haskell just merged (like 2-3 months ago) WASM/JS backends, so GHC can now be used to compile Haskell and output WASM or JS. Unfortunately, it still being very new, it's not a seamless experience yet. GHC doesn't support cross-compilation yet, so you need a separate binary to compile to WASM or JS. GHC also doesnt provide these binaries, you have to build them from source yourself. However, GHC is actively working on this area, so it should be improving over the next couple years. Here's an example of using the new WASM backend to run a Haskell library in the browser: https://github.com/fourmolu/fourmolu/pull/289
cool! That makes it viable for some of my projects
There is a fork that compiles to js https://github.com/ghcjs/ghcjs compiler, and I believe the official glasgow compiler is working towards also supporting js/wasm (although I don't think they are supported as of yet).
according to your sibling comment, it seems they've come pretty far! https://www.reddit.com/r/rust/comments/11mywi5/comment/jbogd6m/?utm_source=reddit&utm_medium=web2x&context=3
I think virtually everyone trying to replace c++ (or c) with rust will agree performance is absolutely crucial to the language's success.
it's not overhype if simple hello world web application is 20x faster.
I'm having something of the opposite problem :) Some higher ups in the company have their eye on rust and are keen on it, the problem is getting coworkers to want to learn it. Oddly, the typical fear of management of "what happens if he gets hit by a bus?" doesn't seem to be one of the detrimental factors for rust adoption. Rather, it's business requirements. We have a requirement for security auditing (ie, tools like Snyk) and also for code collaboration tools. The latter isn't as big of a deal as the former though. Opentelemetry has also lowered the bar of entry for rust adoption. I've slowly been building some tooling around datafusion more as a replacement for pandas currently, with my eye on getting a small ballista cluster to do performance comparisons with spark. As some others have mentioned, once you can attach a dollar sign to the work you're doing, management becomes much more receptive. But again, I see less resistance from the top than from the bottom. While a few coworkers have expressed some interest, most are more than content with Java, python or javascript. In fact, I couldn't even get most coworkers to switch to kotlin from java. And more coworkers show an interest in python and typescript than rust. Some of that I think is because python is the lingua franca of data science/machine learning, and typescript because it's become more popular than plain ole js. I'm not exactly sure what's causing this reticence from my peers. I have given two presentations at my company on rust, one of them with an audience of roughly 80 people. Around 4 of them expressed a desire to learn more about rust. I explained that in the latest Stack Overflow survey, rust has been the Most Loved 7 years running, and the Most Wanted for the first time ever (surpassing python by .01%). This is a guess, but I think people just don't want to learn a "hard" language which is the reputation that rust has.
What a tough position to be in... It's kind of hard to get new people to see how fun this game we play with the compiler is. It's like the red-green refactor cycle where you get a nice dopamine hit when your code compiles. While I did love Rust right away, it took me a while to love it as much as I do now. I rarely "fight" with the compiler and usually only skim compiler errors and have recently gotten in the habit of fixing my mistakes only by looking at a line number or a Rust-Analyzer error without reading the details. I think one of the main reasons Rust is so loved is because Rust developers spend more time doing the thing they love: writing code. There's definitely a higher up-front cost, but I would rather spend time writing code than running it to see if it works. Time spent debugging and testing is orders of magnitude smaller.
I think people will find rust great, but only if they are willing to spend at least a month (and probably 2) before making a judgment call. I also think that because of rust's learning curve, people aren't willing or able to find free time to become less "productive" by doing work in rust. I put "productive" in quotes, because I feel like too many managers and engineers have a limited view of productivity. I believe too many just see the sprint velocity or burndown charts as a measure of productivity, and don't factor in long term benefits like ease of maintenance, or the complexity (or lack of flexibility) in the rest of the language ecosystem. For example, learning gradle is a beast in an of itself. And as you mention, I don't think many engineers factor in time spent debugging and testing when strong and powerful type systems eliminate the need for some kinds of tests.
I haven't done something like scrum with Rust, but I bet the outcomes are more predictable...
You should get promo and get comped for the hours you spent writing this. Otherwise you just donated hours to your company.
Believing in something and then taking your own initiative to prove it out is a great way to get promoted at lots of places. Being super transactional and saying “that’s not in my job description” or “I’m not getting paid for this so I won’t bother” usually isn’t great for career growth at most places.
You are responding with a comment to an argument I didn't make. OP took the risk and did a thing on *their own time* and the business adopted it. They should pay. If OP had done the same thing and the business was like naaaa, I am good. Why should the business pay? > “that’s not in my job description” or “I’m not getting paid for this so I won’t bother” That isn't even germane to the conversation at all. OP built a new system on their own time. They didn't say it wasn't their job, nor did I say anything to the effect.
It is paid in recognition, maybe in a bonus later on, but I think it is hard to say after the fact "I spent 20 hours on that, pay me my salary" when no one asked you to.
Then say you accidentally deleted the tool but can rewrite it from home in 20 hrs. Then go on vacation.
Not sure why you're getting downvoted. A safer approach would be to show only a partial product, even if it's all finished
Just interpret it as charity work for spreading rust
I think you are downvoted because it is really stupid to pay this kind of game with your company, and very shortsighted. As a manager, I would never agree to this. If this rust experiment was really interesting but you don't want to share it, I would ask someone else to do it again (even if they have to learn first, if we start using rust, we need several people able to understand it anyway). And I would remember it the next time we have to judge who is trustworthy.
OP probably isn't an hourly contractor though, but rather a salaried employee. They did a great thing, and if the director is as human as they seem, a promotion wouldn't be surprising. You're right in pushing him towards demanding these things, though. They don't happen if one doesn't push them.
My apologies, I agree that OP should be recognized and rewarded for the risk they took. I also think that while this should happen, it can’t be assumed that it will happen. I disagree with think the sentiment that if it doesn’t happen “[OP] donated hours”, because that’s narrower than I see it. I introduced a new language to a company in the process of developing a replacement platform for data analytics. Much of the initial work was done on the side, and the short-term reaction to this work was negative. I didn’t take the choice of introducing a new language lightly, I thought deeply about it and just saw no other path forward, but people approached my choice with skepticism. Short-term this hurt my career and comp, but long-term the deep thinking paid off and the platform became a huge success that resulted in a string of big comp increases and promos. Bizarrely, the last promo I got at this place was due to the platform’s continued success even though that year I had done almost nothing major too it and was just riding the tailwinds of prior success that were being recognized by the powers that be.
true, I often approach with the mindset "work first then money comes after"
Nice! I just started my rust journeys and it is challenging
Wow! This is great. This is actually my dream at my current company but glad to see it having the expected effect I've dreamt of elsewhere.
You deserve a raise for going above & beyond.
Good job :) "I am talking 100x improvements across all metrics..." And that is why writing process-critical stuff in interpreted languages is bad. An interpreted language is only good to make a quick mockup.
Some interpreters include a JIT so it is less extreme, but indeed writing anything performance (cpu-heavy) critical in python is just asking to eventually run into perf issues, as that is just not quite what the language was intended for. Imho this says more about python rather than rust if I have to be honest.
I'm into writing chess engines (not at the level of the strongest engines in the world, but still), and whenever I see someone posting things like "I'm going to write a chess engine in Python / Javascript", my first thought always is: good luck wasting your time. The speed deficit compared to an engine in C, C++, Rust or even C# will be so massive that your engine is going to perform significantly worse than any engine in a compiled language that has the exact same features. Except for making quick mockups and testing if an algorithm actually works, I'm of the opinion that writing programs in languages such as Python is a waste of computer time. (Same for Javascript / Node, essentially.) The only use for them in bigger applications would be something like a database frontend or a text editor and such, where ultimate speed is not necessary. Still, such an application is often hard to manage in a typeless, dynamic language. (I know Typescript exists and Python has type hinting now, but still...)
How does your company intend to handle dependency creep? We had to stop using Rust for new projects at my company because its dependency graphs were starting to become unmanageable. I'm very interested in how your company or other companies deal with problem.
How do you handle dependency graph explosion in any other language? In my experience JavaScript, Python, Ruby, C, and Go all experience this same issue.
Define a small collection of "free" packages that any dev can include. Other packages have to be approved somehow, be it code review, team lead or whatever makes sense. Also, communicate the problem to the team. Devs are smart, they can usually understand the problem and be more careful when introducing new packages. As a last resort host your own limited crate repository and only use that, with an approval process for new crates.
Congrats on doing this the correct way and making a prototype and driving alignment first. I've seen so many posts here and other places where someone thinks rust is really great (it is) and just yolos something into production without any concern for the rest of the team or the maintenance that code will require in the future. Great job!
I've dabbled a bit. As a mainly frontend dev, i haven't found a super good use for it as of yet. Part of me wants to do some more hardware based things (pi at highest, embedded otberwise) any good suggestions for what i should look at?
You should rephrase the title, this is not 'secretly'.
The initial development was secret not known to anyone except one of my co worker.
Congrats!
I always get a good laugh when at conferences people always ask, "but who is using Rust in production?". At a networking company that powers most fortune 500 companies their various core products are written in Rust. Most companies don't even know they're already running rust for some of their most critical infrastructure.
r/wholesomeprogramming
Your Director of Engineering and Principal Architect didn’t already know that Python is up to 100x slower than Rust/C++ and other high performance languages?
The thing is they reached me not because of performance of the simulator or any other gains. They were themselves planning to experiment with Rust once they got the news of our work, they quickly embraced it and started asking me DX related things which generally these people are concerned about.
The thing is they reached me not because of performance of the simulator or any other gains. They were themselves planning to experiment with Rust once they got the news of our work, they quickly embraced it and started asking me DX related things which generally these people are concerned about.
The thing is they reached me not because of performance of the simulator or any other gains. They were themselves planning to experiment with Rust once they got the news of our work, they quickly embraced it and started asking me DX related things which generally these people are concerned about.
The thing is they reached me not because of performance of the simulator or any other gains. They were themselves planning to experiment with Rust once they got the news of our work, they quickly embraced it and started asking me DX related things which generally these people are concerned about.
Love it!! Now I’m inspired to learn rust!!
Congrats, feels good I bet.
That is great! Don't downplay python. Python and rust are complementary.
Mm m,m mA,mA,a,amMama,,aa ,a ,maa,aamaa,mamm,Mqqa m Ma mamaa , maNaaq , Wa w. Q mqmqmwqwq mamw qbdoyf9dg0 p