All: Rust has clearly reached the now-it's-a-flamewar-trigger stage of the hype cycle. Nobody wants that. If you're posting to HN, please stick to interesting specific things, not boring generic ones.
Programming language flamewar is not interesting, so please don't do it here.
I am one of the devs who got attracted to Rust's advantages over C/C++ (no double free or use after free, guaranteed memory ownership, relatively fearless concurrency) and have been using it increasingly to the point of now professionally working with it.
But I never felt the need to degrade others for not using it. I do have my strong opinions about when and where it should be used but I almost never escalate them to flaming (sadly it occasionally happens even to the best humans).
I'd hate it if such an excellent technology's well-deserved adoption is held back because its core user base is viewed as zealots.
I'm currently using https://github.com/rust-lang/git2-rs to interact with git in my software. Are you aiming to have a stable api that could act as a pure-rust replacement for that at some point in the future?
Absolutely! My plan is to proclaim a version 1.0 once the basic workflow of clone-commit-push can be performed, which should be enough for many to start using it. From that point on, the API should remain stable, following semantic versioning as usual.
It is my hope that the quality and stability will be high enough to convince people [in the Rust ecosystem] to move away from libgit2 and instead contribute to the maintenance and development of gitoxide, rewarding everyone with better performance and improved usability.
This sounds great, I added support for signing git commit's in git2-rs and would be happy to try to do something similar in gitoxide if I start to use it.
I might have missed your attention to this thread, but I'll ask and hopefully you'll be able to check later. I have to deal with a monolithic codebase that is of excessive size (10's of millions of lines of code) and has a very large number of developers committing against it.
I haven't looked at the internals of Git much, but performance becomes an issue with it in this context (we currently use a different vcs), and switching seems impractical at the moment. Issues from local performance (30 seconds or so for git status, git checkout, etc) and clone/fetch speeds.
I'm curious, given your experience on porting, have you noticed areas where we might be able to make improvements that might be easier based on Rust's safety improvements? Such as more threading or other areas that could improve Git for use with very large code bases?
(I plan to review the project as this would be an exciting area to work in to help with productivity in this space)
That sounds like such a project should definitely see improvements when using GitOxide. Even in projects of the size of the Linux Kernel checkouts can take time as those only reach about 3000 files per second. You will see only 70% of a single core being busy and a lot of kernel overhead. On my machine, using all the 4 cores, this number can be 7500 when checking out in parallel, something that `gitoxide` is definitely going to do from day one. After all, there is no value in just being as fast as git.
The same applies when checking for changes on disk - right now git does not do that in parallel. These are low hanging fruit that I plan to pick for my own sake.
There is another contributor who is very interested in increasing pack performance, which will directly impact fetch and pull speeds. Judging from my experience with packs thus far, I believe a lot of options are still to be tapped in that field as well. Rust will open it up for contributions and experiments to a greater audience, so I would hope that this will go way beyond of what I can do.
Even though this project is not very contributor friendly right now, I will be working on improving this so more people can join in (see https://github.com/Byron/gitoxide/issues/8).
Unfortunately I can't yet tell, as the corresponding code does not yet exist. Object and pack lookup is competitively fast so I would hope that translates well to everyday operations like that.
Right now, the project is clearly missing contribution guidelines, but now that it's a bit more public these will be added soon, possibly along with some tickets that are ready for pickup. For now I am very focussed on implementation.
That said, I have created a quick issue for you with a small tasks and high value: https://github.com/Byron/gitoxide/issues/7
Thanks a lot for your consideration <3
Great project - more power to you for driving it so far.
My 2 cents. I think rust-analyzer offers a great new dev onboarding experience. issues labelled with has-instructions usually have a a link to the relevant snippet of code in the repo and sometimes even the stub of a failing unit test. While it might be obvious to you, the author, how and where to find the necessary code, it enables a great many people to send patches.
I am not interested in competing with libgit2, and have no plans in adding and maintaining C-bindings to the project. This doesn't mean, however, that other parties couldn't maintain them out-of repo at first, and once things stabilize, it just makes sense to make them part of an organization that maintains it along with the project. After all, C-bindings open it up to be used in interpreters, which might be especially interesting for users of `GitPython`. It has been around for a decade and is definitely in for an alternative (I am the author and maintainer of that one, too).
There are several comments on the value of having this project be "pure rust".
Based on my experience, the main value is that it makes this code easily portable.
Meaning, if you can compile rust on your device, you can just run this code without worrying about also installing and appropriately linking the correct version of some C library. It's a huge convenience.
Of course, this only works if all dependencies are also pure Rust. I haven't verified that this is the case here. Here's hoping!
It depends on what exactly you mean by "portable." This is an extremely complicated space with a ton of interlocking dependencies, but here are two axes on which you could make opposite claims, and be correct:
* C is more portable than Rust because there are C compilers available for more platforms than there are Rust compilers for Rust platforms.
* Rust is more portable than C because Rust programs tend to be written in a more platform agnostic way, and are therefore more likely to be able to work on platforms that they weren't originally intended for.
(To make the second point more concrete, as a Windows user, pure Rust programs almost always Just Work for me, but as soon as we get into C dependencies, it becomes way, way way worse.)
No, no, ... Turbo Pascal is what is more portable than C.
Proof: just look at graphics. You just write your graphics code in a platform-independent way and use the correct .BGI file for your graphics hardware.
And it's safe: no pointer arithmetic or void; real array passing. Module system for dependencies. No makefiles needed. No problem of linking a stale object file that didn't get rebuilt due to a missing dependency rule.
This is beside the point I was trying to make. The point is that Pure Rust > Rust + Non-Rust dependencies in the sense that it's easier to compile, cross compile, install, or deploy.
If it's pure rust, then I don't have to worry about dynamic or even static linking. I just compile the code for the target and I'm done. Cross compiling becomes simple. Installing becomes simple.
I'm repeating myself a bit here but just to clarify: there's no question that pure C is awesome for portability. And like with Rust it becomes less fun once dynamic linking gets involved.
Only if you have no dependencies and interact in no way with any platform-specified services.
Now certainly there are platform-specific things with Rust as well, but the defaults are structured in such a way that exposed APIs are more likely than not to be platform independent--you have to go out of your way to break compatibility, rather than it being the default.
And once you get your binary to compile, the static linking means there isn't runtime dependencies that might break either.
The net result is that given a piece of rust code, it is far more likely than its C equivalent to compile on a new platform. And once it does compile, it can be run in any context without concern for differences in the runtime environment. The Rust compiler may target fewer platforms, and therefore be "less portable" in that sense, but if it is a supported backend then it is going to be easier to get the code working.
Static linking means that if a security flaw is found in a dependent component, you're responsible for shipping a whole new application binary to the end users; they can't just pick up some new shared libs from upstream of you.
I find in Rust I have far fewer platform specific switches with #[cfg(Unix)] and the like vs. the number of #ifdef macros in C.
If you’re talking about code portability of pure C, no dependencies, then I agree. Once you start depending on platform features, in my experience, the portability of Rust is superior.
The problem is that this requires the Rust run-time to be a ball of mud that provides everything for everyone.
Where is the Rust compiler for a Motorola 68K?
How about PIC24? And if there is ever a Rust compiler for PIC24, what will happen to all that run-time support? How much of it will work? How will you detect what of it works and what doesn't, in order to work around for it in your program?
Yet, it was claimed in the grandparent, that "Once you start depending on platform features, in my experience, the portability of Rust is superior" (because of no #ifdef crud and library versions and whatnot).
Maybe what it really means is that "once you start depending on platform features, the portability of Rust to a handful of mainstream platforms which have all those features in slightly varying flavors is cleaner due to some layering".
You don't have annoyances like, oh, foo_t requires <sys/types.h> on this platform, but on that other one it was already exposed in <stdlib.h>.
I mean, rust does have the equivalent of #ifdef. There are platform-specific things.
It's just that, with the benefit of hindsight, we designed support in three major layers:
* core, which only relies on there being like, a symbol for memcpy
* alloc, which gives you a heap
* std, which gives you operating system-dependent features
Based on this hierarchy, a lot of libraries that are OS dependent may use only core, or core + alloc. And way more crates do this than you might think, and it's pretty easy to move a crate to them if they truly don't need all that libstd has to offer.
I thought that was implied by the statement I made about C without dependencies being more portable.
In any case. You’re not wrong. We can caveat everything about Rust as “for the platforms it supports”, and in this context it is more enjoyable to work with across those platforms. And for all of my development needs, it targets everything I work with.
C is more portable as a language, but that's never been up for debate.
For suitable values of someone, Visual Basic embedded in Excel targets everything someone works with and they are happy.
In C there are also portability libraries. So for instance, suppose you want to do asynchronous I/O with sockets on a few contemporary platforms. You could do all the hard work and make it work with kevent on BSD, epoll_wait there, or I/O completion ports on Windows, with some select and poll based fallback cases.
Or you could just use, whatsitcalled, ... libuv and follow its API. Libuv has the grotty multiple implementations of the same thing in three or four ways, and ifdefs and whatever, so you don't have to.
Then you're into problems like: do you build libuv yourself and ship that? Or do you rely on the upstream one available in some of your target platforms, and which version will that be, and will that cause issues. It's going to be dynamically linked, so users can run with a different version than what you tested with as they update their systems.
But that's just due to having more choices.
If libuv weren't widely adopted, then that would be easier: there is no platform version of libuv. You want it, you build it yourself. You choose the version, pin to that, and you control if/when you update.
All that complexity is from more independent parties being at the table. It's not just you, Developer versus some Mother Ship (language that provides everything, including platform stuff).
We all know that C is portable and has many libraries that support that. The statement is that Rust is in the opinion of many of us that have experience with porting both languages to multiple platforms, that Rust is easier.
mio is the portable library many use in Rust for IO across multiple platforms, it's used by Tokio and other async frameworks to support async-io.
And, yes, if something doesn't exist you must build the support for it. This is true for anything? It feels like you're trying to change the goal posts on the discussion, to be one of library support now. But luckily in Rust, we have bindgen that makes it relatively painless to support C libraries when you want the "easy" path to getting libraries that are implemented there, but not yet in Rust.
The idea that Rust is more portable than C is laughable. C is the most portable language of all time, and Rust has a long way to go to compete. Git already runs on more platforms than Rust can target.
It's true that the C language is available on more platforms, including more exotic platforms, than Rust, and that will probably remain true for quite a while. But in another sense, Rust tends to be more portable in practice.
Take a random, non-trivial C program or library and try to compile it for something that's not a Unix (edit: or cross-compile it). How hard is it to do? Now, do the same with a random Rust crate. It's probably a lot easier.
I think there are two key differences. First, Rust has a standard build system (Cargo) that is dominant, while there are many competing build systems for C. Second, the Rust standard library was designed much more recently, and covers far more of the functionality in today's platforms than the C standard library does. (For example, contrast Rust's OsStr and Path types with the pain of supporting Unicode filenames on both Unix and Windows in C.)
I think this is a good point, but I think you're mostly talking about building rather than porting. It's way more likely you'll be able to port something from a popular architecture to an obscure one in C because the lingua franca is C, and shipping an architecture generally means shipping C compiler support for it.
I would guess this will slowly change as LLVM gets more backends, but that's pretty hand-wavy. The other option is we move more towards platform monoculture, which is probably more likely? Not sure.
I think the point is that Git for Windows needs a whole Unix compatibility layer (msys2), whereas gitoxide easily compiles to a self-contained executable even on Windows.
If you're interested in a step-by-step guide on how to build your own git from scratch, this book is excellent and incredibly educational: https://shop.jcoglan.com/building-git/
I've also seen a number of people following along in this book in other languages, including Rust. It really is a well written guide, even if you're not fluent in Ruby.
You probably misunderstood: they're not talking about building from source (which is easy), but rather about recreating Git from scratch in another programming language (which is hard).
I didn't watch the video but I've gone through that guide you linked, it's excellent but I don't think it's a great comparison. It only implements a handful of commands and doesn't go into the same amount detail. The Building Git book goes way more into the interesting bits.
My whole point was it is way easier than one thinks and there are good free resources available. Once you do the basic of git filesystem , object storage and sha basics implementing the rest of the API is trivial in comparison.
It's true that you can find most content somewhere freely available in various disparate corners of the web and everything is trivial if you have the info... but that's a strange reason to automatically reject a book you haven't read.
Does this address the cryptic-ness of git commands? E.g. are the various commands we all know and love like `git reset HEAD`, `git co --track origin/branch` etc. made clearer?
Even after years of using git, this is for me a major pain point.
> a simple command-line interface is provided for the most common git operations, optimized for user experience. A simple-git if you so will.
But an explicit non-goal is
> replicate git command functionality perfectly
git is git, and there is no reason to not use it. Our path is the one of simplicity to make getting started with git easy.
a simple command-line interface is provided for the most common git operations, optimized for user experience. A simple-git if you so will.
So it depends. They may refine some parts of the UX, others may be identical, and other still will be left unimplemented because git still exists.
Git achieves that stated goal, to a degree, via git alias. You can define your own simple versions of the commands or shortcuts.
What you've done is awesome!
What I would love to see is a pure-Rust reproduction of the git commands we know, some simple-git flavor commands, a Git API we can call from Rust, and the ability to add new Rust written git commands. I would love to put my money where my mouth is and volunteer to help, but my job right now is consuming all of my time not spent on family.
Git alias is bittersweet to me, much the same as various GUIs on top of VCS, like magit in Emacs etc. They give you a simplified interface to a subset of the functionality. But when you need to escape out of that, suddenly you need to use the full complex solution, and without the constant training of using the 'real deal'. I see git aliases in the same category. Gitoxide sounds a lot more complete.
Furthermore, git aliases work on your machine. Then you ssh to a server and suddenly `git please-do-my-command-without-many-weird-options` don't work. Yes you can sync them, but not super-easily. Whereas a complete tool you can just distribute onto the machines you work on. Not entirely different, but not the same either.
Since some existing tooling - various scripts, GUIs, etc - use the git CLI as an API, it would be pretty cool if a subset of this implementation's commands matched the originals exactly, even if some convenience commands are added on top of that. That would allow it to be slotted-in in many more places
It's a project goal to make the API so accessible and easy to use, that's it's straightforward to quickly throw together your very own custom commands that do exactly what you need.
This should allow building these slot-in commands as the need arises, and without breaking into sweat.
As this is part of the every-day workflow, I will think long and hard on how to make it as painless and user-friendly as possible. Having a more user-friendly experience on the command-line is one of the project goals, and it will also be me benefiting from it so the motivation will be high to achieve it.
By then, that thinking process will hopefully be public enough to allow more people to chime in and get a better result that way.
And yes, I think a lot is possible, and I can't wait to test some ideas of mine :)
I'd be interested to know what, according to you, are the worst part of git commands (I'm currently trying to figure out a better CLI on top of libgit2).
Let me reply with the most tedious parts, as I wouldn't want to make the impression of labelling git as 'bad' - I have been fascinated by it for more than 10 years now and it's time to scratch my itch for good.
Please note that everything I name can certainly be fixed by some tool that already exists, and that's great. It's just that I would like to have 'this one tool' that gets most things right and be happy with it alone.
That said, here is my list:
* adding individual files to the staging area/index
* looking at the commit history and copying individual commit hashes
* pulling while assuring no merge commit is created, or: simplified trunk-based development
* resumable clones
* seeing what's going on during all remote operations - here in China GitHub is incredibly slow most of the time and connections can be flaky
Thanks! That's really interesting to see that only 2 of your list (around adding and pulling) were on my radar as git usability issue, and not even in my top five!
The third one is a bit unclear to me:
> looking at the commit history and copying individual commit hashes
I frequently use `tig` to see the commit history, and pull out a single commit hash for use in `git checkout` or to reference it elsewhere. Probably it's just me not knowing all the `tig` hotkeys to make that easy, but it's my hope to have `gitoxide` as an obvious way to do things at least I need commonly.
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?
There was an HN discussion a few months back on a Rust program that overused the unsafe features, to the point it may as well have been written in C. Sure enough, it turned out to be full of nasty bugs.
> to the point it may as well have been written in C
Mildly disagree. Even if half the code base is unsafe, that's better than a code base where everything is unsafe. Now I only have to audit half the code base for crazy shit, which is about half the effort. A stronger type system means that even in unsafe land, we can still encode some invariants better.
I disagree with this notion that "if you're going to have bugs anyway, what's the point of Rust". Our goal isn't to eliminate every bug in the world, it's to have fewer bugs today than we did yesterday. Rust, even Rust with several unsafes thrown in, helps us achieve that goal.
In principle I agree, but note that such projects are not created in a vacuum. Someone who goes out of their way to put that much unsafe into the codebase is more likely to commit mistakes that lead to ub than someone who just writes C stuff.
> Someone who goes out of their way to put that much unsafe into the codebase is more likely to commit mistakes that lead to ub than someone who just writes C stuff.
[citation needed]. And it would be hard to find a citation because most Rust codebases don't have much unsafe. The repo you're thinking of was an anomaly and has since improved a lot.
> I disagree with this notion that "if you're going to have bugs anyway, what's the point of Rust" [...] [citation needed]
Well, this can be related to an actual real-world concept, that is "programming in a certain language with the syntax/runtime of another".
In my experience, all the times I've seen this happening, the project was just terribly written.
I program in Rust, and if I happened to put an excessive¹ amount of unsafe code in Rust, it means that simply, I'm not programming in Rust. In my opinion, in real world this phenomenon happens for beginners, lazy programmers, or bad programmers, especially for Rust, because it has a steep learning curve, and it requires an effort, when designing a project, that other languages don't require.
So there is a point, although theoretical, that a good programmer in an unsafe language, can produce a more stable project than a bad programmer in a safe language.
With that in mind, I still wish as others to see unsafe languages disappear :-)
Also most of those are actually `#![forbid(unsafe_code)]` declarations or comments. I only see two places where unsafe is actually used, via `UnsafeCell`.
Because pure-rust, as in, not relying on bindings to external git libraries is independent from using "unsafe" in the code. For me the question is misguided.
There are reasons to prefer a pure-rust code, even if the whole crate was unsafe.
Complaining about the use of unsafe as a “gotcha” is a common canard used by people who often don’t understand what it means. On HN at least, it’s usually not a substantial criticism.
My comment was neither complaining nor criticising, it was asking. I made this perfectly clear in my edit.
A program can qualify as pure Rust without making use of the safety advantages of the Rust language. It's not unreasonable to wonder how much unsafe code there is in a Rust codebase. It matters.
Rust is better for having unsafe features, but it opens the door to their overuse, and this shouldn't be ignored.
In the SPARK Ada world, there are 'assurance levels' that offer different levels of guarantees. [0] At the 'Silver' level and above, there is a guaranteed absence of runtime errors (such as divide-by-zero, or out-of-bounds array access). Rust doesn't have such a scheme. It seems reasonable to wonder about overuse of unsafe features (as fuzzy as that is), as a very rough approximation.
> In 2007, Jeff Atwood made the quote that was popularly referred to as Atwood’s Law:[5]
>> “Any application that can be written in JavaScript, will eventually be written in JavaScript.”
Because it is a interesting excercise to reimplement something great in a new interesting language you wanna test drive?
Why are people writing new programming languages? After all we already have some. Sometimes you do it for fun and frivolity, sometimes because you think you can do better, sometimes because you are addressing real tangible issues with the old way of doing things and often a combination of the three.
Honestly I used to find the "rust evgangelism strike force" obnoxious and naive, but man, after reading this thread and seeing all these brand new accounts that seemingly have nothing to do but complain because someone used Rust in a neat project, I'm honestly starting to think their attitude is 10x more obnoxious.
As we used to say, "haters gonna hate". It used to annoy me but now I mostly ignore it. If other people don't see the value in technical novelty that isn't directly in service of making money or having enormous impact otherwise, that's their loss - I'd rather spend my time hacking on something cool than defending the practice to someone who starts the conversation on the defensive.
Reimplementation relying on unsafe ‘C/C++’ code (as most of the core infrastructure is written in them) is done more for marketing especially among language aficionados.
Hope someone from Rust community can write something which can match some of the core software written in Go language, which has already proven its usefulness and quality in writing systems programs in networking and system infrastructure areas.
C/C++ replacement at this time is just a wishful thinking given Rust cannot work without C/C++ today, most useful crates will break if underlying C/C++ code is not maintained or updated.
> Reimplementation relying on unsafe ‘C/C++’ code (as most of the core infrastructure is written in them) is done more for marketing especially among language aficionados.
Let's read the page we are talking about to check your judgment:
"Project Goals: a pure-rust implementation of git including transport, object database, references, cli and tui"
Doesn't sound like they are relying on unsafe C/C++ code at all – and sounds like they are just doing it out of curiosity. Unless you mean that parts of the git infrastructure (beyond this project) use C/C++ and therefore as long as you don't rewrite everything at once, their effort remains meaningless, which would be quite a dire world view, so I am assuming you mean something different which I don't get atm.
This wasn't about Rust – it was about you making quite vague claims about somebody's project. I don't know you, but I do write software myself and know how easy unfounded claims can go haywire. So before critiquing the work of someone else I'd rather make sure the points I make are true, actually something the person I critique could have avoided and adequate to the level of the project (e.g. a hobbyist should receive milder criticism than a big organization).
So if you are claiming there is C/C++ in the dependencies – therefore the project must not be a true scottsman and should not have been written – so if you put the burden of proof on the other side, maybe it is time for you to look into the mirror, and ask yourself whether your opposition to a simple programming language is not a bit... irrational..?
If a innocent project like this one makes you use that kind of rhetorical moves consider the possibility that this says more about you than about the thing you are commenting on.
There's valid criticism of Rust and then there's what you are doing, which feels distinctly like flat-earthism of computer science. You pick arbitrary goal posts (like, pretending that "unsafe" isn't a keyword in "real rust") and try use that to discredit a language that a lot of people have found super useful and superior in their work.
I imagine there are different motivations for different people.
Some people may just want to use rust to re-implement something that exists in order to hone their skills or just for fun. Having a reference implementation makes that more productive.
Other people may think that it would simply be better if the project were implemented in rust. This is the case for some C projects, where a lot of control is still necessary but the project would benefit from the safety and productivity gains of rust. See the example of QEMU yesterday. It is an absolute pain in the ass to do things well in C. Correct programs end up being heaps of boilerplate and tests. I'd love to escape C but haven't been able to until Rust.
Maybe some people just want to showcase that Rust can do the thing. I think that's fine. It might help in adoption. It might cause better libraries to be created that are actually used.
For me, rust is the first real competitor in the systems programming market. There are hundreds of languages for application programming. I prefer Haskell, Java and JS for those but I've never found a replacement for C in the low-level ___domain. C++ just never cut it for me and the alternatives never really caught on. For me, Rust brings a lot of what we learned from Haskell and ML to C without sacrificing the low-level control. If I wanted to get better at Rust, I'd probably also implement something that exists just so I could check my work. If I was to re-implement some of the low-level projects that I've worked on, I'd also probably do that in Rust.
I'm getting really tired of comments like this though. Why does it bother you so much? Are you trying to communicate that you'd prefer this person be doing something else with their time? What does that even mean?
>For me, rust is the first real competitor in the systems programming market. There are hundreds of languages for application programming. I prefer Haskell, Java and JS for those but I've never found a replacement for C in the low-level ___domain
There is Pascal
I have used Pascal as safe C alternative for twenty years
It has solved all the C problems. Strings/Arrays know their length, you can enable range/overflow checking, reference counting ...
I don't know enough about Julia, but the definition of "systems" is different in Go vs. C/C++/Rust. Go is more of a Python, Ruby or Node competitor while Rust is more of a C, C++ or D competitor.
Doesn't mean that there is no overlap, but when you wish to go closer to the metal, picking Rust makes lots of sense.
Julia is positioned well to be a powerful high performance language in a niche market, that of scientific simulation, due to is reliance on long running. It also doesn't consistently match C benchmarks last I checked, "only" getting within a factor of 2 or 3. For a pythonlike language its very impressive and powerful, but its main competitive power is as a higher performance replacement for Matlab or mathy python.
Its gradually typed, and compiles down to typed code with LLVM on first run. So after a warmup (which can be cached) its effectively static for purposes of performance.
I was quoting the developers. I'll take their word for it. Whether something is compiled or not is orthogonal. I need strong static typing, preferably with algebraic data types. Julia doesn't provide any of that, Rust provides all of that.
Keep in mind that the person who posed this appears to have nothing to do with the project, they're just someone who's seen something that interests them and shared it here, the same as the people voting it up.
The hate is not towards every language that is Rust, it's against C, at least in this thread.
I haven't seen anyone arguing against Python or Java in a Rust thread. Memory-managed languages are already at the memory safety levels comparable to Rust's borrow checker.
More specifically, I hope, C++. I like to think of asm, C, and Rust as a trio. C isn't "better" than asm; it just doesn't make sense to use asm when C does the job. And it doesn't make sense to use C when Rust does the job.
C++ is where, in almost all scenarios, I draw the line and say, this would be probably be better if new code is written in Rust.
It's generally against both C and C++, because the reason applies to both of them. That reason being that using these languages expose users and the world to huge negative externalities in the form of security vulnerabilities, or alternatively (but resulting in the same conclusion) that the speaker just likes writing correct code.
> And it doesn't make sense to use C when Rust does the job.
There are few jobs left where C can do it and Rust can't, those jobs are generally "well there exists a C compiler for this architecture and not a rust/llvm backend". Rust is generally just as capable as C is at writing low level code. If you're willing to put up with translating macros by hand (or using wrapper functions), it's even capable of integrating with existing C code bases.
Lots of people still prefer C over Rust in various situations where you could use Rust, so I don't think it's a generally accepted fact that "it doesn't make sense to use C when Rust does the job".
As a Lisp programmer, I don't dunk on everything that is not Rust; I instead dunk on everything that is C. The extensive use of this language has brought us countless pain via stack overflows, buffer overflows, memory corruption, and multiple other vulnerabilities that are literally baked into the language model. Dropping C for any sane alternative will be a massive boon.
I think Ada's future is in safety-critical systems, where it makes sense to invest heavily in correctness, with the option of using SPARK and formal verification. Additionally, Ada has several mature compilers suitable for life-and-death applications.
For more ordinary software though, doesn't Rust make more sense? Its approach to memory management for instance, with a borrower-checker, seems much nicer than what Ada has to offer.
It would be fair to point out though that Ada has had decades to catch on and replace C, but it hasn't done so, except in certain narrow areas of highly critical embedded software development in aviation and military applications. My understanding is that it's not easy to work with for 'general purpose' work (command-line applications on GNU/Linux), as it lacks mature bindings.
I think it's fair to say Ada failed to truly embrace Free and Open Source software. A pity, in my opinion.
Well they are trying to reach FOSS community. Recently they started survey asking community "Hello here, we (AdaCore) have some plan for the future of GNAT Community that we want to share and have your opinion on: https://forms.gle/Q34myTCQUXvrva5n7
"
There is Ravenports very good port manager written in ada for FreeBSD so ada can be used for CLI apps and has good gtk binding too
They're compilers, not interpreters - or at least SBCL, CCL, ABCL, ECL, Clasp, CLISP, ABCL, and LispWorks are. I'm not aware of any other alive contemporary Common Lisp implementations.
Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. In addition, the Lisp compilers are written in Lisp itself, not in C, which further decreases the attack vector.
Also, the currently-in-progress SICL project intends to do away with C completely, even for its garbage collection and OS-interfacing parts.
In Lisp, the programmer never frees memory themselves, so use-after-free and double-free are not triggerable by the user. Bound checks for all array types are in effect, so overflows are impossible. Strong typing and a lack of casting prevent type confusion.
Do you have any arguments other than the unsubstantial "yeah, right"?
Lisp implementations using C means that the implementations may have C-related vulnerabilities, not Lisp programs themselves. You're not facing the risk of creating new C-related vulnerabilities by writing new application code in Lisp, even if the Lisp you're using has substantial amounts of the run-time written in C.
As others have said, the issue is with C style memory issues.
Rust not only gives you safety and correctness, but gives you often speed as a bonus over C. There is a real benefit towards rewriting everything written in C in a language/tool system like Rust.
There is still a place for other languages, especially ones that use a garbage collector. Rust would make that garbage collector a lot safer.
I think garbage collected languages like Haskell actually provide better security than Rust, because the code is not littered with constructs dealing with memory management.
The only reason to use Rust is if you need the performance. But often, that's only an issue in your "inner loops", so you could write the rest of your code in a more suitable language.
Since in most cases these performance critical parts are only small in terms of lines of code, and hence easily verifiable by hand, you could even write them in C and still not have security issues.
Therefore, I think Rust serves only a very specific need, and isn't nearly as universally "the right tool" as everyone seems to believe.
For applications like Web browsers the "inner loops" approach to optimization isn't nearly enough. Execution of important benchmarks smears out over huge amounts of code. If executing straight-line code in your favourite language is just a bit slower than C++, or touches more memory than C++, it's a losing proposition.
Since the top subthread comment has been predictably flagged by the clique:
Rewriting is easier than doing original work. If you manage to get people to use "your" new Rust project, you get a huge payoff for comparatively little work with lots of plagiarizing.
Sure. Do you have any arguments why it isn't broken and go against the arguments linked in the related HN discussion? Is CPython in some way immune to overflows, use-after-free, double freeing, and so on? How much of CPython is actually implemented in C, and how much in itself and/or in Python?
That's a little different. If you're running a C linter that statically guarantees safety, then it's comparable; otherwise, you're comparing mostly Safe Rust (with some Unsafe Rust in it) to Unsafe C.
Safe Rust is automatically immune to lots of these issues. Unsafe Rust isn't, but all of C is unsafe (unless you're using a safety-enforcing linter that only gives you access to a subset of the language).
I don't think the author thinks git is broken, most likely the opposite. I often reimplement things I admire or want to learn how they work. I would guess that is one of the motivations of this project.
Perhaps because it brings them pleasure. That hardly seems a sin. And then they share it with others, for whom seeing the work is a pleasure and perhaps an inspiration. That seems just as little of a crime.
As I have understood it, the major coding flaws in Git involve failure to handle OS and file system errors responsibly. (The SQLite people are very persuasive on the topic.) Rust does not seem to bring anything new to this particular table.
Any improvement in this area would need to inhere in library-level facilities constructed for the purpose. What are they?
Not to be overly pedantic but calling .unwrap() is about as far from swallowing an error as you can get. That's gonna panic right away if it's an error case.
Programming language flamewar is not interesting, so please don't do it here.
https://news.ycombinator.com/newsguidelines.html