I switched from Zsh to Nushell almost two years ago and I have never looked back. If you need POSIX compliance, Nushell is a no go. But it sounds like your real problem was just that Zsh was familiar whereas fish was not. Nushell strikes the perfect balance of offering the commands you’re used to but letting everything just make intuitive sense. Plus, its help command is so far above and beyond other shells. I rarely need to open the Nushell docs (even though they’re really good), and I never have to go the community (even though it’s awesome), because I can figure pretty much everything out just from interacting help within the terminal.

More specifically, he argued (and the recent and upcoming releases of most major frameworks agree) that rendering most content on the server with islands of client-side interactivity is the future.

That’s not necessarily a huge revelation, but the big difference from what people have been doing with PHP for decades is the level of integration and simplicity in mixing server-side and client-side code seamlessly so that a dev can choose the appropriate thing in each context and not have to go through a lot of effort when requirements change or scaling becomes an issue. I would say that this represents a new level of maturity in the “modern” web frameworks where devs can choose the right technology for every problem to serve their users best.

I think you would be pleasantly surprised by the direction web dev is moving if you gave it a chance.

For example, I suspect that you think one of the ways the web has gotten shittier is because sites are too bloated and JavaScript frameworks are too heavy and slow.

One of the key takeaways is that, across almost all frameworks and stacks, web dev is moving back to doing as much work on the server-side as possible, while retaining the minimum necessary interactivity via Islands of Interactivity with much lighter JavaScript than what was pushed for the last decade.

Have you tried developing a GUI app for Windows in the last 5 years? All the official first-party frameworks are either mostly deprecated (WPF, WinForms), or half-baked and despised by every developer I’ve talked to about them (MAUI).

I’ll stick with nushell for terminal-first data interactions.

I think the point is that they don’t want to have to use a full JS framework (which is what HTMX is) for this behavior.

And this is where HTMX fits in. It’s an elegant and powerful solution to the front-end/back-end split, allowing more of the control logic to operate on the back-end while dynamically loading HTML into their respective places on the front-end.

But for a tech-luddite like me, this was still a bit too much. All I really want to do is swap page fragments using something like AJAX while sticking to semantically correct HTML.

EDIT: Put another way, if you look at HTMX’s "motivation"s:

motivation

• Why should only <a> & <form> be able to make HTTP requests?
• Why should only click & submit events trigger them?
• Why should only GET & POST methods be available?
• Why should you only be able to replace the entire screen?

By removing these constraints, htmx completes HTML as a hypertext

It seems the author only cares about the final bullet, and thinks the first three are reasonable/acceptable limitations.

If you dig the structured output of powershell, you might want to check out Nushell. It’s a cross-platform shell that builds on powershell’s structured data approach but is much less verbose and, in my opinion, more intuitive than both powershell and Posix shells.

I mean yes, but also the idea is that the user of serverless doesn’t have to configure, provision, maintain, etc. any server. You as the user just provide the code, and their platform handles running it on a server when needed.

There are several things I disagree with in this article, although I see where the author is coming from. I will never be onboard with “I’ll take my segfaults and buffer overflows.”, and I fundamentally disagree about concurrency. I also think that cargo is fantastic, and a lack of standard build tools is one thing that holds rust’s predecessors back.

However, a majority of the authors points can be boiled down to “C is more mature”, which doesn’t tell us much about the long-term viability and value of these languages. For example, in the author’s metric of stability and complexity, they use C99 as the baseline, but C99 is the state of a language that had already had almost 3 decades of development, whereas Rust has been stable for less than a decade. Talking about superior portability, stability, and even spec, implementations, and ABI is in some real sense just saying “C is older”.

That’s not to say those things aren’t valuable, but rather they aren’t immutable characteristics of either language. And given that safety is playing an ever more important role in software, especially systems software, I think Rust will catch up in all the ways that are meaningful for real projects more quickly than most of us realize. I certainly don’t think it’s going anywhere anytime soon.

Nushell is so great! I’ve been using it for a couple years. It has completely replaced my need for tools like grep, sed, awk, etc. and because it handles JSON and so many other data formats natively I rarely even need to think about parsing.

If I had to guess the motivation, it would probably be that:

• Rust is a systems language known for performance and correctness, which makes it a good candidate for their stated goal of having a competitor to encourage performance and correctness within Prettier
• Rust is popular and relatively well-known among open source developers, more so than any comparable language except maybe Go
• Rust is a hip language that probably added some free publicity to their announcement

It’s not just a proposal, it’s already fully defined and almost completely implemented - I believe they’re just waiting on a standards update from ISO for time zone stuff.

Ah ok I think I get you now. To be clear, fall through is implicit - when the case being fallen through is empty. I forgot that, if you want to execute some statements in one case, and then go to another case, you need gotos. To be fair, I’ve never needed that behavior before.

I absolutely see your point on break not being the default. It is sad, although I will say I don’t mind a little extra explicitness in code I’m sharing with a large team.

I’m not sure I understand your point about fall through having to be explicit, but I agree that switch statements are lacking ergonomics - which makes some sense considering they were added a looooong time ago. Luckily, they added recently the switch expression, which uses pattern matching and behaves more like Rust’s Match expression. It’s still lacking proper exhuastiveness checks for now, but that’s a problem with the core design of composition in C#’s type model and one they are looking to solve (alongside Discriminate Unions in all likelihood).

deleted by creator

I certainly see where you’re coming from, but I think the designers of C# have done fairly good job evolving the language to balance backwards compatibility, simplicity (in terms of having “only one way” to do things), and the ergonomics expected of modern languages. I think C++ and JS are great comparisons because C++ has at this point added everything and the kitchen sink to it’s language and standard library, whereas C# has gone much more like JS introducing features that evolve the best practices for writing but still feel and read like essentially the same language. For example, primary constructors still look just like regular C#, it’s just a nicer way to define simple POCOs when desired.

As far as important language features, I think it’s easy to pick on discriminated unions because it seems like C#’s users unanimously want that. However, if you read through proposals and discussions, it’s obvious that there’s a lot of nuance and trade offs in deciding how and what form of discriminated unions should exist in C# (and the designers are very active in working through that nuance and trade off - they said they have a working group that meets weekly to discuss it I believe*). And to be fair, they have introduced a LOT of other important features (like records and the vastly improved pattern matching) in just the last few years. Without those features, discriminated unions wouldn’t be nearly as appealing, and those features are great for the language even without DUs.

*Edit: Source for my claim is the recent Languages & Runtime Community Standup on the official dotnet YouTube channel. Mads talks about the working group at 21:05, but the discussion of discriminated unions begins at 7:09.

TypeScript React (although I like Svelte better, it’s hard to pitch for business projects), C# ASP.NET Core API, Postgresql.

I think they’re referring to the fact that Edge runs on the Chromium engine which, as the name implies, is a Google product.

I’ve been daily driving for right around a year now. There have been less breaks and difficulties than I expected from pre-1.0 software and it has made my shell experience so delightful!

I find that when I want to do something simple quickly, nushell enables me to do it with no context switching, little to no friction, and no googling. I can just open/http get my data, pipe it through a really straight forward pipeline that practically writes itself with how clear the commands are, and save it in whatever format is convenient to me. I don’t have to monkey around with Python and packages and virtual environments, and I don’t have to spend 75% of my time googling and debugging insane bashisms. Nushell just works, and the help is so convenient I almost never have to go to the docs.

My absolute favorite feature is that it’s truly cross-platform. I don’t have to install a compatibility layer like minGW on Windows, I can just make it my default shell and it works great. Then I can use it the exact same way in WSL, macOS, and Linux.

The reasons to not be interested in nushell imo are:

1. You’re already comfortable to the point of mastery with bash/zsh/fish, so the ease of use and quality of life improvements from nushell won’t be as valuable to you compared to the cost of switching.
2. You spend more time in the shell on random servers you don’t want to customize than you do in your own shell. Obviously we are (infinitely?) far away from nushell becoming a default on any platform, so if you aren’t gonna be able to install in the places you would want it most, you’ll just end up infuriated that nothing else is as good as it.

This is an interesting artifact because most of these pain points have been effectively solved. Not that there aren’t any difficulties left in cutting edge web dev. For example, we’re still wrangling the frontiers of mixed rendering modes. But between Vite and now Bun, the average dev never has to worry about bundling or module syntax compatibility. Things Just Work. Thanks for the reminder of how quickly the web is continuing to advance GUIs and DX.