On Jun 15, 2018, at 10:26 AM, Mark Gardner <m...@vt.edu> wrote: > I'm cool with Python. When I am not programming in Go, I am programming in > Python. It seems to be installed by default on all the Linux systems lately. > I am no longer so fond of perl, which is strange to say as I have done some > fairly big programs in perl. I found that it gets very obtuse when you need > to start creating nested data structures or use objects. Once upon a time, > perl with the the big thing. The momentum seems to have swung towards Python > these days.
Speaking as one of the guys who has been a member of the team supporting postmas...@python.org since 2003, the problem with Python as a programming language today remains the split between Python 2.x and 3.x, and how many systems are still in active use with an ancient version of the language installed as part of the system. If you can write your code in such a way that it doesn't matter what version of Python you're using, then that's fine. But that's also a very tall ask. > I think you are conflating the dependencies that need to be installed to > build a compiled tool from the dependencies to install and use the tool. > Since most people install packages via their package manager, the former is > not much of an issue in my opinion. I agree that I don't want to have to tons > of separate libraries installed with the tool. I don't want to have to pull in a lot of additional dependencies in order to support a tool -- any tool. The simpler and more self-sufficient you can make/keep the tool in question, the better. > Don't know about Rust but installing a Go-based pass would be no different > than the current version. It would be just a single executable plus stuff > like examples and docs. The code would be written to check for optional > dependencies, such as git, and only use them if found. Just like the current > pass. If the code is written in go, then it has to be compiled to run on the hardware in question. I don't want to have to compile code, either. Moreover, once you have a binary that is separate from the source code, you can no longer guarantee the behaviour of the binary and that it really does correspond to the source code that may have been validated. Keeping It Simple, Silly + There Is No Compiler = Bash plus very few other options. So, KISS and TINC, please. Beyond that, I'm not too wedded to the language. But if you do want to keep it in Bash, here are tools out there that can help make that Bash code robust and pretty safe. -- Brad Knowles <b...@shub-internet.org>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Password-Store mailing list Password-Store@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/password-store
