Rust
-
Sure, """borrow""" their money
I was making a rust joke.
-
I am glad for your comment because I work with mcus and embedded solutions in C, so Rust, in that case, wouldn't be neccesarily safer than C.
I will have to look into it. I need to do 30h of training every two years, so I will learn Rust regardless, but I was thinking about eventually switching to Rust for embedded projects. Might just keep Rust as my scripting language because it is easier for me than Python
It's an interesting discussion. As someone who doesn't actually deal with this and who literally never used Rust, I feel out of me depth. But it does sound like Rust has much better mechanisms to catch a programmer's mistake. See my reply to the other guy.
-
@rumba making new projects in rust sure cool but when big projects that most of the world relies on etc ffmpeg crucially need maintainers and contributions rust isnt needed and is a waste of resources when C can do it better, faster and easier rust is a fast fade that will likely remain in the shadow of C. Tbh your glazing rust without looking at both sides of the argument so the picture op posted really is true
Ahem...
If you want to ignore re-making things out of memory-safe technology as an advancement, we don't really have anything to talk about here.
-
I great example I saw is a dev who was building on a Rust game (with the Bevy engine), and switched to Unity.
https://deadmoney.gg/news/articles/migrating-away-from-rust
Collaboration - I started this project with my brother. While he's sharp and eager, he's new to coding. Onboarding him directly into game dev while simultaneously navigating Rust's unique aspects proved challenging. We found ourselves with a steeper learning curve that slowed his ability to contribute effectively to gameplay logic.
Abstraction - While my initial motivation was the enjoyment of Rust, the project's bottleneck increasingly became the rapid iteration of higher-level gameplay mechanics. As the codebase grew, we found that translating gameplay ideas into code was less direct than we hoped. Rust's (powerful) low-level focus didn't always lend itself to a flexible high-level scripting style needed for rapid prototyping within our specific gameplay architecture. I found that my motivation to build and ship fun gameplay was stronger than my desire to build with Rust.
Migration - Bevy is young and changes quickly. Each update brought with it incredible features, but also a substantial amount of API thrash. As the project grew in size, the burden of update migration also grew. Minor regressions were common in core Bevy systems (such as sprite rendering), and these led to moments of significant friction and unexpected debugging effort. This came to a head on one specific day where I was frustrated with a sprite rendering issue that had emerged in a new release. Blake had run into the same problem at the same time and our shared frustration boiled over into a kind of table flip moment. He turned to me and said something along the lines of "this shouldn't happen, this kind of thing should just be solved" and that triggered the conversation that led to a re-evaluation. The point isn't that specific sprite problem, but that because all systems in Bevy are open to tinkering and improvement, all systems were potentially subject to regressions.
Learning - Over the past year my workflow has changed immensely, and I regularly use AI to learn new technologies, discuss methods and techniques, review code, etc. The maturity and vast amount of stable historical data for C# and the Unity API mean that tools like Gemini consistently provide highly relevant guidance. While Bevy and Rust evolve rapidly - which is exciting and motivating - the pace means AI knowledge lags behind, reducing the efficiency gains I have come to expect from AI assisted development. This could change with the introduction of more modern tool-enabled models, but I found it to be a distraction and an unexpected additional cost.
Modding - Modding means a lot to me. I got my start in the industry as a modder and I want my game to be highly moddable. Over time, as I learned more about how to realize this goal, I came to understand many inherent limitations in Rust and Bevy that would make the task more difficult. Lack of a clear solution to scripting and an unstable ABI (application binary interface) raised concerns. I am not an expert in this area, perhaps these are all easily surmounted. I can only say that I did not find a path (after much searching) that I felt confident trusting.
It sounds like Rust (game engines, and more) could use a higher level scripting language, or integrate an existing one, I guess.
Rust [...] could use a higher level scripting language, or integrate an existing one, I guess.
One approach is to use more macros. These are still rooted in the core Rust language, so they give up none of the compile-time checks required for stability. The tradeoff is more complex debugging, as it's tough to implement a macro without side effects and enough compile-time feedback that you'd expect from a DSL.
Another is to, as you suggest, embed something. For example, Rust has Lua bindings. One could also turn things inside out and refactor the rust program (or large portions of it) as a Python module.
-
a community that allows squatting to happen and does nothing to resolve the issue is going to be plagued with chaos in the future. it opens an attack vector for supply chain attacks and altogether breeds distrust in the platform entirely.
on the flip-side, a developer that squats on common library names in an attempt to garner support to resolve an issue and is ignored tells me two things;
- this is normal enough that the community doesn't feel the need to address the toxic behavior
- the issue of squatting isn't perceived as a high enough threat and they will take no action
in my case both of those observations tell me the community at large isn't mature enough or forward thinking enough to allow me to use it as a solution. it also forces me to assume that the matter of toxic behavior will only continue to fester unchecked within the community.
I guess, that's an opinion to have then. I interpreted your point about toxicity to mean something different.
I will say that it certainly isn't the case that no one in the community cares about namesquatting. You can likely find lively discussions around that right now.
But I have to admit that I don't concern myself with it too much.
The thing for me is that one of the solutions that people suggest (for some of the problems that namesquatting has) is namespacing. And Rust kind of already has that, because it's already pretty customary to create basically meta-packages with feature-flags to pull in other packages transitively, meaning your users will only need to get one package name right.Well, and the other thing is that the official package registry isn't nearly as important in Rust as it is in many other languages, because you can also specify dependencies by providing the URL to the Git repository, with no registry involved. It's mostly just for visibility that you'd stick something onto the official registry.
-
Piefed is not written in Rust.
No one was talking about piefed.
-
Piefed is not written in Rust.
not yet
-
Piefed is not written in Rust.
I am still mentally in lemmy lol. Switch to piefed was pretty recent.
-
I am convinced Rust haters are simply refusing to learn something new, consciously or not.
I don't like rust because I'm too stupid to understand it
-
not yet
evil maniac laughter
-
Be careful, a Rust Dev will accuse you of FUDposting! They might even try to collect evidence on you for being "a terrible person", then sending their followers after you, then individually contact all your publicly known friends about it!
Okay, Christoph Hellwig.
-
Okay, Christoph Hellwig.
Sorry, but Rust is still just as much a "not a functional programming language" as Java is "not an object oriented programming language"...
-
Where would you say Rust isn't the right solution?
We always hear how great Rust is, but I'd be curious to know where it isn't.
We always hear how great Rust is, but I’d be curious to know where it isn’t.
-
In any project that's sufficiently advanced and written in any other language. You don't simply do a rewrite of 100k+ LOC just because you want to use Rust.
-
Somewhere where you'd rather use a scripting language like Python. I.e., rapid prototyping or gluing together some infra components.
-
A situation where your team's expertise is in some other language.
-
A situation where a library/framework is native/only available for a certain language.
Few of these are strictly technical requirements. It's obvious that you can use almost any language to do almost anything, including Rust, if that's what you prefer. However, the context matters in the real world.
All this being said, I wish I had a chance to write Rust professionally. It's a neat language.
-
-
We always hear how great Rust is, but I’d be curious to know where it isn’t.
-
In any project that's sufficiently advanced and written in any other language. You don't simply do a rewrite of 100k+ LOC just because you want to use Rust.
-
Somewhere where you'd rather use a scripting language like Python. I.e., rapid prototyping or gluing together some infra components.
-
A situation where your team's expertise is in some other language.
-
A situation where a library/framework is native/only available for a certain language.
Few of these are strictly technical requirements. It's obvious that you can use almost any language to do almost anything, including Rust, if that's what you prefer. However, the context matters in the real world.
All this being said, I wish I had a chance to write Rust professionally. It's a neat language.
Lots of your point apply to any language it seems. I should have specified new projects I guess.
But the points you've made are good nonetheless
-
-
Rust [...] could use a higher level scripting language, or integrate an existing one, I guess.
One approach is to use more macros. These are still rooted in the core Rust language, so they give up none of the compile-time checks required for stability. The tradeoff is more complex debugging, as it's tough to implement a macro without side effects and enough compile-time feedback that you'd expect from a DSL.
Another is to, as you suggest, embed something. For example, Rust has Lua bindings. One could also turn things inside out and refactor the rust program (or large portions of it) as a Python module.
Are Rust macros akin to the C macros? Basically an inline replacement of a code section?
-
Are Rust macros akin to the C macros? Basically an inline replacement of a code section?
wrote last edited by [email protected]Kind of. They do center on code generation, at the end of the day. That's where the similarities end. You can't insert macros into your code arbitrarily, nor can you generate arbitrary text as an output. Rust macros take parsed tokens as input, and generated (valid) code as output. They must also be used as annotations or similar to function calls, depending on how they're written. The limitations can be frustrating at times, but you also never have to deal with brain-breaking
#defineshenanigans either.That said, I've seen some brilliant stuff. A useful pattern is to have a macro span a swath of code, where the macro adds new/additional capabilities to vanilla Rust code. For example, here's a parser expression grammar (PEG) implemented that way: https://github.com/kevinmehall/rust-peg
-
I like how this takes familiarity with the original xkcd comic as a given.
I think half of Lemmy knows most of XKCD
-
I am convinced Rust haters are simply refusing to learn something new, consciously or not.
“Everyone is gunning for you when you're at the top!”
~ someone, after CE
