271–280 of 411 posts
I use this in combination with fish shell and it's been working really well. I can just switch over to `nu` when the task merits; no need to replace my current shell. I can also just run a one-off line like this. nu -c "ls | where size > 10b"
Earlier quoted context omitted.
40 years is a long time, so the experience will almost certainly degrade a fair bit. The notion of editions in rust makes allowances for breaking changes while still keeping backwards compatibility, I'm very curious to see whether the problems that solves outweigh the complexity in the compiler.
The design of editions is such to specifically reduce implementation complexity in the compiler, for this reason. The majority of the compiler is edition-agnostic. It’s not the only reason, but it’s a big one.
My specific concern there is that, while the compiler frontend for any one given edition becomes individually simpler, the whole compiler becomes a bit more complicated, and things like IntoIterator, which pjmlp mentioned elsewhere, imply changes across several editions.
This is not a major problem when editions means {2015, 2018, 2021}, but in a world where we also have 2024, 2027, ... editions, this becomes increasingly tricky.
We would be able to use standard pipelines and jq to filter/query outputs, without any custom shells.
Just imagine:
ifconfig --json | jq '.[] | [.interface, .inet] | @tsv'Earlier quoted context omitted.
is the writing part really what we should focus on in scripting though? i personally would've put much more weight into the ease of reading and understanding the code. personally, i think that PS just came too late, so most people (me included) are too used to the way the unix shell works/feels. It would have to be just straight up better in all regards to displace it, but its more like a different flavor entirely. I…
I think bash is only readable because pretty much everyone is already familiar with the syntax. Given someone with no experience, they would probably have more success understanding what a Powershell script is doing.
I'm getting confused here, Isn't that literally what I said?
Earlier quoted context omitted.
I find cut easier to use than remembering awk syntax. So I get where you're coming from, but it's just a tad disingenuous don't you think? Especially since `free` `man free` is definitely easier to remember than Get-Whateverfunctioncall is
Is it easier? Because I would expect man free to go to the C stdlib.h definition. You’re just familiar with the former and not the latter currently.
It's just an overall bad argument. I don't see how `Get-CimInstance -Class Win32_OperatingSystem` is in any way memorable
Thinking this is so cool! I was wondering if seriously buying into an alternate shell like this would be worth it in the long run. Would really love to read from people who use(d) an alternative shell, both success and failure stories. I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work beca…
A few years back I did a startup with a friend -- a cross platform mobile product but with a mess of complex open-source c++ dependencies (which we forked and customized often) -- and we made the decision as we hired developers to over-specify some aspects of the machine environment to make it as easy as possible to share our development workflows. Note that "development workflow" is much more than just "i can run the app in docker" -- but rightfully includes -- I can efficiently run things in debugger, I can run the performance profiling tools in realistic ways, I can quickly execute and test a change someone else is trying to make, I can quickly share a change I'm making with someone else and be confident they can make realistic observations about it, i can setup a fast repro loop for some specific bug or feature ... etc.
We did a pretty good job of getting the know now needed for all those workflows distributed across the team reliably with low effort despite some complicated and weird build system requirements associated with our dependencies.
One of the big bang for buck tricks that helped more than I would've expected was to mandate that everyone had to use fish shell. This really reduces the number of weird effects from random things that people copy/paste into their bash initialization -- with the developer never imagining the strange knock off effects that will one day cause a tool they don't understand to behave in a flaky way for a reason they will never figure out ...
The amount of terrible things that developers randomly accumulate in their bash initialization probably can't be underestimated ... there's probably more risk of "weird problems" associated with advice on stack overflow related to bash initialization than maybe any other topic ...
So I personally think standardizing a team or startup on an alt shell can be a potentially good idea ...
As another point of evidence -- I later headed devops at another startup that took opposite perspective -- "use your own machine and your machine can be configured however you want and you just have to figure out dev workflows on your own" and it was extremely difficult to share knowledge about how to accomplish a lot of these basic workflows ... doing anything beyond the most basic ways of interacting with the codebase often involved a rather large amount of hands on dev machine troubleshooting (can you send me your .bashrc and .profile and .bash_profile? ok type these commands ... ok now you can grab my branch and try this to have a look at the thing i'm trying to change ...)
fish is reliable and stable though -- I'm not sure about using a shell that's not been around for awhile in this way ... but I'd support it I think if I already had personal experience that the shell was "reliable enough" ...
Earlier quoted context omitted.
The design of editions is such to specifically reduce implementation complexity in the compiler, for this reason. The majority of the compiler is edition-agnostic. It’s not the only reason, but it’s a big one.
Could you expand upon this? My specific concern there is that, while the compiler frontend for any one given edition becomes individually simpler, the whole compiler becomes a bit more complicated, and things like IntoIterator, which pjmlp mentioned elsewhere, imply changes across several editions. This is not a major problem when editions means {2015, 2018, 2021}, but in a world where we also have 2024, 2027, ... ed…
… I don’t know how to say this truly politely, but let’s just say I’ve had a few conversations with pjmlp about editions, and I would take the things he says on this topic with a large grain of salt.
Thinking this is so cool! I was wondering if seriously buying into an alternate shell like this would be worth it in the long run. Would really love to read from people who use(d) an alternative shell, both success and failure stories. I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work beca…
[0] https://xon.sh
Thinking this is so cool! I was wondering if seriously buying into an alternate shell like this would be worth it in the long run. Would really love to read from people who use(d) an alternative shell, both success and failure stories. I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work beca…
I've been using Xonsh[0] for a couple years as my daily driver and I swear by it. I'm also a Python dev so that's part of the appeal. It's billed as the "unholy union" of Bash and Python. [0] https://xon.sh