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…
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…
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…
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…
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…
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.
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…
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…
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…
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…
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…
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.