Foundation thrillogy: Rust programming language gets new home and million-dollar spending account Almost six years after it debuted, the Rust programming language is moving out of the Mozilla's house into a foundation of its own. Mozilla and the Rust community on Monday plan to announce the creation of the Rust Foundation to oversee the sustenance of the language. The non-profit foundation will manage the IT and …
The blog you link to is already out of date... which you should know if you read this article.
Nothing there to indicate why Rust is falling out of favour - just makes you sound jaded. Are you annoyed that tools are improving and those that use them get a better result? Seems a strange, although not uncommon mindset.
I cut my teeth with C++, love it, but its like using a chainsaw when you could use a table saw... Still a specialist tool not well suited to all tasks, but a lot safer than the old way (and table saws, like rust, can also be used un-safely).
I will not be using C++ for new projects, I've been happily using Rust for comimg up on 2 years now, and I expect to like it for significantly longer than 15 minutes
Err... I was referring to the comment that Rust was abandoned by Mozilla, which was not true yesterday either (though things didn't look great when the job cuts happened)
But by comparison, your sweeping generational generalisation really hits the mark. All people born within {years} of {year} are {attribute}. I hope you enjoy the stories of competent {career} being pushed out their jobs in favour of cheaper graduates.... Also, given that 1980/1 is the starting year for Millennials, the audience for those stupid comments is very much the minority in any public forum, particularly so on the Internet. Lol #hashtag
"...given that 1980/1 is the starting year for Millennials, the audience for those stupid comments is very much the minority in any public forum ..."
Actually, it's not :-/ In context to IT specifically, Millennial Panic is setting in as the once "young enough for IT" generation is now approaching (or is) "too old for IT". However, this goes beyond IT for Millennials and into other realms such as "we'll always be in debt" and "it's not my generation's fault" cynicism/illusion/denial/wtf ever. For right or wrong, the "Boomers" and a rapidly increasing proportion of Gen X just don't care anymore and are not fueling what you see on the internet. If you step back you'll see this all around, as it's almost purely "Millennials" starting drama and cynicism across Twitter/Instagram/Blog/$FlavorOfTheDay.
> Are you done
I'm not done. And look up the word fallacy. It doesn't mean what you think it means.
Want references? Here you go:
https://www.wyzowl.com/human-attention-span/
The average US attention span in 2015 was 8.25 seconds. It's probably below 8 now.
The average US attention span in 2000 was 12 seconds.
The average attention span of a goldfish is 9 seconds.
And that's just the first thing that pops up in Google when searching for 'US average attention span'.
Facts are stubborn things.
Oh so your source is a service selling videos that can capture our attention for longer and -how convenient- they have a page stating our attention spans have shortened. Extra points for the "according to research" in the image (not a video so I could only keep my focus for 3 seconds) and the sources bit mentioning the daily mail.
The study was actually done by Microsoft:
https://dl.motamem.org/microsoft-attention-spans-research-report.pdf
Warning: PDF.
It was widely quoted.
And yes, the topic of average attention spans is something a marketing department would be interested in.
So being widely quoted is a metric of quality? Apart from the obvious problem with the study sponsor (tobacco company finds smoking healthy), the "research" has zero citations, the methodology doesn't provide any details and the numbers have no units. This is just another advertising company displaying mathiness. This isn't science.
As an expert (at old man yelling at cloud) I don't get that vibe at all. The post seems to be a valid discussion of the network effects combined with Gartner Trends (for better or worse).
Except for the comment that Rust has been abandoned by Mozilla.
Today's announcement makes yesterday's pronouncement wrong, at least for the moment.
Rust now has the funding and the backers to succeed in the long term (although that is not guaranteed). At least it looks like in the short term it will continue to grow in both capabilities and uses.
It does now have funding and backers, which is indeed good. What I think is interesting about Rust compared to other recent languages is 1) it is a systems language, 2) it makes a real advance in comparison to other existing system languages, 3) some very significant players in the operating system world seem to be taking it very seriously indeed.
I can't recall any other new language that has got all of Microsoft, Google, Apple(?) and Linus Torvalds all scratching their chins muttering that Rust is probably going to have to be incorporated into their various projects sooner rather than later. If those folk all start using it in their projects in a big way, then it will have become the new de-facto systems language. The fact that there's already some pretty impressive (in terms of time taken to write it so far) Rust OSes running is also very hard to ignore; some quite small projects have written a hell of a lot of code really quite quickly. Redox went from nothing to a GUI desktop in about 3 years flat?
Its the old problem of people ascribing problems to a language that aren't actually problems with the language but the environment they're using it in. Rust's syntax appears to have nothing in it that distinguishes it from 'C' except that it uses extra keywords like 'let' and 'fn' to make it look new and improved. The critical bit that these language developers overlook is that a support library is not an inherent part of the language, its something you add in for your convenience, and so if there are problems with a particular concept like scoping or input parsing or arry slicing then its not the language's problem to sort it out, its has to be dealt with in the libraries or by the discipline of the programmer.
This may seem to be a bit nitpicky but the fact is that if you want to play in the systems space then there's no room for people who don't understand exactly wha's going on. There's no point in designing a pseudo-applications language that tries to isolate this from the programmer -- you'll pay for it in coding efficiency, for a start. (This is tolerable at the applications level because there we trade off efficiency for convenience and safety. Its why you should never write applications in 'C' -- the language is what you're supposed to write the applications language in, not the application.)
(I'm allowed to be cranky about language verbosity and meaningless syntactic tricks -- I'm retired so I don't have to put up with dumb stuff to save a semicolon here or a brace there.)
You have retired too early then. The point of Rust’s syntax is that it contains the idea of memory ownership. Memory can’t be mutated unless it is owned.
This one thing solves a number of problems. The compiler has full visibility of the scope of data, and the programmer doesn’t have to write code to do clean up. It also means that programmers of multithreaded code have to have a firm grasp of ownership because the compiler can spot when data is going to be modified in separate threads.
What this boils down to is the fact that if it compiles then there are no mistakes with memory usage. Whereas C compilers don’t give a damn about whether you’ve got an access after free problem, or a failure to free up memory, or two threads both mutating data at the same time.
This seems to translate into several benefits. Running Rust code is guaranteed to be memory correct. Development time seems to be faster because an awful lot of bugs are eliminated at the compiler stage. It’s a whole lot easier and safer to exploit multi core CPUs.
That last point is important. Firefox’s CSS processing was rewritten in Rust. Apparently they developed it as a single threaded thing, got it working bug free. And then they turned on the parallelism afterwards. I don’t know the exact details but it’s something to do with the compiler having complete knowledge of what data ownership is, and can therefore know what can and cannot be run in parallel.
It also has serialisation as part of the language, which is seriously useful.
It’s these things that are appealing to the big OS players. Faster development times and the elimination of whole classes of bug are seriously tempting to companies and projects where developer resources are precious and bugs are seriously damaging.
For years many (including myself) have asserted that C and it's like are just fine, because if you're careful, and skilled you can avoid problems.
Unfortunatly, time has told us this is not true.
You may be able to write perfect bug free C, but I certanly can't, and nor can many many others if the bug lists for, well, pretty much every OS, are to be believed.
Syntactic sugar and language enforced safety (that you have to conciously override rather than accidentally misuse) are not bad things. We're not running on 70s era hardware anymore, bloat is one thing, but we can afford a little more processing power at the expense of safety, surely?
It's also worth noting that Derek Jones has studied the real-world use of programming languages at considerably length, as anyone who's read his The New C Standard knows. I'm not persuaded by this particular blog post, nor by his prediction for Rust (which I like) and Go (which I don't). But I wouldn't dismiss his opinion out of hand, either.
Once programming languages reach a certain saturation point, they stick around - apparently quite durably. We continue to sell a PL/I development and execution environment because there are still plenty of PL/I applications in production, and our COBOL sales are much larger yet. Jones mentions C#; that's still going strong. Languages become unpopular, but once they get into production it's hard for them to go extinct.
I wouldn't recommend someone become a "Rust developer", but then I wouldn't recommend someone become a "chisel carpenter" either. Identify with the techniques, not with the tools.
I'm no expert, but I get very strong "old man yells at cloud" vibes from that blog.
Agreed. That blog describes Rust as a vanity project abandoned by Mozilla, somehow missing the fact that Rust is heavily used in Firefox. There's whole operating systems written in it. Microsoft, Google, and even Linus Torvalds are planning on or already are incorporating Rust into their OSes, the Rust folk having had a chat with the Linux folk are going to make some language additions specifically to make OS development even easier in Rust, etc. And yet there's a ton of higher level things that can be done readily in Rust too.
I don't think the blogger (who shares a name with the OP - bit of self promotion going on one suspects) has heard of .NET Core either...
The blog is also (I think mistakenly) equating "popularity" with longevity. Or even positing "ubiquity" as the only stable place on the popularity curve. He went back to COBOL and Fortran as identifying niches, but the Lisp family (especially some of the schemes) are still kicking along, with many implementations and many users, just not as many as JavaScript.
LLVM did kick the language design business along mightily, IMO. Before LLVM you had to be prepared to write your own optimization passes and target the several interesting processor instruction sets, or do without either or both, or use something like C as an intermediate compilation step, an abstract assembly language. There are some interesting language constructs, like closures, that aren't easy to do from C, so that's a bit limiting (notwithstanding Chicken).
This post has been deleted by its author
well to me it provides the closeness to hardware as C, while removing some of the issues that c and c++ has with side effects that makes safe multi-processor programming a challenge. So it could be used on high performance systems with a safety element (i.e require predictability). There are other languages out there that offer the same, but it does not require you to learn another programming paradigm like functional programming.
What shouldn't you use it for? Well like C, you can probably do most things in it. Whether you should is another question
This post has been deleted by its author
From the article:
As a systems programming language, [Rust] is unlikely to become as popular as higher-level languages that have a lower learning curve, like Python.
I think what the article is trying to suggest that Rust when used as a high level programming language won't be as popular as, say, Python. That is a plausible prediction. But as a systems language it is, by definition, going to be far more popular than Python, for the snake-themed scriptese is pretty much useless for that purpose.
However, whilst we're on the topic; there's no particular reason why Rust couldn't become a popular high level language. It has a lot of nice high level language features (such as freedom from having to do one's own cleaning up, really sensible approaches to modules, serialisation built into the language, quite a lot of web themed crates, iterators, etc) and, having a very well organised ecosystem around it, it is in good position to be used in all sorts of applications on all sorts of platforms. Arguably, if it ticks enough boxes for a project calling for a high level language, it would at least produce an application that'd likely run jolly quickly.
But as a systems language it is, by definition, going to be far more popular than Python, for the snake-themed scriptese is pretty much useless for that purpose.
Python's existing use as a systems language would suggest otherwise: there isn't a Linux distro that can do without it. But, while it has its uses, it also struggles in some use cases, particularly processing of very large amounts of data and some forms of parallelism. However, it works well in combination with other languages and I've even seen people swapping out C libraries with Rust implementations that are then called from Python with no additional overhead and no change to the API.
Python's existing use as a systems language would suggest otherwise: there isn't a Linux distro that can do without it.
As well as Katrinab's point about Python being used to replace Bash scripts, it's also worth pointing out that at the other end of a distro C is also replacing Bash scripts. This is happening in the ghastly, hideous shape of SystemD.
If we're to be saddled with something like SystemD, if it had been written in Rust we'd at least have been able to be confident that it wasn't riddled with memory errors.
I'm a scientist not a programmer (Jim) but I use Python a lot in Monte Carlo modelling, etc. I'm hearing a lot of rumblings in the community from people taking the time to learn Rust to move to that from Python for performance reasons, whereas the older generations used C++ or something (I know one old chemistry prof who is a whiz at Fortran). If I had the time I might look at it myself.
Seeing as most of the heavy lifting is already being done in some C/C++ (and maybe even Fortran) libraries, they may be disappointed. Where there is performance to be gained is in not copying data between runtimes, which is why zero copy data is such a thing nowadays.
And that is precisely why Rust is so promising. It's far quicker to pass data ownership around (which is what Rust does) than the data itself.
It's even been a long established concept in many performance C libraries. VSIPL relies on handing ownership of data over to the library, calling a bunch of library routines, and only at the end of a chain of processing passing ownership back to the application. Rust just makes this sort of thing mandatory, between everything.
Agreed. I am a scientific programmer (or programming scientist, depending on the day of the week) and work largely in Matlab, as it is de facto standard in my field (although Python is making inroads). As you say, most of the grunt is carried by libraries (BLAS, LAPACK, SLICOT, WFFT,... in my case) and I'll write C plugins for anything more exotic. Matlab is fundamentally crappy as a scripting language, though, and I'm not enamoured of Python either, so have been doing some serious dithering about moving into Rust or Julia - my main concern being library support.
While some languages have indeed been abandoned to open source – Swift springs to mind – it's not inevitable. Programming languages don't need large organisations to maintain, but they do need institutional security. Basically you need to cover the costs of hosting the development environment, having a secretariat that can coordinate and lawyers to handle the inevitable copyright issues and stuff. Mozilla has insulated Rust from its own fate and got other interested parties onboard. If they can maintain the fine stewardship thus far, there is no reason for the language not to continue to thrive.
Dear Mozilla bods, while you're here, Geckoview doesn't support multiple views.
Yes, I know you have it marked "complete/works for me" but there's a simple problem with it.
WebExtension.MessageDelegate are not stored PER SESSION, instead you've made it per (extension id+appId), so one session in each of two views on screen at once, could not have separate message pipes to each view. And cannot be controlled. You can only control one view, and one view only. Good enough for Firefox in an single screen app on an Android device, but useless for more complex multipane software I'm working on.
It needs fixed. Android will get better, and you will need it in future.
https://mozilla.github.io/geckoview/
But really, you should just be able to execute javascript in them. Webextensions are a bit half assed anyway. Per domain code gives half assed control anyway, as pages go wandering off domains. These are controlled views, so let them be fully controlled!
I think that Rust is just a very successful experiment but its lessons will be borged into the main stream languages eventually. It's main problem is the bolt on parallelism due to its initial establishment as a single threaded css processor within Mozilla. Go has the parallellism built in far better but will also be borged in the long run. The reason is that languages like C++'s problems are unavoidable if you want to deal with the breadth. The alternative is that we will no longer have main stream languages but separation into niches.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
