Live data from Hacker News

Fish 4

github.com

71–80 of 113 posts

Re: Fish 4

#71

Earlier quoted context omitted.

Agreed. I would rather be forced to explicitly cover all match cases than accidentally run into problems that are hard to debug.

Exactly. I wish all languages implemented things like this, a bit more strictness (such as requiring all possible match cases to be handled across a set of inputs) goes a long way

Not all though. I am currently writing my own Lisp dialect, and as much as I wish and hope I will be able to force case/switch to be exhaustive, I don't see a direct way for that in a dynamically typed version.

I do plan to add something similar to Clojure's spec though, so the compiler can at least be advised about things and warning if stuff is missing.

But I do agree, any statically typed language should have that check and not just warn about it. It should be a hard error, no questions asked. And I love that Rust didn't relegate it to a warning that could be turned be into an error.

Re: Fish 4

#72

Earlier quoted context omitted.

the only vcs it supports is git

The —-vcs flag to cargo new supports git, hg, pijul, and fossil. It’s true that dependencies from a repository only supports git right now. Part of the issue there is just like, the VCS integration wasn’t don’t in a principled way (it happens!) and so it’s not simple. See here for more: https://github.com/rust-lang/cargo/issues/12102

no darcs?

and this is why i really loathe language package managers, because they're prone to this kind of thing. assuming one has no problems with the opinions made in a language itself, when it has a tightly bound package manager embedded into it's ecosystem (using rust without cargo is like pulling teeth) you have an entire extra hurdle of far more rigid and controversial opinions to deal with.

package managers are maybe next to shells with "it's several orders of magnitude harder to make a good one than it is to write a compiler." with the dozens, possibly hundreds of package managers i've touched over the years, there's only been one that i'd call "good". the absolute worst ones have always been language package managers. at this point i've basically written off the concept, even system package managers.

Re: Fish 4

#73
post #6

I've used Fish for many years, but frankly only for the great autocompletion. The streamlined theme/prompt system and oh-my-fish plugin management are quite nice too, but minor. The rest of Fish features that are not bash-compatible are rather a pain, particularly environment variable management. In principle these features have a better design than in bash, but not that much better, and their use is infrequent enoug…

What I truly appreciate is the completion system from a dev perspective. Writing completions is comfortable. Even wrapping completions into other completions is fairly clean (e.g. sudo {cmd}TAB).

Re: Fish 4

#74

Earlier quoted context omitted.

The —-vcs flag to cargo new supports git, hg, pijul, and fossil. It’s true that dependencies from a repository only supports git right now. Part of the issue there is just like, the VCS integration wasn’t don’t in a principled way (it happens!) and so it’s not simple. See here for more: https://github.com/rust-lang/cargo/issues/12102

no darcs? and this is why i really loathe language package managers, because they're prone to this kind of thing. assuming one has no problems with the opinions made in a language itself, when it has a tightly bound package manager embedded into it's ecosystem (using rust without cargo is like pulling teeth) you have an entire extra hurdle of far more rigid and controversial opinions to deal with. package managers ar…

I’m not sure I’ve ever heard of a Rust programmer using Darcs. Anyone likely to would use Pijul.

Re: Fish 4

#75

Earlier quoted context omitted.

Faster than previous C++? Only if there were actual performance bugs that they fixed while doing the port.

What makes you think so? The Rust compiler is able to instrument LLVM a lot better and provide it with a lot more info than C++ can. The borrow checker does a lot of the work there to for example keep things on the stack or do LSE or GSE and other optimizations. It isn't just about "oh, the rewrite allowed them to restructure things and optimize the algos". It is also that Rust due to its nature is able to be absolut…

Additionally, some people shared that they feel more comfortable making more aggressive optimizations in their Rust code because the borrow checker has their back.

Stylo was tried twice in C++ before the Rust attempt, and it never worked out, because the threading was too hard to get right. In theory you could have done it. But in theory, theory and practice are the same, but in practice, they’re different.

Re: Fish 4

#76
post #43

Earlier quoted context omitted.

[flagged]

Why would you care what it's written in at all, unless you plan to work on it yourself?

> Why would you care what it's written in at all

Well, actually, it was the OP who said, literally, that "the most interesting thing about Fish (...) will be that it is now written in Rust"

Re: Fish 4

#77

Earlier quoted context omitted.

no darcs? and this is why i really loathe language package managers, because they're prone to this kind of thing. assuming one has no problems with the opinions made in a language itself, when it has a tightly bound package manager embedded into it's ecosystem (using rust without cargo is like pulling teeth) you have an entire extra hurdle of far more rigid and controversial opinions to deal with. package managers ar…

I’m not sure I’ve ever heard of a Rust programmer using Darcs. Anyone likely to would use Pijul.

well that's the thing, you never know. certainly if i ever used rust to a serious degree, i'd not stop using darcs. however right now that'd necessitate bypassing the whole package management part of cargo, at least for my own libraries (and i suffer from a terminal case of NIH syndrome)

i don't think it's reasonable to assert that my own quirks and tastes are explicitly tended to. and that's why ideally you just give the programmer space to do whatever, hence why it's so hard. vcs is just one single point of contention. this isn't unique to rust by the way. cargo is arguably a bit better than the dune experience, it's a bit more flexible and feels simpler.

arguably system package managers are better here, since they're effectively opt-in by choosing what distribution of what operating system you use. language package managers don't have that luxury.

Re: Fish 4

#78
post #12

Earlier quoted context omitted.

Rust, IMO is a noisy language. So not surprising it took more lines. Having to handle every case of every branch also probably balloons line count. Efficient LOC is not a goal of rust at all anyway.

Efficient LOC shouldn't be a goal or metric anyway, readability trumps conciseness... except when conciseness improves readability.

If conciseness improves readability then doesn't readability still win?

Re: Fish 4

#79

Let's guess which one compiles slower

On my Macbook M1 Pro: - fish 4.0.0 / Rust: (cargo build): 16 seconds - fish 4.0.0 / Rust: (cargo build --release): 37 seconds - fish 3.7.1 / C++: cmake ..: 10 seconds + make -j8: 13 seconds = 23 seconds So yeah, C++ was slightly faster in release mode, but slower in non-release. I'd say this is yet another win for Rust, frankly.

CMake + Ninja?

Re: Fish 4

#80
post #6

I've used Fish for many years, but frankly only for the great autocompletion. The streamlined theme/prompt system and oh-my-fish plugin management are quite nice too, but minor. The rest of Fish features that are not bash-compatible are rather a pain, particularly environment variable management. In principle these features have a better design than in bash, but not that much better, and their use is infrequent enoug…

It's the opposite for me; things that are intuitive in Fish would involve inscrutable magic incantations copied from StackOverflow in Bash. If you only want to use Fish for the autocompletion though, you can! Bash is always still there alongside Fish, you can just open a Bash shell when you're copypasting instructions, or `bash $SCRIPT` any scripts.

That's fair, and that's why I'm happy to keep using Fish. I suppose that I'd just prefer a leaner package and more focus on core features, but it's still my preferred option.

It's just that I never find myself needing to do anything fancy in the command line. I just want it to be fast, ergonomic, beautiful and unobtrusive.

And I wouldn't say it's because my workload is any simpler, I'm a relatively senior computer engineer working on large-scale data engineering, LLMs, non-trivial webdev and some systems programming in Rust. And it's not because I use UIs more often either, I use the command-line as much as anyone.

I guess that I have more of a "RISC" approach to the command-line.

Post reply on HN