161–170 of 200 posts
Earlier quoted context omitted.
> Git already runs on more platforms than Rust can target. cough cough Windows cough
What do you mean? Both Git and Rust run very well on Windows.
Earlier quoted context omitted.
What do you mean? Both Git and Rust run very well on Windows.
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.
Earlier quoted context omitted.
> Julia is dynamically typed
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.
Earlier quoted context omitted.
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 oth…
(Another option is a gcc frontend for Rust, which the gcc folks have said that they're not opposed to)
Programming language flamewar is not interesting, so please don't do it here.
Earlier quoted context omitted.
Hi Byron. What in your opinion would be a good place for someone to start contributing to this?
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
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.
Witness the number of contributors with https://github.com/rust-analyzer/rust-analyzer/graphs/contri...
If you want to increase adoption, please borrow as many dev experience tricks from rust-analyzer as possible
How much use of unsafe is there? 'Pure Rust' counts for little if the code overuses Rust's unsafe features. edit This was a sincere question. I'm glad the answer turned out to be that there's very little of it.
rg "unsafe " | wc -l tells me there are 19 occurences, for about 13.7k lines of Rust in total. So it's not a lot.
Earlier quoted context omitted.
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 can be good contender for C replacement
Earlier quoted context omitted.
I think that ANSI-C is a lot more portable than Rust, to be honest.
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.
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?