You have to take all this with a mountain of salt. Boosterism is the norm in our space, sadly. If one devotes time to learning a technology it is personally advantageous if that technology takes off. Hence you get this kind of "My programming language and community are already wonderfully perfect and kick more goals than there are nets to kick into" stuff. And the worse, yet related utter rubbish we see all the time. "C is a virus", "Perl is line noise", "failure to use JVM style garbage collection is idiotic and unsafe". etc etc. You can swap out those languages and swap in any others you like. It's pervasive and that is a shame.
This is the same kind of thing even if less stomach turning than the negative crud. It's pretty crappy and doesn't really belong here any more than Oracle and IBM global services adverts do. It is not anything like objective and in any sensible assessment of Rust should be roundly ignored. Just like big consulting firm whitepaper "Are you enterprise ready!?!?!"
All the very best to Rust hackers, may you achieve your technical goals in both your design and implementations and have loads of fun on the way!
Yes, people who promote a language are biased. But so are people who resist that language: they tend to have existing investments in their favourite languages, and have inertia in moving to a new language. I personally haven't decided to learn Rust yet, but I still appreciate being kept up-to-date on the landscape of programming languages, and I want to know about the cool new languages as well as the solid old ones.
It's a list of facts. You don't need a "mountain of salt" to take a list of simple, easy to check facts.
> you get this kind of "My programming language and community are already wonderfully perfect and kick more goals than there are nets to kick into"
It doesn't say how wonderful Rust is, it says how many contributions it had, how many users on gitter, etc. You can interpret that like you want, but that's just your interpretation.
It's guerilla marketing where one person's fact is another's spin: the Amazon job requiring in-depth domain knowledge and leadership skills mentions rich Java or C++ experience as desirable while also requiring familiarity with Python or Rust.
The resulting fact is then "Amazon is hiring for developers with Rust experience.". If a candidate checks the other boxes they'd probably hire them if they knew VisualBasic... :)
Personally I don't like this forceful advertising stuff unless maaybe it's for a really good social cause which is otherwise ignored. e.g: privacy
How is it forceful? It's a link on a link board site. It said it was about Rust in the title. If you don't care about promotion of Rust, you should probably have not read the article.
This attitude pisses me off because advertising is a necessary task in all projects. It doesn't matter if it's commercial or completely free, volunteer-built open source software. You need to advertise the project to ensure enough people know about it to achieve a lasting, critical mass of users and developers. But this attitude establishes a norm of resentment towards project maintainers who are just trying to do well by their projects and their users. I think young people pick up on this and it makes them reluctant to promote their own projects.
It's what happens when people identify intellectual ability (or other positive attribute) with tool choice, and also wish to identify themselves as having that attribute.
For me, A totally cs newbee, the Rust team has established a great community.
I have learned a lot from the e-mentor(contribute to rust or rust lib directly with the guidelines from rust core developers).
Now I’m the founder of Rustacean group in my school.
Well, a fun fact: there is nothing funny about that list :). It should have been called "Some facts about Rust's growing popularity".
Now, my predicament: I love Rust's type system and tooling, but it's really hard to justify to myself the pain of writing correct Rust code (borrowing, lifetimes, etc.) when I know I can get almost the same effect by using a GC language + immutable messages.
And I don't need that last drop of performance either.
So if you just want a native language with a good type system and a growing ecosystem, where do you go? Still Rust or something else?
You're overlooking that Rusts "solution"(borrowing, livetimes, etc. ) is not only solving the same problem that garbage collection tries to solve. Garbage collection is "only" solving the "memory resource problem". Rusts solution is a more general solution to the "general resource problem" .. like file handles, sockets and of course memory and besides that gives you tools to never get bitten by data races. Nothing (besides memory) garbage collection is helping you with. You have to mitigate those problems still in garbage collected languages like Swift, Go, Java, Python (to name a few) and various other solutions to help with this (try with resource, with statement, immutable message passing etc.) Rust tries to give you one solution "to rule them all". Is this better, worse? Idk – nobody does, the Rust people are trying to figure this out :) Nothing is carved in stone. And if you're more productive in another language you should use it! But you can only know by figuring this out for yourself. Rust works well for me – that's no guarantee that you have the same experience. Rust is still hard to learn and one needs to question himself if the effort in learning pays out at the end – it has for me, i guess/hope ;)
>Rusts solution is a more general solution to the "general resource problem"
It's true. Ever since I got familiar with the ownership concept, I've taken to writing C# IDisposables with disposable member variables like this:
public MyObject(){
this.myResource = new DisposableResource();
this.ownsMyResource = true;
}
public MyObject(DisposableResource resourceToUseThatIDontOwn){
this.myResource = resourceToUseThatIDontOwn;
this.ownsMyResource = false;
}
public void Dispose(){
//not pictured: .NET's boilerplate dispose code
if(ownsMyResource) myResource.Dispose();
}
For the client I'm contracting with right now, mismanagement of disposable resources is the #1 issue in the codebase. 100k lines of code, and it's never clear who should be disposing connections. There are some objects with multiple constructors (like above) that have 'conditional' ownership. In Rust, it's impossible to have this problem, period...although the above C# construct simulates it, lol.
That's pretty cool - it never occurred to me that determining drops required anything other than static analysis. Nice that it doesn't affect the layout of the types, either...which I'm guessing is why they added:
>The drop flags are tracked on the stack and no longer stashed in types that implement drop.
I agree and I appreciate what they are trying to do.
But just as a counter-argument, look how a simple lock looks like in Rust [1]:
fn main() {
let counter = Arc::new(Mutex::new(0));
let mut handles = vec![];
for _ in 0..10 {
let counter = counter.clone();
let handle = thread::spawn(move || {
let mut num = counter.lock().unwrap();
*num += 1;
});
handles.push(handle);
}
//...
}
-----
edit: Just to clarify my point. The ownership model is a beautiful solution to the resource management problem. And as the parent pointed out, some concepts can be cleanly borrowed/reused in other languages.
But now, in Rust, in practice, you realize that this model requires a lot of boilerplate code just to make the borrow checker happy, even for simple things like using a lock: create Arc(Mutex(data)); clone the arc reference; move the new Arc reference to the new thread.
The issue really is lack of scoped threads forcing usage of reference counting to figure out when to drop a value. With crossbeam scoped threads implementation this looks much nicer.
extern crate crossbeam;
use std::sync::Mutex;
fn main() {
let counter = Mutex::new(0);
crossbeam::scope(|scope| for _ in 0..10 {
scope.spawn(|| *counter.lock().unwrap() += 1);
});
println!("{:?}", counter);
}
Four lines to declare a mutex, start 10 threads that all lock that mutex, increase value behind mutex, unlock mutex, and join all spawned threads. There is a lot going on here (unwrap is arguably a noise here however, but the rest is straight to the point).
Also, it's possible to use atomic ints here instead of mutex. Verbosity of mutex actually helps a bit, because locking is fairly expensive and it's better to avoid locking if possible.
You would still need to have lots of resource management problems to consider using Rust, i.e. it is useful to those high performance/embedded domains that still use C/C++. There are high level dynamic solutions even for things like data races these days (e.g. transacations) if you don’t need to juice every last bit of perf out.
... and, it will be eventually closed. Maybe. Definitely before the program quits. Not sure that it'll be closed before you run out of file handles, though.
Rust is not for everything, but for the situations where GC is unsuitable (e.g. you have real-time constraints), and a few others, benefits become obvious (and it's hard to look back once you are there).
Yes it can be a pain to write. But I prefer the pain of making the compiler happy than the pain of debugging a weird segfault.
> [...] but it's really hard to justify to myself the pain of writing correct Rust code (borrowing, lifetimes, etc.) when I know I can get almost the same effect by using a GC language + immutable messages.
> And I don't need that last drop of performance either.
You probably write more highlevel code? Rust is --as the name implies-- most suited for close-to-the-metal code. This is often where that "last drop of performance" counts.
> Rust is --as the name implies-- most suited for close-to-the-metal code.
There are a lot of projects that really could be written in a high-level language, but they were started when C was still preferable due to the immaturity of higher-level solutions. I think it is sad that people, looking at these aging and unaudited C codebases, are thinking about rewriting them in Rust, when rewriting them in e.g. Python might make better sense. Very little Free Software needs to be so close to the metal, and it was just a historical accident that we got so much written in C.
Most of the FOSS software originated with the UNIX culture, where C thrives and the original FSF Manifesto suggested using only C to increase portability between POSIX systems.
So the historical accident was UNIX/POSIX taking over the majority of OS architectures.
> I think it is sad that people, looking at these aging and unaudited C codebases, are thinking about rewriting them in Rust, when rewriting them in e.g. Python might make better sense.
I agree... apart from the Python bit. :) When deving software that is very big (LOC) or very widely distributed (FLOSS packages), then I prefer "well typed" languages that do not need a VM/interpreter.
But Rust is linker compatible with C and C++, meaning the typesafe rewrites can also be shoehorned into Python, just like its native extensions in C are...
My personal answer to that is OCaml. The only thing I miss there is good concurrency support. I can see how this might open a whole new can of worms. Would we still use locks, or some addition to the type system like Pony's reference capabilities?
I need that last drop of performance but only for a very small part of my code. For the rest, it's just painful to either have to implement iterators with tons of boilerplate ownership or declare things as sitting boxes on the heap. Both distract a lot from what I'm trying to do which is annoying.
I wish there was a higher level Rust sublanguage where heap allocation and GC was default, and you would use the "bare" Rust for the fast core of your program.
It's very easy to do the Java/C, C#/C, C#/Rust, Python/C dance, but there is always a massive impedance mismatch at the boundary, and there are always two different build systems and package managers etc involved.
I'd like to see a language that is both systems and high level at the same time, with trivial interop and a common build system + package manager.
This could e.g be a set of low level extensions added to C# (Span<T>, ref returns etc is getting there) or a high level wrapper language/subset for e.g. Rust.
There is always a best tool for the job, and most jobs might require two tools, so it would be great if those two tools were aware of each other and came in the same toolbox.
Totally agree. The thing with LuaJIT or more appropriately stock Lua is that the VM is small enough to include in your project directly. If Vec and String were exposed to Lua first class construct, we would be a long way there.
The two most mature, well-designed languages in the Rust world are Gluon [1] and Dyon [2]
I believe there is a _great_ opportunity for something like Terra [3] but woven into Rust. Perhaps with the same type of compiler plugin that enabled HolyJIT [4]
The grail is having both a GC and an ownership based gc-free lower level all in the same language. Start dynamic, harden to static and sprinkle in properties.
As a side note, I have been thinking about how to bolt ownership onto a dynamic language and then I learned about Snowflake [5]. I think it would be totally doable to bolt ownership onto Java using annotations and AoT subsets of a program, completely escaping the garbage collector. This would be like Terra++
To me, Swift feels very similar to Rust only a lot simpler. Arc is also (imho) a nicer solution than a GC (though people have different opinions on that). Even better, with future versions, some of the features of Rust (i.e. lifetimes) will also come to Swift in an opt-in way. It is still a young language but fun to code in.
Tooling is all right, not as good as the cross platform tooling for something like Java, but still pretty good, especially given how recently Swift has had any non-hobbyist presence on non-Mac platforms.
The core language "just works" pretty pleasantly on other *nixes, I don't know about windows.
You end up missing Apple-specific libraries a lot, though. There are some packages making progress on that problem, but a comprehensive replacement for e.g. audio or graphics surfaces is a ways off, I think, if only because of the fragmentation that exists in those spaces on other platforms. Of course, Swift has that problem only a little worse than any other language that ships without an OS.
It's really coming along now with Swift 4, but it is still (of course) behind the Apple platforms.
The "core language" pretty much works great on Ubuttnu, but there are still minor annoyances getting it installed, or building it, on Linux. Other Linux targets, also doable, but more annoying. Windows, I haven't really heard of people doing for real. Not sure that's even on anybody's radar.
What's really awesome is how far Swift has come with the core lib Foundation, which is a from-scratch clone of Apple's Objective-C and closed-source macOS/iOS Foundation library[1], written in Swift, in the open. It is not done, but huge swaths of it are now done[2], and that makes coding in Swift on Linux a lot more pleasant, since we don't typically want to waste time rolling our own regex support, Unicode string manipulations, basic geometry routines, HTTP networking, date formatting, etc. But Foundation is a huge, almost 30-year-old library that has evolved continuously and has shipped with every OS X/macOS/iOS release. An open-source Swift re-implementation of that sounded like "yeah right" bullshit/fantasy when they announced it but now it looks very real just a couple years later.
Tooling is different issue, though. Swift is a modern language with excellent support for auto-completion and in-editor hinting and help. People complain about it all the time, but Xcode is so much better than any IDE on Linux (or any other platform) for coding in Swift that I do most of my Swift-on-Linux work using a Mac, with Ubuttnu running in VMWare Fusion. If a basic editor will do, though, you have a lot of choices. For builds and package management, Swift Package Manager is now built into Swift, and works great. (It also has an option to automatically generate Xcode project files from Swift packages, which is hugely useful; my practice, and I think the prevailing or at least emerging convention, is to keep the package and source in git but treat the Xcode project as a throwaway item, not in version control, that can be generated whenever needed. So you don't need Xcode, but its easy to use for editing convenience when you want, assuming you have a Mac. But not all devs need to have Macs.)
I think you still have to like Swift a lot to choose it for your Linux project, but it is doable. I'd be surprised if Swift adoption on Linux didn't quintuple or sextuple by the end of 2018.
ARC is nicer than GC and more predictable but in terms of performance for stuff like audio raw graphics processing and so on you still want to use something more low level like Rust, C or C++.
One of the reasons iOS is more smooth than Android there's no "OK I'm going to GC a million objects right in the middle of your scroll" performance dip but it will release all objects more gradually through ARC at a slightly bigger total performance cost.
Ask C devs why they (still) think Swift is a PITA to work with compared to Objective-C. Luckily in most scenarios you can use Objective-C mixed with Swift to get the advantages of both scenarios.
> And I don't need that last drop of performance either.
If Nim could mature a bit it would be really nice.
There is OCaml but it is a bit goofy to work with if you prefer more imperative style coding.
There is Go but no generics.
> So if you just want a native language with a good type system and a growing ecosystem, where do you go? Still Rust or something else?
Nim[1] is a good alternative to Rust if you don't mind a GC, and I argue that even for use cases where a GC might be problematic it's still a good choice thanks to the Nim GC's soft real-time capabilities.
This one jumped out at me. I'd be curious how this compares to other languages. (I know nothing about rust besides that I see it on hn all the time, impressive list though!)
I think that once upon a time as c++ was relatively new, it got a faster adoption in the corporate world. There are still very few job offerings that mention rust. I hope that will get better at some point.
C++ was helped by the adoption of C compiler vendors.
So we got two compilers in the box.
Plus having almost copy-paste compatibility with C, meant we could enjoy higher productivity with a more safer language, and leave the other unsafer one on the drawer.
Of course, nowadays we are paying the price of the copy-paste compatibility that helped the language gaining adoption in first place.
I would look more carefully at this figure. As an example, over 20% of Nim devs use Nim at work as well[1], but of course the number of respondents is far smaller so it merits a closer look.
Jumped out at me too. The link 404s so there's no source for the claim. Plus, what does "use it" mean? They dabbled with it for a small, non-critical application, or they're using it as their primary language in a non-solo project?
It's a common marketing tool nowadays. Many popular vloggers and DJ's who have made a name for themselves through social media do it too. They also use other shibboleths to foster an 'in-group' vs 'out-group' feeling, like hand signals, or just specific phrases used for signing off, or referring to themselves or other groups. I guess it appeals to some fundamental desire to 'belong'.
Personally I think it's quite creepy and dystopian. Then again, is it worse than wearing t-shirts with the name of a software project on them outside of conferences about that specific software? That's kind of cringy/cultish too, when you look at it from the outside, but it doesn't feel that bad when large parts of your life revolve around that particular software.
That's a rather reductive approach to the current discussion, and has nothing to do with the original point. Once groups start being labeled it's no longer an opt in on the individual's level.
Check your hangups at the door man. I love being a gopher and a rustacean. I like being cute and having a cute name for myself and fellow community members. It's attitudes like this that created the massive gender divide in CS and it needs to end.
On the (very cold) ride into work this morning I realized my mistake.
I did not mean to say that being cute needs to go away. If you want to have a teddybear on your desk called Mr. Snuggles, that doesn't bother me in the least.
What bothers me is cutesy labels like what we're talking about here. They're so commonly used in a manipulative manner that I have trouble seeing them as anything other than scary.
I don't like them for when people watch TV or listen to music or use a programming language. And I despise them when companies try to act like there's a strong bond between employees by breaking them out.
Very, very creepy. Please don't contribute to that. That's all I wanted to convey.
I apologize if it comes off as sexist, because that's not my intent. Cutesy labels trip my cultometer. Hard. It's a creepy indoctrination technique, and I'm incredibly uncomfortable with it, especially after having grown up in a very gaslit home.
Even for people who know the word "crustacean", it's not clear how to say it. The cleverness of the pun doesn't make it more universal.
I'd guess "Pythonista" or "gopher" are much better in that regard because they are almost obvious to pronounce in other languages using the Latin alphaber. They are only one "th" or "ph" away from regular German, for example.
There's been a number of competing names (e.g. rustler) but rustacean won out because it has the advantage of being ideologically neutral and lacking other connotations.
> However, in cases where people say that some language is bad, it means that it simply does not fit their tasks.
I disagree. It is possible for a language to simply be a bad language. Intercal is intentionally so. I will refrain from mentioning unintentionally bad languages in order to avoid a flame war.
If the task is to show everyone their own steepness, then isotheric languages are a good choice. Isn't it? If people did not confuse causes and consequences, it would be more boring to live without sacred wars. It is not correct to call a language bad. But it is correct to call a language not suitable for a specific task.
In fact, the flame wars can also be useful as an advertisement.
Nobody would have accused Brainfuck of being a good language but it turns out that its radical simplicity works well for integrating with optimization algorithms for creating self-programming AIs. It's all about a niche, except INTERCAL, you're right about INTERCAL.
I'm not on Twitter, and so cannot contact Jonathan Turner (whose website this list of facts is on). On this page, some of the links to the Rust Survey results are broken - they have a prefix of jonathanturner.org and have the actual survey results link within parentheses. [1] They should be corrected to link to the Rust Survey Results. [2]
Is "Rust" a positive-sounding name in the first place ? It's old, decaying metal. It's like saying your favorite image editor is Gimp. It is a fine piece of software, but sounds unprofessional for native English speakers.
If the "metal" is the existing ecosystem of languages, then the name would imply that it will slowly eat away and replace code that's been written in other languages.
Good point. The term doesn't sound good. I'd rather call myself a Rubyist or a Pythonista. What we call something matters. Presentation matters. Some geeks think they're hyper-rational, but do you turn up to a job interview in pyjamas? A new programming language should use a positive and cool name.
"Rust" is positive and cool. Job ads can just use "Rust programmer" instead of whatever cutesy demonym. I don't look at job ads often, but I don't recall seeing terms like "Rubyist" or "Pythonista" used in them.
Dunno - I think “Rustacean” sounds fine. Whereas “Pythonista” makes me think of Starbucks and hipsters (not necessarily a bad thing, but still), with “Rustacean”... I think of some solitary crab-like creature lurking in gloomy depths (literally, a “low level”)... robust, with a sturdy hard shell... content to exist without drawing a lot of attention to itself, but nevertheless a bit mysterious, intriguing.
Really, it’s a better analogy for Rust programs than programmers themselves, but associations don’t have to be exact. I see it as very much positive and cool.
I don’t think I’ve seen “Pythonista” in a job description in a while, even among pretty casual hip startup job postings. I actually had forgotten that term, but to be fair I’ve been in the Ruby world for a while. :)
I think I’ve seen Rubyist here or there, but it’s still not common (based on my somewhat extensive Bay Area Ruby job search early this year). It’s also the most standard grammatical construction, and doesn’t sound too punny or playful at all (which can be a good thing depending on the tone you want to set on your resume or job posting).
If you have a recent version of Firefox installed, you have Rust code running in production on your computer. Along with the dozens of other companies who are now using Rust.
This is the same kind of thing even if less stomach turning than the negative crud. It's pretty crappy and doesn't really belong here any more than Oracle and IBM global services adverts do. It is not anything like objective and in any sensible assessment of Rust should be roundly ignored. Just like big consulting firm whitepaper "Are you enterprise ready!?!?!"
All the very best to Rust hackers, may you achieve your technical goals in both your design and implementations and have loads of fun on the way!