I don't know if this is your point, but we're hearing the same stores with AI. Do these people really mean what they say or are they just lying to paint themselves as honorable

How can you say that when workers don't have a choice? What accessible job has professional level pay and is part time?

Nursing

Tauri existed well before the LLM boom.

for me the main thing about Tauri is not that it is built with Rust (that's interesting as well though)

but that it uses the webview implementation of windows and macos instead of bundling its own browser

I've wasted many 2 months on way worst tbh, at least he got something used by users with little, but still some, improvement

I don’t know if I would see ”Now I'm the only go person so guess who gets paged for everything” as an improvement.

Why? The half a second for the HMR is taking up too much your day?

No, because layers of abstraction come at a cost and we have created a temple to the clouds piled with abstractions. Any option to simplify processes and remove abstractions should be taken or at least strongly considered.

Code written for a web browser 30 years ago will still run in a web browser today. But what guarantee does a build step have that the toolchain will still even exist 30 years from now?

And because modern HTML/CSS is powerful and improving at a rapid clip. I don't want to be stuck on non-standard frameworks when the rest of the world moves on to better and better standards.

> Code written for a web browser 30 years ago will still run in a web browser today.

Will it? - My browser doesn't have document.layers (Netscape) It seems to still have document.all (MSIE), but not sure it's 100% compatible to all the shenanigans from the pre-DOM times as it's now mapped to DOM elements.

The Space Jam website from 1996 still renders perfectly almost 30 years later.

https://www.spacejam.com/1996/

Those (document.layers and document.all) were both vendor-specific, neither were part of the w3c. I don't recommend ever writing vendor-specific code.

The w3c and standards have generally won so it's easier than ever to write to the standard.

Having all your code go through a multi-step process that spits out 30 different files makes it impossible to know what’s really happening, which I’m uncomfortable with.

There's a moral line that every person has to make about what work they're willing to do. Things aren't always so black and white, we straddle that line The impression I got reading the article is that they didn't want to work for bubble ai companies trying to generate for the sake of generate. Not that they hated anything with a vector db

OOP isn't just about classes... It can also be about JavaScript classes!

It sounds funny to say that JavaScript classes aren't classes, but if you don't believe me, just ask JavaScript in your browser (Ctrl-Alt-K, probably):

    » class X { }; typeof(X)
    ← "function"

Whats "really good"? Pydantic? Mypy with dataclasses and built in typings? Is integration with Django okay? Genenily curious, not sarcastic. Im coming from from static typing and learning python ecosystem. Im still searching to make it work for me

Pros:

Pydantic is good. Mypy and pyright are good enough for type checking real projects. I run mypy as pre commit. It takes time but it has saved me from real bugs.

The type system coupled with pydantic for validation is more expressive and ergonomic than java / go. But it's also lousy when working with people who don't have the type oriented thinking (especially juniors). You need to enforce people to type public signatures and enable strict linter settings.

Mixed:

Library wise, FastAPI ecosystem is type-first and works well. But old world ecosystems like django - I don't have first hand experience.

SQL alchemy seems to be getting better. But I wish something type-first similar to sqlc or room or Micronaut Data JDBC existed for python, where I could just use pydantic validated DTOs and use query builder, rather than dealing with SQLAlchemy's proxy objects. It's workable though. I would suggest keeping SQLA objects in only the layer that touches the DB and convert them to pydantic models at the boundary.

Library support is hit or miss. In common web dev, I get good typings as long as I stick to popular and "boring" libraries. Sometimes I have to look at docstring and use typing.cast to return types.

Cons:

new type checking solutions like pyrefly aren't there yet for my use cases. Ruff is good as linter and VSCode extension.

IDE extensions and mypy still miss some bugs which should never happen in typed languages. ESP with coroutines. (I wish there was a way to make it an error, to call coroutines without await, unless submitting them to a asyncio.run or gather etc.., dart has very good async linting in comparison).

Writing a: dict[tuple[str, str, str], int] = {} is no fun. But it guarantees if I use a wrong type of key down in the function, I will get a red squiggle.

You're not "reviewing" ai's slop code. If you're using it for generation, use it as a starting point and fix it up to the proper code quality

I say the opposite, the lack of tooling highlights the weakness of the language. The drive to make it declarative/mimic "natural" language by reshuffling and overloading can be "delightful" to some, but beyond the paper covered surface is a mess. And for what ? "5.times do something unless" isn't cute to me. It's a dog "talking" by putting peanut butter in his mouth. But I think I'm the only one who feels this way

What I've noticed about language design is that people confuse their preferences and opinions with genuine objective observations. It's more of an art and aesthetics than a science. I agree "5.times" is an abomination but that's a subjective reaction - there's no principle or law that it violates (other than perhaps principle of least surprise). We can't quantify and measure how good or bad some invented syntax is.

As for lack of tooling, it apparently wasn't a priority when the language was designed. I'm guessing the emphasis was more on the ease of reading/writing, and having internal logical consistency. How such language design decisions make the development of tooling more difficult was a secondary concern.