Ah yes, the need for "influence without authority", i.e. "the real challenge of this project is that you have been organizationally set up to fail, and we expect you to find a way to succeed in spite of that."
This is what removed any lingering thoughts I had about moving up the corporate ladder. If in order to succeed I either need to do certain things or at least get other groups to do those things, and if I'm not allowed to do those things, and if no other group is willing to do those things, and if no one above me is going to change the circumstances, why on earth would anyone think this could be successful?
Another good sales pitch is `jj undo`[0]. It puts the repo back to previous state, regardless of what the mutative operation was. It's a powerful and simple safety net that unlocks experimentation.
It does this by adding an new operation on top of the operation log[1], so you don't lose repository states by moving up + down the op log. There's a corresponding `jj redo` as well.
jj undo is great but it's a one time thing. You can't do jj this, jj that, jj other, jj undo, jj undo, jj undo AFIACT. You have to look into the op log and jj op restore for that. It's nice you can get back to where you were though.
The biggest issue for me is it requires active change management (or feels like it). In git I do `git checkout foo` then I start editing. If I want to see what may changes are since foo then `git diff` tells me. With jj though, `jj edit foo` is the to git, state of the repo ALL changes to foo. So any new edits are invisible. So, instead of `jj edit` I have to do `jj edit` `jj new`, then later squash those into foo
I know there are similar cases in git but I guess I'm just used to git so I wasn't using those cases.
that said, I'm mostly enjoying jj. Though quite often i get a conflict I don't understand. Today I got 2 and it told me choose A or B. I did `jj diff -r A -r B` and it said no diffs. If no diffs aren't there no conflicts? I'm sure someone gets it but it was annoying to just have to pick one to abandon
I’m not sure if it’s a typo, but you don’t need to edit and then new, you can just new. It’s a good habit to get into as a replacement for checking something out.
I’m not sure what happened in your conflict situation either, that does sound frustrating. EDIT: Oh, I wonder if it was this: https://jj-vcs.github.io/jj/latest/technical/concurrency/ specifically, that I bet the repo was being modified concurrently, and so you ended up with a divergent change.
> You can't do jj this, jj that, jj other, jj undo, jj undo, jj undo AFIACT
You can as of v0.33.0[0]. Previous behaviour was that `jj undo; jj undo` would leave you where you started (it undid the undo).
> The biggest issue for me is it requires active change management (or feels like it). In git I do `git checkout foo` then I start editing. If I want to see what may changes are since foo then `git diff` tells me. With jj though, `jj edit foo` is the to git, state of the repo ALL changes to foo. So any new edits are invisible. So, instead of `jj edit` I have to do `jj edit` `jj new`, then later squash those into foo
I'm not 100% clear on what you mean here, but a few things that might help:
1. In jj you don't "checkout" a branch, you edit a specific commit. That commit might be pointed to by a bookmark but it doesn't have to be. A jj bookmark is roughly equivalent to what git calls a branch. Note that a git branch, and a jj bookmark are just pointers to a commit, as illustrated here[1]).
2. If you want to resume work on a branch/bookmark instead of `git checkout BRANCHNAME` you'd do `jj new BRANCHNAME` which puts a new commit on top of the commit and sets it as a working copy.
3. Bookmarks don't auto advance like they do in git. So adding new commits on top of a "branch" will leave the bookmark where it is until you `jj bookmark set/move` it. So you could squash commits down into the "foo" bookmark, but you could also move "foo" to point to subsequent commits.
4. Not sure what you mean by edits being invisible, but if it's seeing a diff from main to the tip of your branch (with a change id of ex. XYZ) it would be `jj diff -f main -t XYZ`.
The core of their complaint is that if you use `jj edit` it's not obvious how to get a diff of what you did. The answer, of course, is that you can use `jj evolog -p`.
Your response conflates the categories of people and ignores that statements like "people..." can mean "(some|most|all) people..." in casual writing/speech. It is not a fair response.
I agree with your frustration with the framing that _all_ people who like the act and craftsmanship feel AI is negative, and the consequence that if one does like AI, then they must not like the act of craftsmanship. Many such people view it as a tool, Mitchell included.
No, it didn't mean that. It mean what I thought it meant. It was a roundabout way of saying that people who use AI aren't interested in craft. The meaning was plain.
> It's impossible to prevent people who you disagree with from using a language
True, but the message on the website starts with "As a community...", and speaks to participation in the Gleam community, not the usage of Gleam as a language. And participation within a community _can_ be prevented by its stewards.
I just want to point out, this conversation has been had over and over, on HN, in the Gleam Discord, and I'm sure in many other places as well - always spurred by the same statement on the Gleam website.
So instead of discussing one of the most beautiful programming languages ever created, we're discussing politics, virtues, and wannabe Nazis. Because of a single sentence on the website...
I don't care either way, but it is notable how distracting that seemingly innocuous statement has become.
Could the community goals not be accomplished in a possibly less divisive way? The first part of the community statement seems entirely sufficient to me.
So, while I don't care and will continue to use Gleam regardless, it does seem to me that greeting curious potential new users with any particular brand of politics (righteous or not) is possibly antithetical to the goals of the language.
I don't believe even a little bit the success of the community has anything to do with this sentence on the website. The success of the community belongs to the relentless hard work of Louis et al.
The sentence is a source of continuous friction between the language, community, and public. It just seems so... unnecessary.
Half of this thread was consumed with people discussing politics and virtues instead of the v1.12 release - that is a pretty large problem for the language, objectively.
When people google Gleam, they'll find pages/discussions like this instead of people discussing the merits of certain syntax or libraries, new features and the like.
There's a reason most businesses/organizations don't engage in politics... even if the founders have very strong political views.
Your metrics for community success might be misaligned with those of the community stewards.
There's more room for interpretation in "all backgrounds, genders, and experience levels are welcome and respected equally" than with the explicit stated support for BLM, trans rights, and anti-nazi ideologies. Room for interpretation on codes of conduct make for more moderation work, allowing more undesirable behaviours to crop up.
> There's a reason most businesses/organizations don't engage in politics... even if the founders have very strong political views
Yes, but that might not be the goals of the Gleam stewards. Maybe they would rather take a moral stance even if it hurts Gleam's reach.
by default, snapshots only get created on (most) `jj` invocations
the watchman integration runs snapshots on filesystem changes[0], so every time a tracked file changes on disk, a new commit is added to the evolog regardless of `jj` invocations
so say if you ran `jj status`, then changed a tracked file 3 times, and then ran `jj status` again:
without watchman you'd have 2 new evolog entries, resulting from the two `jj status` calls
with watchman you'd have 5 new evolog entries: one from `jj status`, 3 from file changes, and one from the second `jj status`
Not parent, but for me it was a couple hours of reading (jj docs and steve's tutorial), another couple hours playing around with a test repo, then a couple weeks using it in place of git on actual projects where I was a bit slower. After that it's been all net positive.
Been using it on top of git, collaborating with people via Github repos for ~11 mos now. I'm more efficient than I was in git, and it's a smoother experience. Every once and a while I'll hit something that I have to dig into, but the Discord is great for help. I don't ever want to go back to git.
Zed has the least uncanny valley of any vim emulation that I've tried.
Switching is not feasible for me until they get mini.surround[0] and Flash.nvim[1], particularly Flash's treesitter mode (see screenshot of [1] to get an idea).
They work particularly well together to select semantically meaningful chunks of code and add/remove/change surrounding parens/braces/curlies/etc.
I think I understand the use case for a smart surround plugin like this; I watched the demo video and saw and lot of picking-and-pulling text.
What I don’t understand is the development workflow that includes so much text manipulation. If you’re writing new code, there’s nothing to manipulate. If you’re refactoring existing code, wouldn’t you want the support typical AST-based refactoring tools provide? Where’s the sweet spot where shuffling strings around makes sense?
For me (maintainer of Zed's vim mode) it comes down to a few things:
1. LSPs differ per-language, and so I'm never sure whether I'll get lucky today or not. It's more reliable for small changes to talk about them in terms of the text.
2. LSPs are also quite slow. For example in Zed I can do a quick local rename with `ga` to multi-cursor onto matching words and then `s new_name` to change it. (For larger or cross-file renames I still use the LSP).
3. I err as a human continually, for example in Rust a string is `"a"` and a char is `'a'`. It's easy for my javascript addled brain to use the wrong quotes. I don't know of any LSP operation that does "convert string literal into char literal" (or vice versa), but in vim, it's easy.
We are slowly pulling in support for various vim plugins; but the tail is long and I am not likely to build a vim-compatible Lua (or VimScript :D) API any time soon.
For example, most of vim-surround already works so you could get the most used parts of mini.surround to work with just a few keybindings `"s a":["vim::PushOperator", { "AddSurrounds": {} }]`, but rebuilding every plugin is a labor of love :D.
I think you’re just highlighting the different preferences people have between a text editor and an IDE. Obviously the line between the two is very blurry. I much prefer being able to efficiently edit text myself rather than relying on refactoring tools.
Appreciate the response. I viewed it more as a question about scope rather than preference.
At mega-scale, even IDE based tools are skipped in favor of automated tools such as Refaster/OpenRewrite that can refactor 10s of millions of lines of code at once.
I do find myself occasionally using, say, a regex find/replace to change something project wide. But most of the time (95% to put some arbitrary number on it), once I’m beyond the scope of single function, I use AST-based tools to ensure changes are correctly reflected in other files or parts of the project.
So, I’m trying understand to who lives in my 5% long enough that they the need what is essentially a highly specialized regex. Are they doing cross-project changes based on text? Do they have giant functions where that’s not a concern? Are their projects just smaller and they have many of them?
I definitely see the allure of having a smaller, faster editor. How far are people actually able to push that paradigm?
