3 ms·

The worst is that they keep messing with things outside the language. It is normal to have a set of tools that you like or wish to retain. There may be a packa

by burfog 6y ago

The worst is that they keep messing with things outside the language. It is normal to have a set of tools that you like or wish to retain. There may be a package installer (rpm, apt, msi, etc.), a build system (plain Makefile, autoconf, CMake, the Visual Studio project/solution files, etc.), a linker (link.exe, the old binutils ld, gold linker, etc.) and so on. Most of us aren't looking to replace any of that. Even if we are, the stuff coming along with Rust is probably not what we are looking for. Cargo is thus, to many of us, an unwelcome surprise.

StavrosK 6y ago
Your comment is very odd to me, it sounds like Rust is a version of C++ and you dislike them changing the tooling. Where did that assumption come from? I come from Python, and it would be ridiculous if I said "well we already have Poetry so why doesn't Rust just use that". I don't think saying the same thing about the C++ tooling is different.
- burfog 6y ago
  Python is not comparable. Rust is a natively-compiled systems language that supports the C language ABI. Python, Perl, Java, Lua, Ruby, Scheme, and other such things are expected to bring along some extra gunk. I'm not saying that this is good, but at least it is unsurprising. Rust needs to fit in with C, C++, Ada, Fortran, Pascal, and all the other natively-compiled systems languages. Using generic system-provided tools isn't just for C. You'd likely use a Makefile to compile Fortran. The idea is that the languages are interchangable parts with compatibility. You can create a project that uses a different systems language for each source file, run "make", and it all builds. There is no glue code, no interface definition language, no wrapper, no thunk, or anything of the sort. The expectation is just different. Nobody expects Python to cooperate with Lua or Ruby or Perl, with source files in different languages freely calling into each other. That is the expectation for natively-compiled systems languages.

by burfog 6y ago

StavrosK 6y ago

Your comment is very odd to me, it sounds like Rust is a version of C++ and you dislike them changing the tooling. Where did that assumption come from? I come from Python, and it would be ridiculous if I said "well we already have Poetry so why doesn't Rust just use that". I don't think saying the same thing about the C++ tooling is different.

burfog 6y ago
Python is not comparable. Rust is a natively-compiled systems language that supports the C language ABI. Python, Perl, Java, Lua, Ruby, Scheme, and other such things are expected to bring along some extra gunk. I'm not saying that this is good, but at least it is unsurprising. Rust needs to fit in with C, C++, Ada, Fortran, Pascal, and all the other natively-compiled systems languages. Using generic system-provided tools isn't just for C. You'd likely use a Makefile to compile Fortran. The idea is that the languages are interchangable parts with compatibility. You can create a project that uses a different systems language for each source file, run "make", and it all builds. There is no glue code, no interface definition language, no wrapper, no thunk, or anything of the sort. The expectation is just different. Nobody expects Python to cooperate with Lua or Ruby or Perl, with source files in different languages freely calling into each other. That is the expectation for natively-compiled systems languages.