61–70 of 498 posts
How big are the executables when compiled, especially compared to the C versions? I hope it's not Rust version 2 MB, C version 6 KB.
What are the licensing implications for this kind of work? I assume the authors used GNU coreutils as more than just inspiration. They probably read all the original code and reused some of the solutions (obviously ported to Rust). Shouldn't the derivative work still be covered by the GPL?
What are the licensing implications for this kind of work? I assume the authors used GNU coreutils as more than just inspiration. They probably read all the original code and reused some of the solutions (obviously ported to Rust). Shouldn't the derivative work still be covered by the GPL?
https://github.com/uutils/coreutils/blob/master/src/whoami/p...
looks suspically simmilar to:
http://code.metager.de/source/xref/gnu/coreutils/src/whoami....
I'd really love to use rust, given the large growth of projects like this. I only need an IDE to get started, but it seems like there isn't one yet. Anyone have any pointers on where I can find a good IDE for Rust? Should I just start praying to lord-JetBrains for something that works?
I don't understand why you need an IDE, I believe Rust is simple enough that you can work on things in Notepad++ or Vim or Emacs.
- Autocompletion
- Mass rename
- Source formatting
- Integrated debugger interface with breakpoint insertion and overlying of state on source
- Integrated VCS control
- Automated deploy
- Error display
- Automatic importing of modules
- Source cleanup (Automatic loop transformation)
- Automatically building my project
I understand that there are other tools that do the tasks better, maybe even faster, but that's not what I want. I want to be able to learn one thing, and learn how to use all of it's features well.
Earlier quoted context omitted.
Windows supports forward-slash fine. Has for at least 25 years. No need to change / to \ or visa versa. Now obviously any Windows port would have to call Win32 APIs instead of POSIX APIs (unless you're writing for a Cygwin-like layer).
Supported, just but it's a second class citizen, for example, no tab completion of directories on the cmd prompt when using forward slash. Some commands will not except it; e.g. type c:\home\foo.txt -> cats it out type c:/home/foo.txt -> 'The syntax of this command is incorrect.' whereas cd will except either forward or backslash cd c:\home/foo cd c:/home/foo work as expected.
It certainly beats using NodeJS. EDIT: Yea, this was meant as a reference to the coreutils-in-nodejs post on the frontpage.
NodeJS is for applications, Rust is for system programming. How does one beat another? It's akin to saying "ARMv7 assembly beats using Java for Android programming".
I have seen such a paragraph in another projects README, IIRC a Go rewrite of standard utilities. I do not understand why a project would be obsolete because it's on CVS or is old. CVS is simpler than Git, albeit less capable. I, for one prefer it over Git for this reason, and others may do so too. Why would the end user care?
And why would we care about the age of a programme if it works?
Now, that said, the authors need not justify anything, they are free to do whatever they want, and I guess it's fun to code this stuff. I tried this just to play with Golang when it was 1.1.
And lastly, that Makefile is really a bunch of shell scripts, and some common environment variables. There is no real dependency tracking in it, and it is easier to maintain a bunch of shell scripts than a seriously ugly and complex Makefile like this. N.b. that when I say dependency tracking I mean dependencies among input and output files of processing commands, not tasks. I guess Cargo would know how to do that, and how to not build if the build artefact is already there. It's a useless use of make. And that makefile is very GNU-specific, not complying with a project whose purpose is to be cross-platform. Also, I guess, tho I'm really unfamiliar with Rust and Cargo, if that makefile was removed, maybe on Windows they'd be able to drop development dependencies on Cygwin or Msys.
Earlier quoted context omitted.
It looks like there are 134 instances of 'unsafe', in 23,000 lines of Rust. And it looks like a lot of that unsafe is to FFI into libc. Rust works with GDB, so you end up debugging like anything else. IDE integration is being actively worked on, and sorta-kinda works in my understanding.
What is the roadmap on getting rid of the need for libc? Given how terrible libc is, I personally would make that a high priority, though I guess in Linux you can't even start up a process without libc (maybe that is a misunderstanding?), which makes the situation less clean, but at least you could get to a point where you never call back into it after entry into main.
Someone did start a C stdlib implementation in Rust, but it appears to be inactive: https://github.com/mahkoh/rlibc
I'd really love to use rust, given the large growth of projects like this. I only need an IDE to get started, but it seems like there isn't one yet. Anyone have any pointers on where I can find a good IDE for Rust? Should I just start praying to lord-JetBrains for something that works?
https://areweideyet.com/ vscode and textadept are good
How big are the executables when compiled, especially compared to the C versions? I hope it's not Rust version 2 MB, C version 6 KB.
Well, that would be a statically linked Rust version vs a dynamically linked C version. Either of those languages can produce binaries of either size. Statically link a MUSL libc and it'll be bigger than 6kb, dynamically link the rust code and use the system allocator instead of jemalloc and it'll be smaller than 2MB. (Or rather, it should be, I haven't literally tried it. The smallest known Rust executable is 151 by…
It gives a good idea if the replacements can actually be comparable replacements.
The second part is then to compare the number of features implemented and the behavior.