kaeshiwaza

jj is amazing, even as a solo dev on small projects. It's difficult to explain because it depends of each usage, but it's very easy and safe (you can undo everything) to just try and see.

AI is so ineffective that compagnies that use it cannot pay their workers ! Poor guys tech bros.

Taking a pause also... I don't believe serving IA can be aligned to serving devs. I hope that the part of the work related to the core of PostgreSQL will help the community.

Locality of behavior can be done with few lines of js. https://github.com/gnat/css-scope-inline

I use Fluxbox since the first version. Very easy to customize. I've just an issue with Firefox, the Firefox windows doesn't want to play with Fluxbox (on Debian)...

Maybe the new feature 'hx-on' can help with that ?

As we use less and less Javascript, thanks to htmx, i'm no so reluctant to use vanilla JS when needed.

I'm using htmx in production since one year. From game (scrabble game with board refresh, chat and so on -with sse extension-) and cms to professional crud apps. With Go + stdlib template. Now looking at PWA, it seems to fit very well.

What i like with htmx is that it's very easy to upgrade step by step a legacy SSR app. And the opposite. I mean it will be easy to switch to an other ajax lib or if w3c add similar functionalities in 10 years. To use htmx is mostly to replace whole pages with fragments, that's interesting even when we don't use htmx, sort of server side web components.

In other world, just try !

I'm fighting myself to don't give back examples to the community but i'm so exited to upgrade my very old legacy apps !

I can replace all the iframe from my legacy apps without changing any logic !

Rendering html doesn't consume a lot more than rendering json, specially that with htmx you'll render small fragments... Anyway the bottleneck is most of the time on the database.

I still work like that 30 years after, thanks to Go... I would not like beginning today !

It's where Thomson-Unix way win as KISS and still work for small to large scale.

Maybe they have other future projects with Go ?

In large software you'll not do go get -u for all packages, you'll upgrade each package separately, at the maximum version or at a specified one. It's just that it's you the user of the modules will choose what and when you upgrade, not the(this) tools automagicaly.

Dep has also issues, it's safer to continue to use Dep when you already use it but for new project it's recommended to switch now to go modules. Anyway, most of the time it doesn't change anythings to lock the version with dep or use minimal version selection.

It was a long series of "i will say you my concerns tomorrow" that just make stir up the sauce since month without any clear and obvious problem.

The implementation of vgo (so simple) cannot be compared to dep. It can explain why it was more easy to just do it than spend time to explain. It's often like that in dev, when we find a simpler solution in our own code we just do it and throw away the old complicated one.

I have exactly the same feeling. And remember at the time of the start of Dep that there was no consensus and a big hope that the final integrated solution will be more Goish than Glide. Very surprised by the begin of Dep. I don't believe that rsc and the go team didn't know since the begin that it will not fit sooner or later...

You didn't find example of failed Cargo because most of the time it just do like go get -u, and solve a non-problem !

Upper bound are major version, everything between should be api compatible (it's in the specs of go modules).

You'll find a go.sum with hashs of dependencies.

It's a feature not a problem. It select the only know working solution. You're still free to update to newest versions.

Not only buggy, theses tools didn't follow the simplicity that we like in Go. For example gb was more in the Go philosophy for my taste. I was surprise that it was not chosen as the official experiment.

I've the same workflow, but like you said gopath disappear. You just hate gopath also :-) I mean, with go modules you will have the same workflow but without the need to adjust the envs.

Parts of the "vocal minority" was also emotional, that doesn't help to focus on the technical args.

Look at https://research.swtch.com/vgo-tour (Upgrading)

vgo list -m -u will show you which newer releases of your dependencies. Then you can upgrade one dependencies vgo get xxx or all vgo get -u

Looking at the thumbs up and the comments, the community seems very favorable at vgo. https://github.com/golang/go/issues/24301

edit: and everybody was not agree at the time of Dep launch as it was not simple as Go use to be.

I believe this video of rsc explain some concerns about the Cargo's approach and lock file issues https://www.youtube.com/watch?v=F8nrpe0XWRg

A quick try show me that it's very very slow... Like 1s for a very simple query on a quite small database. I tried from a scaleway server (in France).

Is it possible to create a replicate user and then replicate to a local server ?