Fish 4

According to the blog post (https://fishshell.com/blog/rustport/#fn:formatting):

> A lot of the increase in line count can be explained by rustfmt’s formatting, as it likes to spread code out over multiple lines [...] The rest is additional features. Also note that our Rust code is in some places a straight translation of the C++, and fully idiomatic Rust might be shorter.

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.

Rust code defenitely takes more space with default formatter settings if you use functional paradigms. Every chained function call in many cases is one extra line. Default line width is not much anyway. Also if you handle all return types, lines will add up.

Since there are quite many contributors, it can be difficult to introduce some advanced macro requirements for the project, which could reduce the code.

Beyond what others have said about superficial things like laying out code differently, remember that Rust encodes memory-safety-related information in types, function signatures etc that might not exist at all in a C/C++ "we hope you do it right, or it's UB" codebase.

Also, here's a code size tracker that counts tokens not lines, which is a better measure: https://github.com/rrethy/tcount

First experiences with QEMU suggest ~10% more lines of code.

Not surprising to me. While learning Rust, I rewrote in Rust several existing programs I had written in C++ and all of them were longer with default formatting.

It’s broadly the same speed currently, but the goal was always to do a simple port to start with, then iterate from there.

Anecdote time: I did a test like this with a small hobby project of mine (c++). I ported it to rust and saw roughly a 25% speed increase because of some refactorings I was meaning to do for a long time. I then ported the rust code back to c++ and saw another 15% gain in performance. Backporting the changes to rust again yielded no significant difference.

I am no rust programmer though, and I don't think the rust code was very idiomatic.

But then again I apparently write c++ like a common lisp programmer...

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

In what way does fish being built with cargo affect you as (not even) a user? Were you fish-curious in that you were interested in becoming a contributor? Or do you make a habit of judging projects that you might be interested in using based primarily on their build system?

I dont like lisp but hackernews is still fine to browse?

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

What does it matter which tool-chain they use . I can understand if the difference is it made it notably slower or they dropped some features because they couldn't get it done in rust . But purely as an end user why would it matter if it's written in rust or cpp ?

What do you dislike about it?

Everyone is entitled to opinions of course, but this is a rather weird one given how Rust's toolchain is the thing most people like most about it.

https://xkcd.com/1172/

There's a nice way to halfway-fix that issue. It makes use of the fact that most bash commands that we copy are prefixed with a $ and a space. It also requires your terminal emulator to have a way to hook into the paste mechanism and edit the to-be-pasted text. To my knowledge, Kitty and iTerm both have this feature.

Basically, the terminal will replace each line of the pasted text that match (start with)

  $ rest

  pbash 'rest_escaped'

  \$ 'rest_escaped'

This function will start (if not exists) a persistent background bash instance connected on both ends to FIFOs, with the same lifetime as your fish session. We then pass the `rest_escaped` to one FIFO, capture the output from the other FIFO, and echo it.

Because its a persistent session, stuff you copy that makes use of variables or bash aliases all Just Work. Being able to blindly copy-paste the entire bash codefence from a github readme.md is especially nice.

It all happens automatically after a one-time setup, and overall works pretty well for me. Here is a demo: https://i.imgur.com/HdqGkRk.png

This is the fish function

  function \$
      if not test -f /tmp/bash_daemon.pid; or not kill -0 (cat /tmp/bash_daemon.pid) 2>/dev/null
          echo "Starting bash daemon..."
          bash ~/scripts/bash_daemon.sh &
          sleep 0.5
      end
  
      echo "$argv" > /tmp/bash_daemon_pipe &
  
      while read -l line
          if test "$line" = "###DONE###"
              break
          end
  
          echo $line
      end < /tmp/bash_daemon_out
  end

  #! /usr/bin/env bash
  
  rm -f /tmp/bash_daemon_pipe /tmp/bash_daemon_out
  mkfifo /tmp/bash_daemon_pipe
  mkfifo /tmp/bash_daemon_out
  
  echo $$ > /tmp/bash_daemon.pid
  
  while true; do
      read cmd < /tmp/bash_daemon_pipe
      { eval "$cmd"; echo "###DONE###"; } > /tmp/bash_daemon_out
  done

That's fair but having a package manager manage all your dependencies makes maintenance and hygiene easier.

Yup.

Have you read Jef Raskin's The Humane Interface? It's an explainer and retrospective for his Canon Cat.

I want more of that foundation, vision, concept.

With the recent renewed interest textual user interfaces (TUIs), maybe this cycle we'll tact a little closer to that utopian future perfect omni-shell.

https://en.wikipedia.org/wiki/The_Humane_Interface

https://en.wikipedia.org/wiki/Canon_Cat

https://en.wikipedia.org/wiki/Jef_Raskin#Pioneering_the_info...

--

And another thing (I say curmudgeonly)...

bash (and csh), the progenator of all modern shells, is just one realization.

Iteration and refinement are double awesome. We're seeing crazy awesome new variants, like Warp.app, oil shell, fish, and so forth. Yea for evolution!

But I would also hope today's youngsters take a moment to review the genesis of all the modern ideas we now take for granted. From memory, in no particular order:

  Engelbart's Mother of All Demos
  Raskin's original vision for Macintosh
  Nelson's Xanadu
  Higgins art philosophy of "intermedia"
  Xerox PARC
  cybernetics
  Atkinson's HyperCard
  etc.

With 60+ years of progress and gestation, surely there are even more tangents worth exploring.

It’s actually fish that has that tagline :)

Most people reading this didn't experience FoxPro DOS probably. Why not say more?

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.

Generative AI might be able to generate them, but it's still on you to understand the result and check that it indeed does what you want. And with the sometimes very nuance- or foot-gun-rich syntax of bash, that's rather a significant burden, if you're not familiar enough with the syntax to write the script yourself in the first place.

Speak for yourself, but I would not want to be beholden to AI for every trivial shell one-liner. "Sorry boss, ChatGPT is down, I can't count how many *.txt files are in this directory. See you tomorrow!"

I'll take the better syntax, thanks.

Scripting languages are so dynamic, flexible, arcane, and subtle and the consequences for getting scripts wrong are so potentially catastrophic for a system that they are absolutely the last thing I would ever dare generate via LLM.

When you don't use it all the time it's impossible to remember what all the flags are for. The names/scopes are also not helpful, I usually want universal, but think I want global because I don't remember there is a universal. And the thing I have to look up every time is how to set a variable for the current line.

I'm not saying these are hard things, to figure out. I just agree that they're hard to remember when you don't use them all the time.

Nice!