Ask HN: Is Rust worth investing in as a reliable C-alt given its recent saga?
46 comments
Technically, the language is excellent. Organizationally, major corporations have invested a lot of resources into it, they won't allow it to fail. Community-wise, there are lots of friendly and supportive people in the quieter corners (this is true most everywhere, I think).
That being said, my recommendation for learning systems programming would be to consider trying plain old C first. Rust's safety features are a godsend, but IMO easier to understand once you have experienced working without them. (Similarly, I like to recommend leaning a dynamically typed language first, and introducing static typing later.)
That being said, my recommendation for learning systems programming would be to consider trying plain old C first. Rust's safety features are a godsend, but IMO easier to understand once you have experienced working without them. (Similarly, I like to recommend leaning a dynamically typed language first, and introducing static typing later.)
> Rust's safety features are a godsend, but IMO easier to understand once you have experienced working without them.
Passing around a pointer becomes passing around a borrow or a Mutex<T> or Arc<Mutex<T>>.
Not sure how you'd summarize Rc<T> or Box<T>
Passing around a pointer becomes passing around a borrow or a Mutex<T> or Arc<Mutex<T>>.
Not sure how you'd summarize Rc<T> or Box<T>
Well, it depends on what you define by passing a pointer. Is the pointer mutable (needs to modify the data it is pointing at?) or immutable? Is it a reference ("guaranteed" pointer?) Or just a plain old pointer? (const T and mut T)? Or do you want a smart pointer, like Box<T> or a unique_ptr-ish thing with a reference counted pointer via Rc<T>?
Want to pass and modify data from and to multiple threads? Yea just drop an Arc<Mutex<T>> and you're good to go. If you just want to pass some data, even around threads, without modifying it, then a plain old borrow is your best bet. Make sure to get the lifetimes right tho!
Want to pass and modify data from and to multiple threads? Yea just drop an Arc<Mutex<T>> and you're good to go. If you just want to pass some data, even around threads, without modifying it, then a plain old borrow is your best bet. Make sure to get the lifetimes right tho!
Rc<T> is a chunk of memory you can only access through special versions of malloc and free. These don’t actually allocate new memory with the OS though, they just give you pointers to the memory and tell the memory management system that you’re done using it. Once everyone who has allocated that memory calls free, then the memory is actually given back to the OS. Box<T> is the same, except if you have multiple people try to call the special malloc it will fail to compile.
I definitely have to agree with this. C was both easy and hard. Easy because the syntax and stdlib were both simple. Hard because you had to learn pointers/memory management.
Also, side note: C != C++.
Also, side note: C != C++.
> Easy because the syntax and stdlib were both simple.
the stdlib could have like ~5 ease of life things (linked list, hashmap come to mind) that would have made a world of difference in my opinion
the stdlib could have like ~5 ease of life things (linked list, hashmap come to mind) that would have made a world of difference in my opinion
+1 for C before Rust. It will help you appreciate the logic behind the borrow checker much easier.
Also once you learn C, you never lose C. C will still be around, and it's good knowledge, it's not wasted knowledge. C doesn't really change anymore. You can take it to the grave.
C forces you to have a good understanding of what the hardware does compared to high level languages, but without the assembly grind.
Also once you learn C, you never lose C. C will still be around, and it's good knowledge, it's not wasted knowledge. C doesn't really change anymore. You can take it to the grave.
C forces you to have a good understanding of what the hardware does compared to high level languages, but without the assembly grind.
Just a recommendation, but learn Rust first. Once you have a good intuition about mutability xor aliasing (which is what the borrow checker enforces), you'll actually write better C and C++ code should you need to.
Personally, I think Rust is the future of systems programming and there's no more reason to learn C / C++ than there is a reason to learn FORTRAN or COBOL (specifically, the reason is only ever "I need to get a job using those languages"). But, you know, feel free to take that with a grain of salt and see for yourself.
Rust isn't going anywhere any time soon given how many big companies use it, so even if you learn C/C++ first, you'll likely need to learn rust as well eventually if you want to do systems stuff.
Personally, I think Rust is the future of systems programming and there's no more reason to learn C / C++ than there is a reason to learn FORTRAN or COBOL (specifically, the reason is only ever "I need to get a job using those languages"). But, you know, feel free to take that with a grain of salt and see for yourself.
Rust isn't going anywhere any time soon given how many big companies use it, so even if you learn C/C++ first, you'll likely need to learn rust as well eventually if you want to do systems stuff.
In my opinion, it's better to learn C first because it forces you to do a lot of painful memory management manually. You tend to really appreciates Rust's features when you understand how things can go wrong. Need absence to value presence.
I kinda disagree, I learned assembly after I learned C and I felt like I still appreciated it
can you please share how you actually learned assembly and the resources you've used for it?
It was in college, had a couple of courses that involves writing some things in assembly. There's not a lot to assembly, but when you write it you realize how function calls involve a bunch of arbitrary choices, and the stack is part of the c runtime, etc. I definitely wouldn't call myself an expert, but the experience was illuminating coming from the world of higher level languages.
I agree with what other posters say here regarding building, specifically, C knowledge first.
Further, I've noticed a trend highlighted by people such as Jonathan Blow that there are users of Rust who don't fully understand object lifetimes in particular systems and are hacking around warnings in Rust creating unsafe memory scenarios while being told otherwise because all of their compiler messages have disappeared.
Some things in software engineering are hard, but you can't escape them. It seems like you can only defer the problem until you actually need to understand what's going on, and by the time you realize that, you'll be deep in experience with "weird holes" in your knowledge (as I fondly remember a (pre-?)algebra teacher telling me when I was discussing quaternions in middle school.)
Further, I've noticed a trend highlighted by people such as Jonathan Blow that there are users of Rust who don't fully understand object lifetimes in particular systems and are hacking around warnings in Rust creating unsafe memory scenarios while being told otherwise because all of their compiler messages have disappeared.
Some things in software engineering are hard, but you can't escape them. It seems like you can only defer the problem until you actually need to understand what's going on, and by the time you realize that, you'll be deep in experience with "weird holes" in your knowledge (as I fondly remember a (pre-?)algebra teacher telling me when I was discussing quaternions in middle school.)
To me, it looks like Rust is suffering from "cool kids syndrome." It's hip right now, and all the cool kids are piling in, or some of the people who have been using it for a while are hoping to cash in social capital.
I don't understand this way of using technology or being in this profession; self promotion and dialogue through twitter, blog posting all over the place, conferences, panels, books, speaking tours, ego & self promotion all built around particular tools.
In the end these are tools for writing software and we get paid. Is Rust a better tool that some others? Yes, and it's what I'm working with these days. But it's not a lifestyle, and it should not be a culture/subculture. Other professions don't generally talk this way about their tools, why are certain people in software like this?
To answer the question: Rust is a good systems programming language. But I will say this: many of the people piling into it right now don't actually need Rust.
I don't understand this way of using technology or being in this profession; self promotion and dialogue through twitter, blog posting all over the place, conferences, panels, books, speaking tours, ego & self promotion all built around particular tools.
In the end these are tools for writing software and we get paid. Is Rust a better tool that some others? Yes, and it's what I'm working with these days. But it's not a lifestyle, and it should not be a culture/subculture. Other professions don't generally talk this way about their tools, why are certain people in software like this?
To answer the question: Rust is a good systems programming language. But I will say this: many of the people piling into it right now don't actually need Rust.
For some, programming is a lifestyle, and a culture, and has nothing to do with getting paid.
In my experience, these people and their projects tend to be more interesting.
In my experience, these people and their projects tend to be more interesting.
I program for fun and have since I was 8 years old on a VIC-20. I look forward to retiring so I can work on all the software projects I love without the distraction of work.
But I don't do twitter, or the conference circuit, or blog. And I learned long ago to stay away from committee & project politics.
Programming being a lifestyle means programming, not self-marketing or getting into turf wars.
But I don't do twitter, or the conference circuit, or blog. And I learned long ago to stay away from committee & project politics.
Programming being a lifestyle means programming, not self-marketing or getting into turf wars.
IMHO, one should make one's language choices based on utility and NOT solely on metacharacteristics such as quality of governance, DEI efforts, or nation of origin. None of these things matter when the program is run, if the process and end result do not solve the problem(s) at hand.
Thorough feature discussion, appropriate licensing, and accessibility of source code for risk evaluation are metacharacteristics that are relevant.
And-lest anyone think that, as a white cisgender male born in America, I have no skin in the game, it is my belief that any interactions with others ought to be principled on transparent rigor and mutual respect, from which all other things should flow.
Thorough feature discussion, appropriate licensing, and accessibility of source code for risk evaluation are metacharacteristics that are relevant.
And-lest anyone think that, as a white cisgender male born in America, I have no skin in the game, it is my belief that any interactions with others ought to be principled on transparent rigor and mutual respect, from which all other things should flow.
solely
I agree with that, but that stuff you mention is still a factor. Politics is creeping into everything, and there are lots of reasons why choosing a relatively politically stable language is important, though obviously not the only factor. I think the best one could hope for is a lot of diverse groups with different political views and motivations being invested in the future of a language, so that despite any culture war stuff, there's likely to be a useful version that survives.
I agree with that, but that stuff you mention is still a factor. Politics is creeping into everything, and there are lots of reasons why choosing a relatively politically stable language is important, though obviously not the only factor. I think the best one could hope for is a lot of diverse groups with different political views and motivations being invested in the future of a language, so that despite any culture war stuff, there's likely to be a useful version that survives.
Microsoft and Alphabet have plenty of motivation to keep things on track, as does the Linux Foundation and others. I suspect that, if things get completely out of hand, that corporate sponsors might impress their will upon the Rust Foundation to address any issues around governance.
Politics will creep into anything, if one allows that to happen.
Politics will creep into anything, if one allows that to happen.
Google and Microsoft are political entities with their own political agendas that sometimes aren't aligned with profit making. Many of the activists in CoC dominated communities don't care the slightest bit about profit or even continued existence of their entity if it means they can enforce their brand of ideological purity. FAANG entities threatening to reduce or eliminate resource allocation to a project will for some be evidence of the capitalistic desire to control everything and will motivate the community to welcome the purge of the unclean from their community.
Heh Heh Heh
New potential language feature: "Not created nor maintained by Americans". ;) (/s)
Though that in itself potentially opens up other cans of worms, some of which could also be not good.
New potential language feature: "Not created nor maintained by Americans". ;) (/s)
Though that in itself potentially opens up other cans of worms, some of which could also be not good.
I was not aware that there are any recent issues with the Rust community since I don't use Rust. while technical characteristics of a language are important the ability of a community to continue supporting the language for the long term is also important. Go has Google backing it, Java has Oracle backing it, etc. Is there enough corporate use of Rust that if the current Rust community falls apart someone will create a stable version of the language and toolchain that will be maintained and updated?
I was not aware that there are any recent issues with the Rust community
And this: https://news.ycombinator.com/item?id=36105637
And this: https://news.ycombinator.com/item?id=36106942
If you have no experience with low level programming I think it is better to learn c first anyway. It will help you understand some of the problems that Rust's design solves.
Rust is technically excellent, and has significant buy-in from major corporations, who won't allowwz their investments to go to waste. I wouldn't worry about the drama.
I program a lot of personal projects and just ignore the drama. It's a fun language to program in, and whatever dramatics the core team is engaged in, they've still managed to put out an excellent language and ecosystem.
Yes. Excellent modern language with vibrant package management ecosystem. Some of the memory semantics can be a bit tricky to keep straight when to do what and why, but as you understand ownership and borrowing better it gets easier and more intuited. Good trait and generics strategies can be tricky, and asynch is a bit clumsy at times.
Every community has its fair share of drama. I wouldn't worry too much about such things.
This kind of thing has happened forever, it's just thst before social media it was confined to obscure listservs and usenet channels and most of the people using the language would never see it.
Every town has crime but some towns have far more crime than others.
Yes absolutely. The politics is stupid crap. If everyone in the rust org quit the community would continue onwards just fine.
Rust is a great language with a lot of advantages and is absolutely worth considering for your next project.
Rust is a great language with a lot of advantages and is absolutely worth considering for your next project.
I found programming in Rust is fun. The std library provides efficient implementation for your need, which made your time spent worth it.
Whatever your goal is, it's worth your time as i see it.
Whatever your goal is, it's worth your time as i see it.
Community drama is a terrible way to evaluate a language.
Software already has a big problem with toxic childish behaviors.
I asked my mom who used to audit businesses what was important about founders and CEO's and she said they more than anyone else set the companies culture. I feels to me like that seems to be true of the culture surrounding various programming langs.
I asked my mom who used to audit businesses what was important about founders and CEO's and she said they more than anyone else set the companies culture. I feels to me like that seems to be true of the culture surrounding various programming langs.
A decent metric for community maturity though. That absolutely should be a factor in deciding on a language.
I'm having a real hard time seeing this unfold among the greybeards that call the shots in Java or C++.
I'm having a real hard time seeing this unfold among the greybeards that call the shots in Java or C++.
Granted, the reason for that could be that through the years the greybeards that call the shots have weeded out (whether unintentionally or intentionally) any voices that are incompatible with their way of doing things. I agree that it does indicate the maturity of the community, but that could be because the community's values become more homogenous.
[deleted]
If you are going to spend your life in the ecosystem it can matter a lot
crote(1)
As an outsider who's keeping an eye on Rust, am I better off sticking to vanilla C/C++?