Rust Enters 'Top 20' Popularity Rankings For the First Time (zdnet.com) 107
Programming language Rust has entered the top 20 of the Tiobe popularity index for the first time, but it's still five spots behind systems programming rival Go. ZDNet reports: There's growing interest in the use of memory-safe Rust for systems programming to build major platforms, in particular at Microsoft, which is exploring it for Windows and Azure with the goal of wiping out memory bugs in code written in C and C++. Amazon Web Services is also using Rust for performance-sensitive components in Lambda, EC2, and S3. Rust has seen its ranking rise considerably on Tiobe, from 38 last year to 20 today. Tiobe's index is based on searches for a language on major search engines, so it doesn't mean more people are using Rust, but it shows that more developers are searching for information about the language.
Rust was voted for the fifth year straight the most loved programming language by developers in Stack Overflow's 2020 survey. This year, 86% of developers said they are keen to use Rust, but just 5% actually use it for programming. On the other hand, it could become more widely used thanks to Microsoft's public preview of its Rust library for the Windows Runtime (WinRT), which makes it easier for developers to write Windows, cross-platform apps and drivers in Rust.
Rust was voted for the fifth year straight the most loved programming language by developers in Stack Overflow's 2020 survey. This year, 86% of developers said they are keen to use Rust, but just 5% actually use it for programming. On the other hand, it could become more widely used thanks to Microsoft's public preview of its Rust library for the Windows Runtime (WinRT), which makes it easier for developers to write Windows, cross-platform apps and drivers in Rust.
It's not already #1?? (Score:5, Funny)
From all the posts here about Rust I assumed it was already in the top two languages and whatever I was using was basically Cobol.
Re: It's not already #1?? (Score:1)
Finally! (Score:3)
All those 'sponsored stories' on slashdot finally paid off!
Most loved, but unused (Score:4, Insightful)
The stats appear to show that there are more people who love Rust than people who use it.
This looks like those politicians who get more votes than there are eligible voters.
Once Again (Score:4, Insightful)
Re: (Score:1)
Re: (Score:2)
I'm an iOS developer and purely by platform force, Swift is pretty high up. It's ridiculous because you're forced to use the language, there's nothing else.
Re: (Score:2)
Apart from Objective-C, C, C++, Javascript, C#, any language that can be linked with Objective-C (which is the same as saying any language that can be linked with C).
Admittedly, Swift is better than all those option, particularly for developing iOS applications.
Parallels (Score:3)
Programming languages always have had parallels to religions. The less one knows the more one believes and the more believers a religion has got the more superior it is viewed.
The media attention Rust gets, while behind way behind Ruby, Go and PHP and even Perl, reminds me of Scienetology.
Re:Parallels (Score:4, Insightful)
Pretty much this. All those people believing that finally this magic tool will make the code they write not suck. Of course, that does never work. In reality, religion wants your money and time and gives you really nothing real in return. Religions usually do make a credible attempt at faking some benefits though. You know, like any good con. Rust is getting better at that too (faking benefits), so I guess that explains why the managed to get more gullible idiots to cheer for them.
Re: (Score:2)
> All those people believing that finally this magic tool will make the code they write not suck
Or people have tried it carefully, over a while, read the manual, and used it in practice and find that it is pleasant to use and works nicely.
This has been my experience. The language is nice, if occasionally baroque, the tools are well-written and good to use, and the community is kindly, patient, well informed and helpful.
From the amount that you post about Rust, I would guess that you have either been forc
Re: (Score:2)
You know, no. That is just your fantasy of what is happening. The nice ad Hominem at the end makes that even clearer.
Re: (Score:2)
You know, your post was just a diatribe pointing out that any one who does not agree with you, is just part of a religion and a crappy coder, so I am completely fine with ad hominem attacks. Oh, and it's also fine to dismiss by personal experience, as well as that of other people I know who started to use Rust after trying it and found that it was okay.
So I am genuinely curious about you. Where does your dislike of this piece of technology come from? Have you used it? Did it not work for you?
Re: (Score:2)
Well, if you read _that_ from my posting, any answer is just a waste of time.
Re: (Score:2)
A shame, I am curious where your animosity comes from. But I can live with out finding out.
Re: (Score:2)
Pretty much this. All those people believing that finally this magic tool will make the code they write not suck.
No, I'd say it's more akin to a seatbelt. It doesn't stop you being a bad driver but may save you if you are, but also save you even if you are a good one from your momentary lapse of concentration or someone else's.
Re: (Score:3)
Re: (Score:1)
Go back to your PHP then. You're clearly not up for newfangled things.
Do you show the same attitude towards Jews, Christians or Muslims, too?
Re: Parallels (Score:1)
Re: (Score:2)
True, but this is only what you believe it's about! To kids do you tell that God sits up in Heaven, that there is a Santa Claus, an Easter Bunny and that storks deliver babies. Funny you haven't figured this out yet and are still in disbelief of there no God being up above your head.
Go is a systems programming language? (Score:3)
Who knew?
Why my team switched to Rust (Score:5, Insightful)
Slashdot comments about Rust are usually ill-informed about the technical merits of Rust, and they fall back to cultural observations given their lack of technical understanding. So I'll add some technical observations.
I'm a professional language designer. I added the "async-await" keywords to C# back in 2010 which has subsequently been adopted by many languages - most recently, C++ and Rust. I've always had a passion for concurrency, and how to write concurrent-safe programs, and how concurrency-safety could be achievable by rank-and-file developers rather than being solely the domain of experts. Async-await achieved that in most languages by using a single thread and interleaving only at well-defined "await" points, so you could continue to use your conventional data-structures safe in the knowledge that you only had to enforce invariants at those await points.
Rust removes much of that need. Rust's ownership system is a beautiful way to ensure that there won't be concurrent races to access shared memory. I've seen many language researchers attempt to pull off ownership in the type system in various ways, and Rust's is the most usable. It's exciting that it still lets you gain this power even while still using threads.
I don't know how many of you read post-mortems by game developers at Gamasutra. The successful post-mortems inevitably start "What went well was that we started with an object management foundation for lifetimes, allocations+deallocations etc. and built the game on top of that". Rust's combination of ownership and lifetime in its typesystem basically does that, and forces everyone into successful patterns. Rust's ownership and lifetime are more expressive than other RAII patterns.
In my current job, my team of ~20 engineers maintains a language (parser, compiler, typechecker). About half of us have been working on a Rust port over the past couple of years, and we're half way there. Implementing a language at scale involves a load of systems work (you have to fetch stuff off disk, manage threads, evict memory, network services for the things that are too slow for the compiler to do locally) as well as good old-fashioned computer science stuff (parsers, constraints-solvers). We've found Rust tooling to be kind of poor, but it's delivered useful performance wins. Those wins would have been theoretically possible for us to achieve in C or C++, and might have made sense if we were targeting a fixed language that would be stable over 5+ years. But our particular language evolves much quicker than that, and our business needs for scalability, so we have to be more nimble than would be safe in C/C++.
Separately, just on a personal note, I've been coding since age 7 back in 1981, in a load of different languages. I was suspended from the computer room for a year for writing hacks. I designed and built a toy CPU from logic gates. My summer job in college was reverse-engineering software and file formats. I've loved being a hacker. I've loved doing high-level stuff and low-level stuff. When you spend your time writing Java business logic or full-stack web development it's easy to get sucked into the boring side of coding. When I learned Rust a couple of years ago it brought flooding back the enthusiasm and delight that sucked me into the discipline into the first place. It's exciting to harness its power to write high-level code with a low-level performance mindset.
Re: (Score:3, Funny)
Re: (Score:3)
I'm a professional wrestler. I actually invented the DDT.
A come on, dude, thanks for killing all those eagles, what's wrong with you.
Sounds nice but... (Score:1)
What you say sounds nice and from reading the language looks nice. But I'm not sure it's that much of a win over other modern languages that it's worth the pain of bad/primitive tooling...
I admire your desire for good patterns in concurrent programming though!
Re: (Score:2)
Maybe not yet, but with enough momentum tooling will eventually improve.
I remember writing my first Java toy programs in a text editor without syntax highlighting and compiling it using make - because in the beginning that's what everyone had to do.
What I really want from Rust. (Score:3)
I keep losing my jobs because I wind up killing my co-workers every time I have to think about if my C variable needs to be passed with a * or an & and then which return to use. And then wonder if *obj->foo() is the same as *(obj->foo). I go mental when I can't figure out how to return a local object on a return statement-- is it safe to return by Value? I end up feeling that C++ is not a language but a disease that wen need to eradicate even if it means we have to nuke the earth from orbit aft
Re: (Score:3)
I keep losing my jobs because I wind up killing my co-workers every time I have to think about if my C variable needs to be passed with a * or an &
I don't believe you program C, especially being paid to program C, if you don't the know the difference between the dereference and pointer operators.
missing the point (Score:3)
Why would you ever design or want to use a language where you have to know that? it's a bad design right out of the gate.
Re: (Score:2)
Re: (Score:2)
that's the compilers job.
Re: (Score:2)
And then wonder if *obj->foo() is the same as *(obj->foo)
Those are never the same. Problem solved, never wonder again.
Re: (Score:2)
I keep losing my jobs because I wind up killing my co-workers every time I have to think about if my C variable needs to be passed with a * or an & and then which return to use. And then wonder if *obj->foo() is the same as *(obj->foo).
You aren't programming in C, I don't think you ever did.
missing point (Score:2)
Why would you ever design or want to use a language where you have to know that?
Re: (Score:2)
If you have to ask if you can return an object by value or not, then I honestly don't envy you.
One always tries not to return anything at all, because the less one passes around the less gets copied, the less dependencies it creates and the faster the code gets. Only when one knows that it has to be and cannot be avoid it does one begin to look at the size of it, where it resides and tries to minimise it, because of the impact it creates. Once you've adopted this way of thinking will it will no longer be a
Re: (Score:2)
Re: (Score:2)
You don't think wrong, but you've stopped with it half way through. The point isn't to give up on dividing problems into manageable pieces, but to know where it makes sense to do so and where it doesn't. You'll already know that. And when you find a 3rd party library, which is badly written then improve it (see open source), or find a better one, write one yourself or accept it as is and move on, whatever you want to do.
My response then wasn't to you, but to the one above who couldn't tell when to use what.
Re: (Score:2)
[Rust has] delivered useful performance wins. Those wins would have been theoretically possible for us to achieve in C or C++, and might have made sense if we were targeting a fixed language that would be stable over 5+ years. But our particular language evolves much quicker than that, and our business needs for scalability, so we have to be more nimble than would be safe in C/C++.
This paragraph makes no sense to me. (Thanks for async/await, though)
Re: (Score:2)
This paragraph makes no sense to me.
Sorry, I wrote it dreadfully. Let me rephrase. The question I ask myself is: if gcc is written in C and is fine, and clang is written in C++ and is fine, then are C/C++ fine language for writing compilers?
Problem is, I don't know much about those two. I've heard that gcc isn't actually fine, that it's hard to add features to it.
I do have experience with the C# compiler. It used to be written in C++. We also had a very hard time adding features to it. That might be an artifact of it having an old crufty code
Re: (Score:2)
if gcc is written in C and is fine...
As of version 4.8 (March 22, 2013), GCC is implemented in C++ https://gcc.gnu.org/gcc-4.8/ch... [gnu.org].
Elaborate Please (Score:4, Insightful)
Most of the propaganda about Rust just woffles about how it can do stuff that C++ RAII can easily do. But how can it handle the hard stuff?
How can it handle "ownership" in pointer structures like trees? A short sharp explanation would be welcome.
The only real solution to safe concurrency is ACID, where you have a central database-like system and copy in and copy out and have transactions. Rust does not do that.
I am also curious why you would use Rust instead of C# seeing you look like you are from Microsoft. C# is perfect for writing a Compiler in. GC is fine for a compiler.
Re: (Score:2)
There are several different approaches that do not require to use Rust 'unsafe' features, for example a concept of 'arena' can be used with a common lifetime of all references which is the same as of the arena where they live (lifetimes cannot be explained in one short and sharp sentence), or using indirection (storing id's instead of pointers), or using reference counters (there are two: Rc an
Re: (Score:1)
Acid does actually guarantee safety (Score:2)
If you store no external state between transactions, obviously. The term is "Serializeable", mathematical proofs that any operations in multiple transactions can be reordered so they have the same result if each transaction is carried out one after the other. It is actually very powerful. Can also detect deadlocks.
Re: (Score:2)
Re: (Score:1)
> There are several different approaches that do not require to use Rust 'unsafe' features, for example a concept of 'arena' can be used with a common lifetime of all
> references which is the same as of the arena where they live (lifetimes cannot be explained in one short and sharp sentence), or using indirection (storing id's >
That pretty much sounds like "you cannot".
So the situation in Rust sounds awfully similar to what we do in C++ for decades: You have low-level stuff hidden in templates ("un
Re: (Score:2)
RAII is not a silver bullet, it solves one particular class or problem but doesn't solve the others. Example:
std::vector v = {1, 2, 3}; // oops
int* p = &v[0];
v.push_back(4);
printf("%d\n", *p);
This is not possible in Rust due to compiler-enforced ownership and lifetimes:
let mut v = vec![1, 2, 3]; // compiler error: cannot borrow `v` as mutable because it is also borrowed as immutable
let p = &v[0];
v.push(4);
println!("{}", p);
Re: Elaborate Please (Score:1)
Re: (Score:3)
Re: (Score:2)
OK, so I have a compiler warning or simply ban the "&" operator. Also prevent references leaking scope. And no raw pointers.
I.e. pure RAII.
I think you then pretty much have Rust.
I would very much like to see those compiler warnings on a C++. But I suppose it is beyond the psychology of a C programmer to not take the address of local variables etc. Still feels a new language is over kill.
Re:Elaborate Please (Score:4, Informative)
I am also curious why you would use Rust instead of C# seeing you look like you are from Microsoft. C# is perfect for writing a Compiler in. GC is fine for a compiler.
Sure GC is fine for some compilers, particularly if the programs you wish to compile aren't that big.
When we ported the C# compiler away from C++ (where it used arena allocation) to C#, it worked okay for smaller programs, but it came with perf+space headaches that were down entirely to memory. It took a couple of years to get on top of those, and a whole bunch of new data-structures and algorithms such as red-green-trees.
In my current job we work on the compiler for Hacklang. It's written in ocaml which uses GC. It struggles at scale - gives hiccups in IDE services due to collection, has unexplained spikes and slowdowns in the bulk checker, and isn't scaling to the size we need. This is the one that we're porting to Rust to keep control over memory size.
Heck, I've seen C++ files with heavy use of templates which take 1gb+ to compile. Of course clang doesn't use GC, but it's indicative of the kind of memory scale you have to be aware of (and the number of bytes you have to GC after compiling a file). We have seen the biggest wins come by adopting arena allocation.
Most of the propaganda about Rust just woffles about how it can do stuff that C++ RAII can easily do. But how can it handle the hard stuff? How can it handle "ownership" in pointer structures like trees? A short sharp explanation would be welcome.
I think a tree is straightforward. Each node in the tree owns its left and right branches. When you unset a branch, that implicitly releases the memory. Nothing surprising. The language stops you making an alias to a branch. Or you'd use reference-counting. Nothing special here and nothing different from what RAII in other languages would do.
A DAG is more complicated because, who owns the sub-branches? Many folks do it just with reference-counting as you normally would. But if you don't want the perf hit of reference counting, particularly not thread-safe reference counting, we're doing it with arenas and using lifetimes to ensure there are no dangling pointers: Tree {left: Option&; right: Option&;}. That means that the tree only has a reference (not ownership) of its left and right branches, but also means that the tree will certainly not outlive its left and right branches.
The only real solution to safe concurrency is ACID, where you have a central database-like system and copy in and copy out and have transactions.
That's not true. If you have a reference which can only be read from, then it's safe for multiple threads to read from that pointer. Rust's typesystem lets you enforce that either (1) all aliases for a reference are read-only, or (2) there's only a single alias and it allows writes. It enforces this transitively for complex datastructures. This approach to concurrency is unrelated to transactions so it's not meaningful to say whether it's ACID.
Re: (Score:2)
I think a tree is straightforward. Each node in the tree owns its left and right branches.
...until you start using persistent data structures. Which is probably why Ocaml has GC in the first place.
Arenas would be cool (Score:2)
Of course Generational Garbage Collection essentially provides automated arenas, using clever techniques way beyond C++ or Rust. But it still requires a certain amount of pointer crawling during Mark (only of pointers that recently changed).
Does Rust provide safe arenas? The trick is to know there are no dangling pointers into it when you free it up, and without reference counting or other expensive operations. Every time you set a pointer you would need to know that it is pointing to something in the sa
Re:Why my team switched to Rust (Score:4, Interesting)
When I learned Rust a couple of years ago it brought flooding back the enthusiasm and delight that sucked me into the discipline into the first place. It's exciting to harness its power to write high-level code with a low-level performance mindset.
This sums up my own feelings very well.
I'm not much into coding anymore these days outside hobby activities, but in my heart I'm still a C person for the same reasons that some people have old junk cars they tinker with - control. No computer code trying to outsmart me and ending up things I didn't tell it to do. Yes, I know about compiler optimizations and the havoc they can wreck (especially on crypto, for example), but short of writing machine language directly, C is as close as you can get.
Rust made me feel in charge again. It had that feel of a language that puts you in the driver seat and doesn't try to hold your hands all the way. It forces you where its needed, and gives you free reign afterwards. You don't feel like you need to read twenty books on styles and patterns before you can do something, and the code is readable (unlike most JS stuff that looks like it wants to compete with Perl for title of write-only-language).
I've also reached that age where I'm done tinkering with the machine itself. I moved from Linux to MacOS because I want to use my computer for something instead of maintaining it. Linux was fun and still runs my servers, but on my desktop I don't want to wonder whether there's a package or should I write my own kernel extension for this (been there, done that) - I want the stuff to simply work.
Rust does that on a programming level. It simply works. You don't need to set up your own system for that or system for this or hope that the built-in garbage collection works properly but let's Google on how to configure it so it does.
I am by far not as deep into programming languages and compilers as you are, but I got the same general "vibe" from Rust and I love it for that even though I'm not currently writing anything in it (but the simulation I wrote last year was a blast, and the sheer performance I got with just simple optimizations was amazing).
Rust vs C++ RAII (Score:2)
AFAIK Rust does not give you much beyond writing C++ in a modern (post 2000) style.
A few compiler warnings about pointer arithmetic and leaking references would make C++ about the same. No compiler actually gives them but a bit of coding guidelines gets you there.
But why, in 2000, let alone 2020, would I want to use any programming language that does not have proper generational garbage collection?
Re: (Score:2)
Re: (Score:2)
Actually no. Not if you can cast a pointer to an int. See below.
Re: (Score:2)
Re:Rust vs C++ RAII (Score:5, Insightful)
But why, in 2000, let alone 2020, would I want to use any programming language that does not have proper generational garbage collection?
Simple: In many applications garbage collection is a problem, not a solution. As soon as you have any type of real-time parts, GC gives you jitter and delays. As soon as you put massive load on the memory management system, GC is inferior, often massively inferior, to custom solutions. Yet the presence of GC often makes custom solutions hard to create and causes problems with them.
Re: (Score:2)
Re: (Score:2)
It might. But it doesn't.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
... In many applications garbage collection is a problem, not a solution. ...
This is more true than many probably realise and sadly has it always been this way. There is a reason why the term "garbage" collection was invented, because it reflects the convenience of developers not wanting to take control, to care for what happens after they've used the memory, but simply to throw away and forget and live happily ever after in a comfort zone.
I suppose if we could get developers to think in terms of "renewable", "recyclable" and "convertible" memory opposed to just "new", "delete", "d
Re: (Score:2)
Indeed. It is the same with many other things: Hide the complexity behind an abstraction layer, like an automation mechanism or a library and in some cases (universally simpler cases), you get a reduction in complexity of use. But in some cases (and these tend to be the already harder ones), you not only get the original complexity, you now have the complexity of the of the abstraction in addition to deal with.
It strikes me as a really bad idea to make simple cases simpler at the cost of harder cases gettin
Re:Rust vs C++ RAII (Score:5, Insightful)
Re: (Score:2)
So, how does Rust handle linked pointer structures like trees and linked lists? Reference Counting? Which is a (poor) garbage collection technique.
Re: (Score:1)
Re: (Score:2)
There are a number of solutions to circular data structures.
In no particular order, one is not to use them. Many data structures are accidentally self referential and you often do not need them. Next would be to use an "arena". So, you have a potentially circular graph. You just keep all the objects in the graph life till you have finished with the graph, then you ditch all the objects at once. This is what happens in most GC systems with graphs anyway I suspect. Finally, you replace references with somethi
Re: (Score:2)
Re: (Score:2)
Rust does allow pointers to be cast to integers and vice versa, so the possibility to create a garbage collector that works reliably with arbitrary Rust applications is, alas, not possible. I'm kinda horrified actually, Rust appears to be a programmer friendly C++, not an attempt to solve an actual problem and deal with the shitloads of insecure code out there.
C programmers do understand that. Let me elaborate:
Modern (post 1980s) garbage collectors actually move things in memory. That is what makes them much more efficient than reference counting. But you cannot do that if anything assumes that things never move. E.g. by casting to an integer.
And certainly there is 1% of programs for which Garbage Collection is not suitable. But I am interested in the other 99%. Like a web browser.
Re: (Score:2)
"Modern (post 1980s) garbage collectors actually move things in memory. That is what makes them much more efficient than reference counting. But you cannot do that if anything assumes that things never move. E.g. by casting to an integer."
But this is a well-trodden path in Rust, and there is a principled way of dealing with it. You can access arbitrary memory in Rust, including accessing memory by casting a random integer, but to do so requires use of `unsafe` code. So, to implement a Gc, you would have som
Re: (Score:2)
I think if Rust GC was implemented it would only work over safe Rust -- casting pointers to and from integers is possible, but you can't dereference the pointers in safe rust.
I think that the Rust attitude is that abstractions should be zero-cost. If you do not need GC to recover memory why have it? And if you do need GC to recover memory, and hence pay the cost, you should use it explicitly. It is definitely a gamble, I think, it looks like many people have been using Rust to build their software without G
Re: (Score:2)
If you do not need GC to recover memory why have it?
For the cases where you *do* need it or something equivalent, like Rust's Arc?
And if you do need GC to recover memory, and hence pay the cost, you should use it explicitly.
And you already do that with Arc, don't you? I can definitely imagine that in the future, it might be possible to replace (explicit) usages of Arc in Rust applications with (equally explicit) usages of a functionally equivalent GC implementation, possibly even without having to change any application code, and to save the memory used for reference count members and the bandwidth of the atomic operations during execution for someth
Re: (Score:2)
For the cases where you *do* need it or something equivalent, like Rust's Arc?
Indeed so, the point is to add this memory management as a library rather than a language feature.
And you already do that with Arc, don't you? I can definitely imagine that in the future, it might be possible to replace (explicit) usages of Arc in Rust applications with (equally explicit) usages of a functionally equivalent GC implementation, possibly even without having to change any application code, and to save the memory used for reference count members and the bandwidth of the atomic operations during execution for something more useful.
Yes, that are already implementations of this (https://github.com/Manishearth/rust-gc for example). It would be interesting to see what impact that would make on Rust performance. There are certainly applications where accurate runtime calculation of memory recovery might be faster. I think that the point remains, thought, that while this might be useful, that Rust can be used entirely successfully without GC,
Re: (Score:2)
Re: (Score:2)
But why, in 2000, let alone 2020, would I want to use any programming language that does not have proper generational garbage collection?
Because GC is a hack, a workaround. It essentially boils down to: "I can't manage my stuff properly, so I'll just hire someone to come around from time to time, ask me if I'm still using something, and throw it out if the answer is no."
That approach is trivially obviously inferior to putting things properly on your shelves in the first place.
Re: (Score:2)
Re: (Score:2)
Except *nobody* can "manage one's stuff properly" in the extreme cases.
There's a difference between "nobody can" and "so far, nobody has figured out how".
I do agree that GC is a step forward over manual malloc() and free().
I also believe that Rust's approach is a step forward over GC.
Re: (Score:2)
There's a difference between "nobody can" and "so far, nobody has figured out how".
All right, should have phrased it like the latter, which is what I meant. Thanks for that.
I also believe that Rust's approach is a step forward over GC.
What Rust is doing is orthogonal to what GC is solving. So there's literally no reason why you couldn't have both and reap the benefits of both.
Re: (Score:2)
What Rust is doing is orthogonal to what GC is solving. So there's literally no reason why you couldn't have both and reap the benefits of both.
Where do you see the necessity for GC in Rust? Because if there isn't (as the Rust devs claim), then it isn't orthogonal at all.
Re: (Score:2)
as the Rust devs claim
Then why did they include Arc if they claim this? They let a library handle something that Rust already solves?
Re: (Score:2)
Then why did they include Arc if they claim this?
That's a good question. I have no idea, I've never had to use it.
Re: (Score:1)
If you can prove that nobody else is going to be modifying the data, then you can convince the compiler to let you mutate it while shared.
For example: Arc<Mutex<String>>, where the mutex acts as proof that nobody else will be modifying the String.
Re: (Score:2)
Re: (Score:1)
Popularity, Schmopularity (Score:2)
So maybe this index ought to be called a ``Curiosity Index'' instead of ``Popularity Index''.
Rust has terrible power consumption (Score:4, Funny)
I can never get my devices into low power mode because Rust never sleeps. Hey Hey My My Perl Scripts will never die.
Re: (Score:2)
Hey Hey My My Perl Scripts will never die.
Unless they run in a Pono music player...:)
Re: (Score:2)
Let's see:
- tedious and boring
- strawman referencess to "inclusiveness"
- No technical content, or actually relevance to the post.
Yes, It's the traditional Rust first post!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
How is a popularity poll a sign of merit? Does that mean the best burgers are McDonald's, and the best pizza is Domino's, just because more people eat more of their food more than other burger/pizza places?
Seriously, Crunchberry, you failed miserably here at your feigned indignation.
Re: (Score:2)
How is a popularity poll a sign of merit? Does that mean the best burgers are McDonald's, and the best pizza is Domino's, just because more people eat more of their food more than other burger/pizza places?
Seriously, Crunchberry, you failed miserably here at your feigned indignation.
Define best. For some McDonald's may indeed be the best.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
hahaha,
No it filters out people writing the software that runs the world's computers and business, because they sure as hell ain't written in Rust.
Another fad language that will come and go...