5 ms·

Honestly I don't like the build process of most go/rust/javascript software any better than C++. It's harder to find the dependencies for building the latter,

by lucb1e 5y ago

Honestly I don't like the build process of most go/rust/javascript software any better than C++. It's harder to find the dependencies for building the latter, but the former has its own version of dependency hell. I have real trouble building both types of projects, though admittedly (especially when the building instructions don't work when followed to the letter) C++ a bit more than the strategy of "everything is just pulled from github, you only have to make sure you've got gigabytes of free space in ~/.cache/, a build environment that was released in the past four to nine days, and have appropriate isolation or simply not care about potentially vulnerable or compromised code being run on your system". On a rare occasion, I will find a nice and small program using only standard libraries that compiles simply with `cc my.c && ./a.out` or runs simply with `python3 my.py`, demonstrating it doesn't depend on the language to have an easy time building it, but in both categories it's the exception for some reason. I see so much software that needs only standard libraries and runs on literally any python version released in the last decade, but to run it you have to setup some environment or globally install it with setuptools or something.

throwaway894345 5y ago
> everything is just pulled from github I hear this a lot, but I can't divine any substance from it. Why is GitHub a less-secure repository medium than SourceForge + random website downloads + various Linux package managers? Maybe this is a red herring and your real complaint is that the Rust ecosystem is less secure than the C/++ ecosystem? > you only have to make sure you've got gigabytes of free space in ~/.cache/ I cleared my $GOCACHE relatively recently (I thought maybe I had a cache issue, but I was mistaken), but it's currently at 75M while my .cargo directory weighs 704M. If these ever really got too big I would just `go clean -cache` and move on with life. If this is one of the biggest issues with Go/Rust/etc then I think you're arguing my point for me. > a build environment that was released in the past four to nine days What does this even mean? You can compile Go or Rust programs on any Linux machine with the build tools. On the contrary, C/C++ dependencies are very tightly coupled to the build environment. > have appropriate isolation or simply not care about potentially vulnerable or compromised code being run on your system Not sure about Rust programs, but Go programs absolutely don't run arbitrary code at compile/install time. C programs on the other hand absolutely do run arbitrary code (e.g., CMake scripts, Makefiles, random bash scripts, etc). > I see so much software that needs only standard libraries and runs on literally any python version released in the last decade, but to run it you have to setup some environment or globally install it with setuptools or something. Yeah, Python package management is a trashfire; however, this is entirely because it is so tightly coupled to C dependencies (many Python libraries are thin wrappers around various C programs, each with their own bespoke build system). Python package management tries to paper over the universe of C packages and it kind of works as long as you're on a handful of well-supported distributions and your dependencies have been well-vetted and well-maintained.
- dmz73 5y ago
  I don't think the exact URL is the problem, it is the fact that it is so easy to include dependencies from external repository that is the problem. In Rust every non-trivial library pulls in 10s or even 100s of dependencies. I don't think anyone can expect that all of these libraries are of good quality but how would one even try to verify that? And you have to verify it every time you update your project. Then there is the issue of licencing - how to verify that I am not using some library in violation of its licence and what happens if the licence changes down the road and I don't notice it because I am implicitly using 500 dependencies due to my 3 main libraries? Rust and Go have solved memory safety compared to C and C++ but have introduced dependency hell of yet unknown proportions. Python and other dynamically typed languages are in a league of their own in that on top of the dependency hell they also do not provide compiler checks that would allow user to see the problem before the exact conditions occur at runtime. They are good for scripting but people keep pumping out full applications and to be honest there is not much difference between giant Python application, giant maze of Excel VBA and giant Node.js heap of code. Of those, Excel VBA is most likely to work for 5 years and across 5 versions of the product yet it is also the most likely one to receive the most negative comments.
  - throwaway894345 5y ago
    > I don't think the exact URL is the problem, it is the fact that it is so easy to include dependencies from external repository that is the problem. In Rust every non-trivial library pulls in 10s or even 100s of dependencies. But it's also quite a lot easier to audit those dependencies, even automatically (incidentally, GitHub provides dependency scanning for free for many languages). > Then there is the issue of licencing - how to verify that I am not using some library in violation of its licence and what happens if the licence changes down the road and I don't notice it because I am implicitly using 500 dependencies due to my 3 main libraries? This is also an automated task. For example, https://github.com/google/go-licenses https://github.com/google/go-licenses: "go-licenses analyzes the dependency tree of a Go package/binary. It can output a report on the libraries used and under what license they can be used. It can also collect all of the license documents, copyright notices and source code into a directory in order to comply with license terms on redistribution." > Rust and Go have solved memory safety compared to C and C++ but have introduced dependency hell of yet unknown proportions. I mean, it's been a decade and things seem to be going pretty well. Also, I don't think anyone who has actually used these languages seriously has ever characterized their dependency management as "dependency hell"; however, lots of people talk about the "dependency hell" of managing C and C++ dependencies. > Python and other dynamically typed languages are in a league of their own in that on top of the dependency hell they also do not provide compiler checks that would allow user to see the problem before the exact conditions occur at runtime. I won't argue with you there.
steveklabnik 5y ago
To be clear, Cargo doesn’t pull code from GitHub.

by lucb1e 5y ago

throwaway894345 5y ago

> everything is just pulled from github I hear this a lot, but I can't divine any substance from it. Why is GitHub a less-secure repository medium than SourceForge + random website downloads + various Linux package managers? Maybe this is a red herring and your real complaint is that the Rust ecosystem is less secure than the C/++ ecosystem? > you only have to make sure you've got gigabytes of free space in ~/.cache/ I cleared my $GOCACHE relatively recently (I thought maybe I had a cache issue, but I was mistaken), but it's currently at 75M while my .cargo directory weighs 704M. If these ever really got too big I would just `go clean -cache` and move on with life. If this is one of the biggest issues with Go/Rust/etc then I think you're arguing my point for me. > a build environment that was released in the past four to nine days What does this even mean? You can compile Go or Rust programs on any Linux machine with the build tools. On the contrary, C/C++ dependencies are very tightly coupled to the build environment. > have appropriate isolation or simply not care about potentially vulnerable or compromised code being run on your system Not sure about Rust programs, but Go programs absolutely don't run arbitrary code at compile/install time. C programs on the other hand absolutely do run arbitrary code (e.g., CMake scripts, Makefiles, random bash scripts, etc). > I see so much software that needs only standard libraries and runs on literally any python version released in the last decade, but to run it you have to setup some environment or globally install it with setuptools or something. Yeah, Python package management is a trashfire; however, this is entirely because it is so tightly coupled to C dependencies (many Python libraries are thin wrappers around various C programs, each with their own bespoke build system). Python package management tries to paper over the universe of C packages and it kind of works as long as you're on a handful of well-supported distributions and your dependencies have been well-vetted and well-maintained.

dmz73 5y ago
I don't think the exact URL is the problem, it is the fact that it is so easy to include dependencies from external repository that is the problem. In Rust every non-trivial library pulls in 10s or even 100s of dependencies. I don't think anyone can expect that all of these libraries are of good quality but how would one even try to verify that? And you have to verify it every time you update your project. Then there is the issue of licencing - how to verify that I am not using some library in violation of its licence and what happens if the licence changes down the road and I don't notice it because I am implicitly using 500 dependencies due to my 3 main libraries? Rust and Go have solved memory safety compared to C and C++ but have introduced dependency hell of yet unknown proportions. Python and other dynamically typed languages are in a league of their own in that on top of the dependency hell they also do not provide compiler checks that would allow user to see the problem before the exact conditions occur at runtime. They are good for scripting but people keep pumping out full applications and to be honest there is not much difference between giant Python application, giant maze of Excel VBA and giant Node.js heap of code. Of those, Excel VBA is most likely to work for 5 years and across 5 versions of the product yet it is also the most likely one to receive the most negative comments.
- throwaway894345 5y ago
  > I don't think the exact URL is the problem, it is the fact that it is so easy to include dependencies from external repository that is the problem. In Rust every non-trivial library pulls in 10s or even 100s of dependencies. But it's also quite a lot easier to audit those dependencies, even automatically (incidentally, GitHub provides dependency scanning for free for many languages). > Then there is the issue of licencing - how to verify that I am not using some library in violation of its licence and what happens if the licence changes down the road and I don't notice it because I am implicitly using 500 dependencies due to my 3 main libraries? This is also an automated task. For example, https://github.com/google/go-licenses https://github.com/google/go-licenses: "go-licenses analyzes the dependency tree of a Go package/binary. It can output a report on the libraries used and under what license they can be used. It can also collect all of the license documents, copyright notices and source code into a directory in order to comply with license terms on redistribution." > Rust and Go have solved memory safety compared to C and C++ but have introduced dependency hell of yet unknown proportions. I mean, it's been a decade and things seem to be going pretty well. Also, I don't think anyone who has actually used these languages seriously has ever characterized their dependency management as "dependency hell"; however, lots of people talk about the "dependency hell" of managing C and C++ dependencies. > Python and other dynamically typed languages are in a league of their own in that on top of the dependency hell they also do not provide compiler checks that would allow user to see the problem before the exact conditions occur at runtime. I won't argue with you there.

steveklabnik 5y ago

To be clear, Cargo doesn’t pull code from GitHub.