5 ms·

So, what new features do we get from that? Except that it doesn't work on Windows any more?

by exxos 3y ago

jenadine 3y ago
Never worked on Windows. The programming language has nothing to do with that anyway.
- exxos 3y ago
  It does. With Go, it would have worked out of the box on all the targets Go can support.
  - Cu3PO42 3y ago
    > It does. It works in Cygwin right now, it doesn't work on Win32 without a compatibility layer. Personally, I don't think of that as "working on Windows", but I concede that that's somewhat up to interpretation on the "on Windows" part. I'm confident that someone is going to get a MingW build working even if it's not official. > With Go, it would have worked out of the box on all the targets Go can support. That's absolutely disingenious. If you choose to only use the Go standard library , sure. But the same is true for Rust and even for C++. If you don't use any platform-specific APIs most languages will work on any target. Fish, however, does use platform-specific APIs and nothing about Go changes that.
  - dymk 3y ago
    unless you have to deal with OS specific APIs around process management and tty input, which is the bulk of what makes a shell challenging to implement
  - Volundr 3y ago
    As long as you called no platform specific APIs. The same is true of Rust and many (even most) languages. Go isn't magic here.
- speed_spread 3y ago
  fish.exe works on Windows just fine if you install it as part of MSYS2, which I prefer anyway to the kludge that is WSL.
  - sedatk 3y ago
    Why do you think WSL (WSL2 I presume) is a kludge?
    - speed_spread 3y ago
      It's an OS inside an OS, you have to setup everything twice (Windows AND Linux) and file system access times always bites you one way or another (with WSL2 it's the IDE on Windows that suffers from accessing the Linux FS). Because it's in a container, localhost does not get resolved to the Windows host, so if you have stuff that's spread across both OS it's also annoying. Also has weird issues with corporate VPNs. And the other day switching to fish shell as default would just freeze the whole container with no way to debug it, WTF? Unlike a real Linux env, it's a black box, if it starts acting weird your best bet is just to trash and recreate it. I mean, it works and gives a somewhat decent Linux CLI experience but personally I stick with MSYS2 whenever I can so I have a single env to deal with.
      - Matumio 3y ago
        I didn't believe all the hate until I watched someone unfamiliar with Linux set up an empty Electron project in WSL. After we hit the third "Linux"-bug that turned out to only happen in WSL, I suggested to maybe just install Linux in a normal VM. Clunky, yes. But at least it has a clear boundary. Unless you move something across it, everything will just work.

So, what new features do we get from that? Except that it doesn't work on Windows any more?

by exxos 3y ago

So, what new features do we get from that? Except that it doesn't work on Windows any more?

jenadine 3y ago

Never worked on Windows. The programming language has nothing to do with that anyway.

exxos 3y ago
It does. With Go, it would have worked out of the box on all the targets Go can support.
- Cu3PO42 3y ago
  > It does. It works in Cygwin right now, it doesn't work on Win32 without a compatibility layer. Personally, I don't think of that as "working on Windows", but I concede that that's somewhat up to interpretation on the "on Windows" part. I'm confident that someone is going to get a MingW build working even if it's not official. > With Go, it would have worked out of the box on all the targets Go can support. That's absolutely disingenious. If you choose to only use the Go standard library , sure. But the same is true for Rust and even for C++. If you don't use any platform-specific APIs most languages will work on any target. Fish, however, does use platform-specific APIs and nothing about Go changes that.
- dymk 3y ago
  unless you have to deal with OS specific APIs around process management and tty input, which is the bulk of what makes a shell challenging to implement
- Volundr 3y ago
  As long as you called no platform specific APIs. The same is true of Rust and many (even most) languages. Go isn't magic here.
speed_spread 3y ago
fish.exe works on Windows just fine if you install it as part of MSYS2, which I prefer anyway to the kludge that is WSL.
- sedatk 3y ago
  Why do you think WSL (WSL2 I presume) is a kludge?
  - speed_spread 3y ago
    It's an OS inside an OS, you have to setup everything twice (Windows AND Linux) and file system access times always bites you one way or another (with WSL2 it's the IDE on Windows that suffers from accessing the Linux FS). Because it's in a container, localhost does not get resolved to the Windows host, so if you have stuff that's spread across both OS it's also annoying. Also has weird issues with corporate VPNs. And the other day switching to fish shell as default would just freeze the whole container with no way to debug it, WTF? Unlike a real Linux env, it's a black box, if it starts acting weird your best bet is just to trash and recreate it. I mean, it works and gives a somewhat decent Linux CLI experience but personally I stick with MSYS2 whenever I can so I have a single env to deal with.
    - Matumio 3y ago
      I didn't believe all the hate until I watched someone unfamiliar with Linux set up an empty Electron project in WSL. After we hit the third "Linux"-bug that turned out to only happen in WSL, I suggested to maybe just install Linux in a normal VM. Clunky, yes. But at least it has a clear boundary. Unless you move something across it, everything will just work.