Ask HN: Is Learning Rust a Must?
Everywhere I read , I notice people talk about rust and how everything is being rewritten in rust. Is learning rust is must now ?
60 comments
I'll take a contrarian view. C++ which Rust proponents usually target for replacement, is an extremely well tested language. In any real commercial application where a system programming language is needed, C++ would usually be a better choice if you know the language. If don't know C++, learn Rust, it's probably easier, and you'll make progress faster. But Modern C++ is extraordinarily powerful -- it may be worth learning to build some high performance systems like games and browsers.
This is good advise. Our large shop has so much C++ nobody here is gonna run and hide from it. Our libs are large, in large numbers. So not having C++ is a disadvantage.
And for those same reasons we know building C++ is giant pain in the butt.
Given the opportunity, I would seriously consider Rust when rearchitecting a system to peel off small bits I can do 100% RUST because I then can escape C++ dependency/cmake/DPKG/RPM hell to something closer to GO.
When I deal with old C++ code not brought up to current build spec at our place I can waste 30-40% of my time getting various things to build. Getting the old code into the new system is now easier, but I killed a week learning it. And should I have to deal with a library off the beaten path who's dependencies I don't know, getting it into the new build system will be a pain-plus because I will then have to find/compute/assess its dependencies.
Getting out from all this nonsense is, I think, is an undersold part of RUST. You still get static types, C++ performance, memory safety, and you get a running start to CDCI because at least getting the darn PR built is a 4 to 6 Phd job of hand holding C++ through dep management.
And for those same reasons we know building C++ is giant pain in the butt.
Given the opportunity, I would seriously consider Rust when rearchitecting a system to peel off small bits I can do 100% RUST because I then can escape C++ dependency/cmake/DPKG/RPM hell to something closer to GO.
When I deal with old C++ code not brought up to current build spec at our place I can waste 30-40% of my time getting various things to build. Getting the old code into the new system is now easier, but I killed a week learning it. And should I have to deal with a library off the beaten path who's dependencies I don't know, getting it into the new build system will be a pain-plus because I will then have to find/compute/assess its dependencies.
Getting out from all this nonsense is, I think, is an undersold part of RUST. You still get static types, C++ performance, memory safety, and you get a running start to CDCI because at least getting the darn PR built is a 4 to 6 Phd job of hand holding C++ through dep management.
One thing I think I missed, was how pleasant it it is to program in modern C++. There are no pointers, for the most part completely automatic memory management (with the RAAI) idiom. Build systems are still a pain. I recently built a physics simulator for an n-body type interaction problem in C++. Not a a large program (about 40K lines of code) but the experience was extremely pleasant. For build I used a combination of make for Linux and macOS and nmake and VisualStudio projects. Debuggers on Linux are still a bit bad. GDB with Emacs is fine but, is somewhat primitive compared to VisualStudio and even Xcode. Other than that it was a joy to actually write in C++.
The primary reason, I think was because there was no legacy code I had to deal with.
The primary reason, I think was because there was no legacy code I had to deal with.
Do you know of any good resources for picking up modern C++?
I’ve used this book in the past to learn modern C++: https://www.amazon.com/dp/1484233654/ref=cm_sw_r_cp_awdb_imm...
For greenfield projects I’d opt for Rust over C++.
For greenfield projects I’d opt for Rust over C++.
We taught Rust at Masters-level as part of a course meant to show engineering students a variety of concepts from innovative programming language (there was also Haskell and Scala). Learning Rust is a must (at least for our kind of students), but not because "everything is being rewritten in Rust".
First, I think knowing concepts from various languages makes better programmers. But Rust in particular is part of a family of languages along with C++ that are very powerful and versatile, but that require a strong discipline in order to write correct programs. And while C++ is more widespread currently, learning Rust teaches you this discipline, simply because the compiler will keep rejecting your programs until you understand it. C++ compilers on the other hand happily accept nonsensical programs, and it is hard to find modern C++ experts to teach this skill (and sometimes it is even hard to get experts agree on what the discipline is!). Yet in some areas where C++ has few alternatives, unreliable software can have huge consequences. So learning Rust is important because it will also make of you a better C++ programmer.
First, I think knowing concepts from various languages makes better programmers. But Rust in particular is part of a family of languages along with C++ that are very powerful and versatile, but that require a strong discipline in order to write correct programs. And while C++ is more widespread currently, learning Rust teaches you this discipline, simply because the compiler will keep rejecting your programs until you understand it. C++ compilers on the other hand happily accept nonsensical programs, and it is hard to find modern C++ experts to teach this skill (and sometimes it is even hard to get experts agree on what the discipline is!). Yet in some areas where C++ has few alternatives, unreliable software can have huge consequences. So learning Rust is important because it will also make of you a better C++ programmer.
No, this is an echo chamber thing. The commercial software industry has largely not even heard of Rust. (Arguably they should!)
The number of jobs available to purely write Rust code in the world is still very very small.
The number of jobs available to purely write Rust code in the world is still very very small.
If you like it.
If you are interested in systems work you will need to know some C++ even if you don’t like it.
What I really want is a theorem prover attached to a macro assembler, that might scratch the rust itch better than rust.
If you are interested in systems work you will need to know some C++ even if you don’t like it.
What I really want is a theorem prover attached to a macro assembler, that might scratch the rust itch better than rust.
This comment is completely off the main topic, however, you are the first person I have encountered reading HN that is looking for a macro-assembler and theorem prover combo. I built a language to use just for my day to day and keep tinkering with it when I feel like it. One of the modes of operation is at least on the path to what you asked for. Right now, it is more of a generating C or C++ with full spectrum dependent types (i.e. it misses the convenience of the standard theorem provers). I find that it is quite practical for what I use it for, which is usually not at the full dependent type level, but it certainly works for me. I have toyed with making what would effectively be an assembly back end, but compiling to C++ usually fits my requirements. No real point in this comment, just wanted to cheer for another dev who seems to find interest in similar subjects.
[deleted]
I’ve been exploring a similar space. Mind expanding on why you think the combo sticks?
It is a long story, feel free to send me an email, but I'll summarize. I think it "sticks" technically but find it hard to see how it works as a business.
I spent a lot of time working in the semantic web space heading in the direction of "low/no code" and was struck at how logic-basic programming (not just constraint languages but production rules and other approaches) has been dead in the water since the 1980s despite the tools getting much better and numerous but isolated success stories.
Lately I got into the Arduino hobby and I've developed a number of things that are basically "traverse an object graph in program memory with several cursors" while doing a few streams of I/O.
(Imagine I have a SPI lightstrip on my car and program memory has a set of dingbats, color palettes, a picture of a McLaren F1 and instructions to put it all together. For now I tell the driver to use the cruise control, someday it reads from maybe the CAN bus, GPS and accelerometer and runs a Kalman filter to stick the GFX to the ground)
In a program like that the functions divide neatly into several layers and everything can be statically allocated and the more I think about it, the more I think the way C thinks about functions (return values, calling conventions, etc.) is not a good fit for the problem. I have no need for the stack, can allocate a few registers for the interrupt handlers, etc.
Thus I think "C sucks" and I am no fan of gas (designed by somebody who hates assembly language but doesn't see the C-thulhu in old-school C compilers.)
There are lots of papers where people apply theorem proving to assembly and seem to have an easier time than they do with languages like C. Maybe the behavior of the system is better defined, maybe you get into combinatorical problems with automatic allocation, etc.
My C programs statically allocate as much as possible and have notes that say what color the functions are and informally justify that the thing works. I feel like a dork knowing how much wasted activity the C code is doing behind my back and think about re-writing it in AVR-8 assembly with even more detailed notes...
... so if those "notes" were a machine-readable proof that the memory allocation and other things in the program were correct and otherwise the system could SMT solve for things I don't want to code by hand that would be sweet.
(A positive in this application is that the program is going to be small but the compiler is going to run on a much bigger machine.)
As a business though I don't believe it.
Even a Pascal-like or FORTRAN-like language without any real technical innovation is a bad enough sell for this market; Arduino using C is good for "education" because learning some C is useful, even if it teaches bad habits like BASIC.
Portability is a problem too. I think AVR-8 is beautiful but it is a dead end but when the going gets tough I am going to swap in an RP2040 and add some transistors to shift levels.
On top of that, expecting people to learn multiple new technologies is a big ask. I am sure many people think "C sucks" but jumping to the system I envision means learning assembly language, theorem proving, and a few other things. I could write many C programs in the time it would take to get that system up to the point where I could use it, and the investment would be several times that before other people could use it.
I spent a lot of time working in the semantic web space heading in the direction of "low/no code" and was struck at how logic-basic programming (not just constraint languages but production rules and other approaches) has been dead in the water since the 1980s despite the tools getting much better and numerous but isolated success stories.
Lately I got into the Arduino hobby and I've developed a number of things that are basically "traverse an object graph in program memory with several cursors" while doing a few streams of I/O.
(Imagine I have a SPI lightstrip on my car and program memory has a set of dingbats, color palettes, a picture of a McLaren F1 and instructions to put it all together. For now I tell the driver to use the cruise control, someday it reads from maybe the CAN bus, GPS and accelerometer and runs a Kalman filter to stick the GFX to the ground)
In a program like that the functions divide neatly into several layers and everything can be statically allocated and the more I think about it, the more I think the way C thinks about functions (return values, calling conventions, etc.) is not a good fit for the problem. I have no need for the stack, can allocate a few registers for the interrupt handlers, etc.
Thus I think "C sucks" and I am no fan of gas (designed by somebody who hates assembly language but doesn't see the C-thulhu in old-school C compilers.)
There are lots of papers where people apply theorem proving to assembly and seem to have an easier time than they do with languages like C. Maybe the behavior of the system is better defined, maybe you get into combinatorical problems with automatic allocation, etc.
My C programs statically allocate as much as possible and have notes that say what color the functions are and informally justify that the thing works. I feel like a dork knowing how much wasted activity the C code is doing behind my back and think about re-writing it in AVR-8 assembly with even more detailed notes...
... so if those "notes" were a machine-readable proof that the memory allocation and other things in the program were correct and otherwise the system could SMT solve for things I don't want to code by hand that would be sweet.
(A positive in this application is that the program is going to be small but the compiler is going to run on a much bigger machine.)
As a business though I don't believe it.
Even a Pascal-like or FORTRAN-like language without any real technical innovation is a bad enough sell for this market; Arduino using C is good for "education" because learning some C is useful, even if it teaches bad habits like BASIC.
Portability is a problem too. I think AVR-8 is beautiful but it is a dead end but when the going gets tough I am going to swap in an RP2040 and add some transistors to shift levels.
On top of that, expecting people to learn multiple new technologies is a big ask. I am sure many people think "C sucks" but jumping to the system I envision means learning assembly language, theorem proving, and a few other things. I could write many C programs in the time it would take to get that system up to the point where I could use it, and the investment would be several times that before other people could use it.
There will always be a popular language, if your goal is to get eyes on your stuff and get on the front page of HN, sure, write it in rust. If it were two years ago, I'd say write it in Go. If it were 5 years before that, I'd say NodeJS.
Please keep in mind that there is more to software dev than web programming. Rust may not be popular as as server language now and never may be, but there are multitudes of other reasons why one should consider learning Rust.
No, but why the reluctance? Not that you must learn it, but being open to learning new things as an engineer (or just about anyone) is generally positive.
Not OP but Rust is a skill I’d like to prioritize if I were more confident in being allowed to use it professionally. It seems most employers feel (maybe rightly) they’re better off using Blub languages and renting more hardware.
It’s not enough to find one Rust shop, I need to expect the next shop also to value the time I invested.
It’s not enough to find one Rust shop, I need to expect the next shop also to value the time I invested.
I think you spend too much time on HN :-)
> I notice people talk about rust and how everything is being rewritten in rust. Is learning rust is must now ?
Like all other programming languages, only if you need it and if it fits your use-case. Otherwise a better language can be used instead.
If it were me, the language I'd learn and use is the one that makes me the most money possible. At this stage for me, it is not Rust.
Like all other programming languages, only if you need it and if it fits your use-case. Otherwise a better language can be used instead.
If it were me, the language I'd learn and use is the one that makes me the most money possible. At this stage for me, it is not Rust.
What would your pick be?
No.
Rust is a good language in many ways - generally well-designed, innovative, aimed at some under-served but important use-cases, very educational to learn, and surrounded by a lively community.
But only a tiny fraction of the world's work and innovation is being done in Rust. There is a huge amount of interesting stuff happening in other languages. There is also much more work available in other languages - even interesting, well-paid work.
Reasons to learn Rust right now:
1. You need to learn a low-level systems language, for use on a platform that Rust supports; i think Rust is a better bet for many uses than C++ already.
2. You have copious time to invest in learning, and ownership type systems are the most interesting or powerful thing you don't currently know.
3. There is some specific piece of software you want to get involved with, and it's written in Rust.
Rust is a good language in many ways - generally well-designed, innovative, aimed at some under-served but important use-cases, very educational to learn, and surrounded by a lively community.
But only a tiny fraction of the world's work and innovation is being done in Rust. There is a huge amount of interesting stuff happening in other languages. There is also much more work available in other languages - even interesting, well-paid work.
Reasons to learn Rust right now:
1. You need to learn a low-level systems language, for use on a platform that Rust supports; i think Rust is a better bet for many uses than C++ already.
2. You have copious time to invest in learning, and ownership type systems are the most interesting or powerful thing you don't currently know.
3. There is some specific piece of software you want to get involved with, and it's written in Rust.
Disclaimer: Rust fanatic
Sidenote, i think a lot of the tech crowd forgets how much industry will lag behind popularity, for a whole bunch of good reasons. My shop uses Rust, and all our hires are aimed at Rust, and it's still not easy - there's not a ton of people who know Rust. We would have a ton of candidates in Python, JavaScript(Node), even Go. Hell even PHP.
The fact is that applicants tend to follow jobs, so you get a chicken-egg problem. New languages have a huge hill to climb in adoption and it takes years for companies to build up large codebases in new languages to result in a large job pool.
Take any previously popular, old and uninteresting language and know it well - and you can get jobs for years and years and years to come. There's just a ton of code out there written in it that needs support, extension, etc.
I always recommend learning Rust but it is certainly not a must.
Sidenote, i think a lot of the tech crowd forgets how much industry will lag behind popularity, for a whole bunch of good reasons. My shop uses Rust, and all our hires are aimed at Rust, and it's still not easy - there's not a ton of people who know Rust. We would have a ton of candidates in Python, JavaScript(Node), even Go. Hell even PHP.
The fact is that applicants tend to follow jobs, so you get a chicken-egg problem. New languages have a huge hill to climb in adoption and it takes years for companies to build up large codebases in new languages to result in a large job pool.
Take any previously popular, old and uninteresting language and know it well - and you can get jobs for years and years and years to come. There's just a ton of code out there written in it that needs support, extension, etc.
I always recommend learning Rust but it is certainly not a must.
If you're hiring for specific language experience you're doing something wrong
Would be true for other languages which are more or less similar enough that knowing one is enough: Java, JavaScript, Ruby, Python et al.
But for Rust, looking for language experience might be the right choice since the learning curve is relatively steep and takes time. Unless, of course, the company is okay giving 2 months to just learn.
But for Rust, looking for language experience might be the right choice since the learning curve is relatively steep and takes time. Unless, of course, the company is okay giving 2 months to just learn.
A great example of this is Jane Street. They write "all" of their software in OCaml. They have a 2 week up-to-speed course about their tools and language. I don't expect it to take too much effort to get up to speed in any language if you're already a programmer. You might. It be peak efficiency but you'll get pretty good faster than you think. The static friction force makes it not feel that way
> But for Rust, looking for language experience might be the right choice since the learning curve is relatively steep and takes time. Unless, of course, the company is okay giving 2 months to just learn.
Yea, this is our opinion. Our options are limited due to the smaller talent pool, so the time it takes for devs to "spin up" is something we consider. We can't hire a full team of devs who take 2 months to spin up. We can, maybe, do 5 young devs and 5 seasoned devs.
I've personally found that devs who have experience with C++ are almost a direct shoe-in. They know all the concepts and the transition seems easy, especially since they're already interested in Rust. Having hired a few dynamic language folks though, they have a higher barrier to entry with Rust. A lot more concepts to learn.
Yea, this is our opinion. Our options are limited due to the smaller talent pool, so the time it takes for devs to "spin up" is something we consider. We can't hire a full team of devs who take 2 months to spin up. We can, maybe, do 5 young devs and 5 seasoned devs.
I've personally found that devs who have experience with C++ are almost a direct shoe-in. They know all the concepts and the transition seems easy, especially since they're already interested in Rust. Having hired a few dynamic language folks though, they have a higher barrier to entry with Rust. A lot more concepts to learn.
This statement is so odd. So we should hire to bring on people who want to work in PHP, and then force them to use Rust?
We have a large codebase in Rust. We're hiring devs who want to use Rust. Why is that "doing something wrong"?
edit: Maybe you think we require full Rust mastery on hiring. We don't. Though we make it clear that work on a Rust codebase is ~~expected~~ required, and familiarity with generalized concepts like static/dynamic dispatch are important. We hire young Rust devs all the time.
We have a large codebase in Rust. We're hiring devs who want to use Rust. Why is that "doing something wrong"?
edit: Maybe you think we require full Rust mastery on hiring. We don't. Though we make it clear that work on a Rust codebase is ~~expected~~ required, and familiarity with generalized concepts like static/dynamic dispatch are important. We hire young Rust devs all the time.
What I mean is that hiring for particular languages is a massive red flag to me in job listings.
I don't mean saying something like "our tech stack is in Rust." More like "3-5 years experience in Rust" under the job requirements.
It's not hard to learn a new language or train it in good engineers. If you're limiting your candidate pool based on particular language experience you are severely limiting the growth potential of the business. That's just been my experience.
And if your reasoning is something like, "Rust is hard and it's going to take N weeks to onboard a dev to contribute and we can't afford that" then it's an even bigger red flag about the engineering capacity of the business and state of development.
I don't mean saying something like "our tech stack is in Rust." More like "3-5 years experience in Rust" under the job requirements.
It's not hard to learn a new language or train it in good engineers. If you're limiting your candidate pool based on particular language experience you are severely limiting the growth potential of the business. That's just been my experience.
And if your reasoning is something like, "Rust is hard and it's going to take N weeks to onboard a dev to contribute and we can't afford that" then it's an even bigger red flag about the engineering capacity of the business and state of development.
> I don't mean saying something like "our tech stack is in Rust." More like "3-5 years experience in Rust" under the job requirements.
I think i addressed this in my edit. We are not doing this.
I think i addressed this in my edit. We are not doing this.
You should hire people who know a statically typed language and prepared to learn Rust.
I learned Rust (and C++!) at my current job, with Java being the only statically typed language i knew before that.
Unless you have reason to believe that a significant fraction of otherwise smart and capable static-language programmers will just never be able to learn Rust. I have no idea if that is true or not, and it would be interesting if it was.
I learned Rust (and C++!) at my current job, with Java being the only statically typed language i knew before that.
Unless you have reason to believe that a significant fraction of otherwise smart and capable static-language programmers will just never be able to learn Rust. I have no idea if that is true or not, and it would be interesting if it was.
> You should hire people who know a statically typed language and prepared to learn Rust.
I believe i said exactly this. Specifically i said:
> We're hiring devs who want to use Rust.
Which seems clear to me. My edit also addresses new Rust devs. Our requirement is that you want to work in Rust. Which shouldn't be shocking or controversial.
I believe i said exactly this. Specifically i said:
> We're hiring devs who want to use Rust.
Which seems clear to me. My edit also addresses new Rust devs. Our requirement is that you want to work in Rust. Which shouldn't be shocking or controversial.
What you said was (my emphasis):
> My shop uses Rust, and all our hires are aimed at Rust, and it's still not easy - there's not a ton of people who know Rust.
Which rather implies that you are trying to hire people who already know Rust. You then asked rhetorically:
> So we should hire to bring on people who want to work in PHP, and then force them to use Rust?
Suggesting that you saw this as the only alternative to hiring people who already know Rust. I was pointing out a third possibility which i thought you had omitted.
So i wouldn't agree that this was exactly what you said. But, of course, i am very happy to hear that this is what you are doing!
> My shop uses Rust, and all our hires are aimed at Rust, and it's still not easy - there's not a ton of people who know Rust.
Which rather implies that you are trying to hire people who already know Rust. You then asked rhetorically:
> So we should hire to bring on people who want to work in PHP, and then force them to use Rust?
Suggesting that you saw this as the only alternative to hiring people who already know Rust. I was pointing out a third possibility which i thought you had omitted.
So i wouldn't agree that this was exactly what you said. But, of course, i am very happy to hear that this is what you are doing!
[deleted]
[deleted]
Not true. Rust is significantly different from mainstream languages and has a greater learning curve due to the borrowing system.
It's not that hard to learn nor is it significantly different. The borrow checking rules are very simple and something that even novice C/C++ programmers follow, implicitly or otherwise.
The "hard" parts of Rust are the usage of lifetimes in generic heavy code (especially combined with function traits in order to be generic over closures), object pinning, and soundly operating in unsafe. Those are advanced topics to be sure, but they are not something you would expose a newbie to in the early days of onboarding.
The "hard" parts of Rust are the usage of lifetimes in generic heavy code (especially combined with function traits in order to be generic over closures), object pinning, and soundly operating in unsafe. Those are advanced topics to be sure, but they are not something you would expose a newbie to in the early days of onboarding.
This is like asking if you have to learn German to find work. Obviously you should be able to find work in any major language, but it may increase your opportunities (if you want to work in Germany.)
If you are in a field where everything is being rewritten in Rust, then it may be a good idea to spend some time on it. It is not the case of every field though.
Basically, Rust seems like a good replacement for most C++ applications. It offers memory and thread safety guarantees with no or minimal overhead and a speed comparable to C++.
I am currently working on two projects: one in python, one in Rust. I am a proficient C/C++ dev but I think I will ditch C++ in the near future. I am not sure it makes sense to replace C with Rust unless safety is required.
I don't see rust replacing python. Rust is painful to write, it is longer than C++ and python is much more productive when you can afford the overhead.
Basically, Rust seems like a good replacement for most C++ applications. It offers memory and thread safety guarantees with no or minimal overhead and a speed comparable to C++.
I am currently working on two projects: one in python, one in Rust. I am a proficient C/C++ dev but I think I will ditch C++ in the near future. I am not sure it makes sense to replace C with Rust unless safety is required.
I don't see rust replacing python. Rust is painful to write, it is longer than C++ and python is much more productive when you can afford the overhead.
no.
I would say it depends. Rust aims to solve perennial issues in software development by bringing as many issues “forward” in the development cycle. The way I think about the tradeoffs personally is that Rust is more "durable" than other languages. Its more rigorous type system and compile-time checks pushes more of your failure case discovery early into the development cycle while you're still getting it to compile, as opposed to runtime testing and debugging. There's less followup patching and bugs to discover because Rust usually makes you handle them up-front - particularly if you embrace the type system.
That's because you are on HN.
No, it's competition for C and c++. Lots of programmers don't know C.
Fwiw it can compete in a lot of areas to a lot of languages. It doesn't represent a need to replace, say NodeJS or Python with Rust, because those languages don't typically have safety issues. However Rust offers low-level benefits with many high-level abstractions. It has lower level features, like generics, so the toolbag is definitely big - but that doesn't mean you always have to use the huge toolbag.
I switched from Go because i wanted more language features. Rust isn't a competitor to Go imo, but indirectly it was for me. I never use C, and while i could use C++, i ultimately wanted a good dev UX. I chose Rust for my developer experience, not because it was a "better C/C++", of which i don't need.
I switched from Go because i wanted more language features. Rust isn't a competitor to Go imo, but indirectly it was for me. I never use C, and while i could use C++, i ultimately wanted a good dev UX. I chose Rust for my developer experience, not because it was a "better C/C++", of which i don't need.
I've heard this opinion a lot, so I'm curious about it. What makes you prefer Rust to Go? (edit: It's not just about Rust vs Go but Rust vs everything else, mostly GC'd languages when you can afford the performance hit). My intuition would be the type system, as Rust is currently the most popular ML-derivative. The compiler and rust-analyzer are also very nice to use.
For me it was things that aided user(dev) experience, and that was primarily things like iterators, enums, and functional patterns like maps (in the robust stdlib), good crate ecosystem. That made a huge DX improvement for me because it was just so applicable in so many scenarios. And to top it all off, i got the DX of things like Iterators with usually zero usability hit - Iterators themselves are fairly complex, at least in the generic param context, but Rust encapsulates that complexity so well that you rarely see it. You just Iterate and gloss over the fact that it's actually really complex.
We share the same experience then! Right now I'm investing some time into OCaml to see if it could be the "GC'd Rust" that I'm looking for, but I'm having a harder time starting out than with Rust.
Curious, why do you want a GC'd Rust? I imagine there's something about Rust that you feel would be improved with a GC?
I like not having to think about lifetimes and ownership when I'm building a tree for example, and for most of what I do I can afford the performance hit.
Is there a reason you'd not just throw RC-like solutions on it? Ie the GC is basically going to employ a handful of techniques with overhead like RC, memory Arenas, etc - which you could also use in Rust.
So i imagine you know this, is it the syntax you're trying to avoid? Ie wrapping a lot of things in RC's is annoying?
So i imagine you know this, is it the syntax you're trying to avoid? Ie wrapping a lot of things in RC's is annoying?
A few reasons. Like you said, syntax, wrapping and unwrapping is annoying. Also, RC doesn't cover cases with cyclic references. I think the difference is that for me GC is the default. For me, you need a good reason to not use a GC. Moderns GCs are very, very good and like I said I'd need a good reason to not use it. That's personal though, and I understand that not everyone agrees.
Yea, i can see that. As much as i dislike Go these days, their GC is impressive as hell. I can imagine future GC's will learn a lot from Go.
Has it improved? Last I heard Java’s tunable GCs still have much better throughput, while Go allows stack allocation more often.
(Yes, GC tuning is painful, but better than rewriting code hoping you might end up with the same behavior.)
(Yes, GC tuning is painful, but better than rewriting code hoping you might end up with the same behavior.)
What do you mean by "impressive as hell"? From my (limited) understanding Go's GC is average.
I don't know this field, perhaps my bar is low because of Python lol, but Go's GC has very short GC pauses. So short that it makes non-GC'd usecases less attractive imo.
My big issue with Go's GC, or GC's in general, is consistency. Go's GC can still be variable in pause time iirc. But it's been ~3 years since i've worked in it - so maybe my memory is wrong :)
My big issue with Go's GC, or GC's in general, is consistency. Go's GC can still be variable in pause time iirc. But it's been ~3 years since i've worked in it - so maybe my memory is wrong :)
Is my code I/O bound? Does it have no/easy SLA? Does it fall well within the send payload, transform payload, send payload to another service or DB flow ... and provided it's along these lines not running into the zillions of iterations per second GO is ideal ... there's been lots of whining about GO not have generics. As we use a lot of JSON I don't care plus it's coming anyway. Now if we get into serious SLA or latency issues, I'll move from GO into RUST. Either way we avoid C/C++. Gotta like that.
Doesnt matter what you pick in an ever changing unpredictable world overflowing with software. All that matters is how many hours you put in and how close you are to areas where there is a high density of software development going on.
Far from everything is being rewritten in Rust. It definitely shows up on HN quite a bit, along with other places. But I think that’s just growing traction.
It seems to have a bright future, but for the time being isn’t established enough to be worth learning for sake of industry relevance.
If you simply like Rust, go ahead and invest time into learning it. There are companies looking for developers.
It’s just not “the standard” at the time being.
It seems to have a bright future, but for the time being isn’t established enough to be worth learning for sake of industry relevance.
If you simply like Rust, go ahead and invest time into learning it. There are companies looking for developers.
It’s just not “the standard” at the time being.
[deleted]
We probably read very little about Java and yet it runs the world.
What we like to read and write about may not be very well correlated with reality.
Rust is a very niche language, gaining attention, and a serious contender to be an important language but it's probably not going to take over any space and even if it does, it's going to take a long while.
You definitely don't need to learn Rust.
It's a neat language though and it's worth tooling around in for a bit, at very least to get a feel for the 'borrow checker'.
What we like to read and write about may not be very well correlated with reality.
Rust is a very niche language, gaining attention, and a serious contender to be an important language but it's probably not going to take over any space and even if it does, it's going to take a long while.
You definitely don't need to learn Rust.
It's a neat language though and it's worth tooling around in for a bit, at very least to get a feel for the 'borrow checker'.