Not sure what is meant by pure, probably another way of marketing to Rust aficionados. It uses crates which still rely on unsafe ‘C’ code to interact with operating system for interacting with files and file related OS calls.
It will be nice instead of proclaiming Rust as “C” replacement it should have positioned as “A language complementing C/C++ to write safe code”.
Recently Servo project is abandoned by Mozilla for which Rust is a primary language.
Now need to see, if Rust can fulfils it’s primary objective to write Firefox in Rust, it looks more remote now. So it will take much longer for Rust to become as ubiquitous and important as Go language for systems programming. Probably Microsoft and others might pick to write some core new systems in Rust, instead of just rewriting same working C/C++ code in Rust for marketing purposes.
Rust market itself as replacement for C/C++ and proclaims as if all code written in C/C++ is garbage and only Rust can solve it, when majority of it's own useful crates heavily rely on unsafe "C/C++" code.
So "Pure Rust" is also marketing when you look at the crates used by this software are not Pure Rust, but rely on unsafe code of C underneath.
Python, PHP do not claim as C/C++ replacement, indeed Python is synonymous with CPython written in C.
In Rust community so far what I noticed is that they try to down-vote anything which shows them that Go language or Swift are more important systems programming language and Rust needs another 10 years to reach to write enough useful software like Go or Swift.
Also in Python look at the example of pure python HTTP server Cheroot [1] and check how many PyPI packages it relies on. Also it can run in CPython, PyPy or Jython or any implementation of Python. Rust does not have anything like this yet so using Pure is misleading given it only has one compiler dependent on LLVM (written in C++) to generate target binary.
Are you a C programmer threatened by the emergence of a C competitor? I have nothing to gain by "promoting" Rust as I'm not a Rust dev. You have commented a lot in these threads to complain about Rust.
If I'm right remember that both your self worth and your employability are ultimately not tied to C. Programmers switching programming languages are not life long miners that have to turn overnight into lawyers. You start building something with Rust and you should be operational quite quickly, most of your skills transfer over.
> You start building something with Rust and you should be operational quite quickly
Rust is anything but easy and simple like Go language.
Please try building something like Kubernetes in Rust instead of Go and you will realize “Rust” is a a complicated language (worse than complex). Rust has a steep learning curve and the standard library is quite limited. So you will need to search and choose from different crates to do eve basic work. Eventually one can be productive in it after 2-3 years of development. Compared to it Swift, Go are much easier to pick up as systems programming language and C++ 20 is advanced enough to write safety critical code. There is a reason why large body of systems programming and software for database,network servers is written in Go language not Rust.
> Rust is anything but easy and simple like Go language.
Rust sure isn't "simple" for anyone, but if you are a C/C++ developer, I'd definitely expect someone who's been writing C code for more than a few years to be able to pick up basic Rust in a few weeks.
Instead of being threatened by other languages and rationalizing why it's not worth picking up, why not spend a few weeks on it so you can have an informed opinion on why it's good or bad?
No language is perfect, everybody knows that. Rust isn't for every use case just like C, PHP or Python isn't for every use case -- but knowing a little bit about all of them means you'll be a better programmer in the end, because you can recognize what tool fits best for the job.
Yeah I honestly never get these threads. I think perhaps it's C++ veterans that have the language spec memorized, and so they have forgotten that C++ is an absolute minefield and has a much steeper learning curve.
I've been using Rust for 3+ years, and while it has a learning curve wrt lifetimes, it's nowhere near as hard to learn as C++ IMO. I recently tried to pick up C++ (yes, I know, weird to have gone to Rust prior to C++), and I finally just gave up and went back to Rust because nothing works how I would expect it to. There are so many edge cases and weird things you have to know to use C++ effectively.
Also add in the fact that you still need to learn lifetimes in C or C++, except now you are responsible for tracking them rather than the compiler.
Go has much bigger backing that Rust. And most of that server software comes directly from Google or their ecosystem: Kubernetes, Kubernetes appendages, "Cloud Native" stuff.
And Swift is only relevant because it's the only modern, officially sanctioned, systems software programming language on 2 platforms: Mac OS and iOS (especially iOS). I know of 0 people who use or have a desire to use it outside of MacOS or iOS.
Time will tell, but Microsoft, Amazon, etc. have adopted Rust. And if you look at what they're doing with it, it is generally much lower level than Go or Swift stuff. It's directly in the C/C++ ___domain.
Agree time will tell at present Rust is like other niche systems programming language competing with others like Nim and Zig bit more popular due to Firefox being popular. Nowhere close to Go or Swift, may be in 5 years might have something substantial by Amazon and Microsoft available in open source.
> Go has much bigger backing
Go is popular because it’s easy, simple, performant with opinionated design and similar to Python controlled heavily by its creator. It gets the job done and it’s syntax can fit in brain, without fighting the language itself.
It has very good standard library.
It is adopted more outside of Google than inside.
Simplicity is easier said than done and Go language did it quite well. It’s like Apple devices and OS beautiful and simple, which works but some just hate it.
Rust doesn’t aim to be simple and easy, as it makes people in Rust community feel superior to other programmers by virtue of showing it as complex and difficult.
You can see example of this in this thread any comments critical of Rust pointing its shortcomings is downvoted because it’s difficult to digest how the best and safe language for systems programming can have any shortcomings.
I don’t mind working in Rust (indeed tried some simple examples and didn’t find any feature special what I can’t do in other languages including safety). I also learned Haskell (which is more complex than Rust) and Lisp (like it more because of its simplicity).
Careful, if you only measure by popularity, you'll get to Java and Javascript as best choice. I'll make a guess and say that these two are not what you want :)
Well, popularity (quantity) does have a quality all its own.
Rust will never be extremely popular, just because it is more low level. I'd say that for each low level concept you add (pointers/references being on of the big ones), your "market reach" for a programming language goes down by an order of magnitude :-)
> Please try building something like Kubernetes in Rust instead of Go
At this point, it's clear that you are simply trolling, because Kubernetes is a well known counter example against Go: the lack of features was so blatant they had to design their own generics system as a preprocessing step.
OT: "Steep learning curve". Can someone give me an intuition that explains the meaning? My understanding is that it means "requires a lot of effort to learn to some degree", but when I see the words "learning curve", I imagine a graph with time on the x-axis and knowlege on the y-axis, and when that curve is steep, that means you acquire a lot of knowledge in a short time. Which is kind of the opposite...
Can someone give me an intuition that doesn't clash with the intended meaning like that?
Have the y-axis represent effort required to advance, and x-axis level of mastery achieved.
F.ex “effort“ could be quantified as topics in a book to cover before being ready for the next chapter, and “mastery” as simply number of chapters read.
The intuition is supposed to be that knowledge is on top of something like a mountain. It is easier to climb up a small hill than it is to climb up Mt. Everest. This is because (in the analogy, obviously in real life it's more than just this) Mt. Everest is steeper than the hill your house is on top of.
In other words, the issue with your intuition is that the speed at which you go up the curve is constant, but in the saying, you go up the steeper curve much more slowly than you do the slight curve.
>Arguably, the common English use is due to metaphorical interpretation of the curve as a hill to climb. (A steeper hill is initially hard, while a gentle slope is less strainful, though sometimes rather tedious.
So common, that it's basically become the default interpretation. Kind of like "irregardless". I wonder if there is a name for phrases like this that basically mean the opposite of what the words literally say.
C/C++ market itself as replacement for assembly languages and proclaim as if all code written in assembly languages is garbage and only C/C++ can solve it, when majority of it's own useful libraries heavily rely on unsafe assembly code.
So "Pure C/C++" is also marketing when you look at the libraries used by this software are not Pure C/C++, but rely on unsafe assembly code underneath.
Python, PHP do not claim as assembly replacement, indeed Python is synonymous with CPython which is ultimately written in an assembly language.
Also, C/C++ relies on LLVM, which runs on assembly language to generate the target binary.
> C/C++ market itself as replacement for assembly languages and proclaim as if all code written in assembly languages is garbage and only C/C++ can solve it
Your assertion is not true in C/C++ community, but “Rust is good and C or any other systems programming language is bad” is common assertion in Rust community. Most C/C++ programmers will not mind writing handcrafted assembly. Seen plenty of such examples in game and embedded systems development. C/C++ contrary to your arguments make it very easy to incorporate handcrafted assembly along with C/C++ code, haven’t seen handcrafted assembly code in Rust so can’t say if it’s as easy as C.
Rust's inline assembly used to be the exact same as clang's. We recently merged a slightly different version, in the hopes of stabilizing that feature. It ends up pretty similar. (I've been writing a bunch of inline assembly lately, and in fact, ported some C inline asm to Rust. It's not exactly identical, and I did in fact introduce a small bug when doing so...)
It’s good Rust adopted C style handcrafted assembly, earlier didn’t expect it given emphasis on safety at any cost as handcrafted assembly is a dual-edged sword it can help with performance and direct access to hardware, but can also introduce bugs.
Porting code will have some stumbling blocks, but given enough time and some resources those mountains can be crossed and may uncover new trail and then leave the ropes for other climbers.
Personally I am from the camp who likes the simplicity of lisp. That’s one of the reason in spite of learning some Haskell to learn about FP, didn’t continue long although I like Haskell’s brevity as in “Brevity is the soul of wit”. Haskell really makes it easy to refactor the code, but given large surface area makes it hard to learn and develop. Rust felt the same way although recently saw it becoming more approachable and easy.
I was pondering recently if built a modern lisp machines, how good it will be. A hardware directly controlled from lisp instead of C.
This is not Rust's position on safety. Rust's position is that you should be able to isolate unsafe parts of your program. And we try to give you tools to make them as small as possible. But unsafe stuff was deliberately included in Rust, on purpose, as a tool to be used.
I also wonder what a modern lisp machine might look like. Oh well, I don't suspect that will ever happen.
> if Rust can fulfils it’s primary objective to write Firefox in Rust
This was what Mozilla hoped to do with it. But the teams at Google, Facebook, Amazon, Microsoft, Dropbox, Cloudlfare, fastly and others using Rust have different objectives. At this point, Firefox's success and Rust's success are decoupled.
Do you also object to the term "pure Python" because the Python interpreter is written in C? Or "pure JavaScript" because there's a whole browser underneath?
