The Slow March of Progress in Programming Language Tooling

• nushell

  212 29,963 9.9 Rust

  A new type of shell

  

> However, the little experience I have indicates that Windows is fundamentally worse.

Fundamentally worse is extremely hard to prove and subjective. It's different, that's for sure.

> For instance, the file handle issue is clearly annoying when developing. You may be used to it, but I don’t see an argument on how Windows’ handling of files is better or even equal.

That's one of the things that's arguably worse in the modern era, I'm quite sure it comes from CP/M (1974) so it's a super ancient decision, one that would break a lot of things if they change it. It's one of "go left or right, but you can't go back, and you'll only find out in 20 years if you made the right choice".

> Or take Poweshell. The *nix approach of composable shell primitives is better for developers. Software development is the composition of primitives after all.

That's ironic, since Powershell is super composable. If anything, it's even more composable since it sends structured data not just raw streams of bytes. There's a reason a ton of alternative shells want to evolve POSIX shells to add structured data, they're all inspired by Powershell. See for example https://www.nushell.sh/

> Google “run on system start linux api” and the first result is about systemd. Create a config file, put it in the right place, and done.

Unless you want to use Gentoo or Devuan or FreeBSD or... And amusingly, systemd is inspired by MacOS and Windows service management (parts of them) plus it actually tries to create the unified userland that's inspired by... Windows :-)

> If you learn on Windows first, or if you’re a masochist, then I’m sure it’s possible to tolerate or even enjoy Windows development. But I have never seen a convincing argument that it’s better or even on par with Linux development.

If we're professionals, we use what's available and we learn stuff from it.

I wouldn't say Windows is better, but it's definitely a lot better than strictly POSIX users complain about it, and it can be made super usable and more POSIX oriented. I've done it with Cygwin circa 2008 and I've been happily using the same setup since then.

For example in terms of desktop/laptop support, on average, Windows still fares better than Linux.

• pdoc

  10 1,813 8.2 Python

  API Documentation for Python Projects

  

RE browser vs reading the code: sounds like you have a nicer setup than my neovim setup. Although I think my first point still holds unless CLion handles that case too.

With respect to the rest of your comment, indeed, those are issues. Although I think I take issue with you pinning this on rustdoc. I actually think it's a dance between documentation presentation (so, rustdoc), API design and familiarity with the language.

I've long said that rustdoc makes unknown unknowns difficult to discover, and this is particularly painful for folks new to Rust. Because you don't really know what to look for yet. And writing docs is a difficult exercise in perspective taking, where you need to balance what you think others know. If you assume they know too little, it's not hard to end up writing too much and adding a fair bit of noise. With that said, I agree that "too little docs" is a far more common problem than "too many docs."

But yeah, your experience is a perfect example of what I mean when I say "generics complicate APIs." They introduce indirection everywhere, and I'm not sure how much rustdoc can really help with that. You might be right that maybe there are some visualizations that can be added, but like you, I've always seen those as gimmicks in other tools that are rarely useful. IMO, a heavily generic API really requires the crate author to write more prose about how their APIs are intended to be used with lots of concrete examples.

The interesting bit here is that I've personally found the documentation experience in Rust to be far far better than any other ecosystem. All the way from writing docs up to consuming them. I've sampled many different ecosystems (C, C++, Haskell, Python, Go to name some) and other than maybe Go, I thought the doc experience was really just not great in any of them. Python specifically seems to be a case where I tend to see a lot of variance in opinion. I hated Sphinx so much, for example, that I built an alternative.[1] I also just generally dislike the output that Sphinx produces. I find that it lacks structure, and I've always had a hard time navigating my way through Python library docs.

[1]: https://github.com/mitmproxy/pdoc

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

Suggest a related project