Data point of one, but I've been using Go since 2012 and would drop it instantly if any of the backwards compatibility guarantees were relaxed.
Having bugs imposed on you from outside your project is a waste of time to deal with and there are dozens of other languages you can pick from if you enjoy that time sink. Most of them give you greater capabilities as the balance.
Go's stability is a core feature and compensates for the lack of other niceties. Adding features isn't a good reason to break things. I can go use something else if I want to make that trade.
Respectfully, I don’t think you would just pack up and leave. The cost of switching to an entirely different language—which might have even worse backwards compatibility issues—is significantly higher than fixing bugs you inadvertently introduced due to prior invalid assumptions.
That's a bit bold when you know nothing about me, but sure.
I exist in a polyglot environment and we use Go for things that we expect to sit and do their job for years without modification.
Nothing more annoying with these than needing to update a runtime to patch a CVE and suddenly needing to invest two weeks to handle all the breaking changes. Go lets us take 5 minutes to bump the version number in the Dockerfile and CI configs and move on to more important work.
I'm not suggesting we'd go rewrite all of those if Go relaxed its guarantees but we'd stop picking it to write new things in and it would slowly disappear as we decommission the existing services over the years.
Every language and its environment has issues. Switching always introduces a new set of problems, some of which could be worse, and many of which you won't have anticipated when you encounter them.
Breaking API changes in a minor version update sucks and is often an unexpected time sink, and often mandatory because it has some security patch, critical bug fix, or something.
Breaking API changes in a major version update is expected, can be planned for, and often can be delayed if one chooses.
> I think it's better -- in the most pessimistic case -- to look at jj as reframing how you think about branches and commits in the same way that learning a type of Lisp reframes your thinking even if you're a full time Python developer and have zero intention of ever using a Lisp.
For some reason this actually had me pause in fear. I've been using git deeply for years and find it very natural and mindless to use at this point. The thought that I might again be trapped in Plato's cave like I found I had been prior to learning Common Lisp is actually disturbing...
Bruce Lee has that quote: “ I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.”
If Lisp’s “one kick” is the cons list, then jj’s is the commit: by using them for everything (they replace, at least, the git stash, index, and working copy) you actually get really fluent in manipulating them and they become more powerful than special-cased tools.
I keep hearing anecdotes like this and truly want to give Emacs a shot. Do you use it exclusively on a PC?
My big blocker is that a significant portion of my time is on a phone rather than a computer these days and I have to think that all the chording with Emacs would get impossibly cumbersome.
Anyone here have a good way to leverage Emacs on the go?
I've had a stab at this. My requirements are pretty much:
- Actual emacs as a client strongly preferred; don't assume anything else can correctly parse org-mode
- Sync between Windows, Mac OS, Linux, Android
- Don't force me to remember to sync, so `git commit`/`git pull` or `rsync` isn't viable unless it's completely hidden
- Don't allow me to overwrite the file if the sync has failed
- Work from an ssh terminal
The closest I got was `crdt-mode.el`. That gives me real-time updates between connected clients. It needs some UI polish around connecting and disconnecting, but it's nothing unworkable. I can get to it on Android via termux ssh to emacs running in tmux on an always-on raspberry pi in my office. That's just about ok in terms of key chording for most things. You do lose some capabilities. I've contemplated getting a bluetooth keyboard for these situations but obviously that's not usable in a lot of situations you might want to be taking notes in. I got in the habit of using the very top of the file as a dumping-ground for one-liners from mobile because sometimes that was just easier than anything else. If I was feeling particularly keen I might try something in the spacemacs vein to make the key combinations work better on mobile. From memory org-agenda was fine, so I tended to use that as a default view for TODOs.
What's annoyingly broken is having Windows in the mix. There's something not quite right about the way `crdt-mode` handles line endings which means updates from Windows mess up the other copies, and given how much org-mode relies on line endings it can completely break whole sections at a time. I ended up using the version running on SSH from Windows too, but there are a couple of chords which Windows Terminal mucks up. That bit's not great.
Take Windows out and sshing to a shared terminal emacs instance running in `screen` is worth a try, with the caveat that you will have to rebuild the muscle memory for the chording on mobile. The termux keyboard has a couple of niceties that the default Android one doesn't, without which it would be a complete non-starter.
I faced this problem too. I am a Linux user personally, but use Windows at work. I am not a phone person, but do use it regularly.
I sync org files to phone (using Syncthing) and use Orgzly to access these from Android. Although it is possible to install Emacs in Android as a terminal tool in Termux or even as a GUI tool, you need to connect a keyboard to do something sensible. Long story short, if your phone is your daily driver, Emacs may not be for you as it is keyboard oriented. But if you are a computer person who occasionally uses the phone, there are ways to get by.
I moved from Orgzly to Orgro. Now updating the files on the phone is exactly like any other note-taking phone application (for better or worse). It's not as good as experience as the Emacs desktop, but no worse than anything else on the phone.
How do you use Organice? Do you self host it? Did you install the PWA? Do you have an account with organice.200ok.ch? Is your Org mode usage confined to a single file? How do you open other Org mode files on your phone with it?
I installed the native apk from that issue i linked to, no account or hosting.
I use a few files on my phone, it shows them with a kind of file picker.
I have managed to get org mode working with emacs android port. big help was keyboard designer keyboard.
I was able to set C-x and M-x for single touch. And added some keys as per requirements. https://www.keyboarddesigner.com/index.php?page=24
> Although it is possible to install Emacs in Android as a terminal tool in Termux or even as a GUI tool
FWIW, it seems Emacs can now be built for Android natively - there seem to be related files and documentation in the main Emacs repo, though I haven't actually built it myself, so I don't know how well it works.
Leader keys + Evil mode make the keybindings pretty much non-issue on mobile. Emacs also has native Android port now, I've found it work quite well. There are apps like orgro[0] that make dealing with org files a pleasure on mobile.
That being said, it is not perfect. My ultimate (and imperfect) solution was to acquire a GPD Micro[1]. Now that thing makes up for all shortcomings of mobile devices, not just Emacs :)
Same thing as my main laptop: NixOS + Plasma desktop.
I barely see the desktop TBH. It is there just so I have convenient control of peripherals. 99% of my time is in Web browser or Emacsclient or Terminal. On GPD I use the browser even less, because its purpose is to be a lightweight mobile terminal. Graphical Emacs is just superset of terminal one, so it is preferred is all.
Personally I use the emacs android port with org-roam, with syncthing for sync to back home. I've got ctrl and meta mapped to volume up and down. I don't know that I'd call it a good way, but it works well enough for me :).
Emacs org-mode is one of the better organization tools with batteries included.
For someone who is disciplined, organized and feels limited by their current tooling, Emacs will probably work great like these anecdotes. If having the discipline itself is a problem then Emacs is probably not the right choice to start with because of the learning curve and the friction due to sub-optimal experience on phone.
That said, I do recommend to give it a go. On Android, Orgzly + Syncthing is good enough to get started.
It doesn't look like anyone has mentioned Beorg yet? [1]
I'm not an org power user (yet), but I find this iphone app works great to quickly add todos, view outlines, see my agenda, etc whilst I am out. I have it synced via Dropbox so when I get back to my desktop everything is waiting to be properly organized.
I’ve used org mode as a daily driver personally and at work for awhile but ultimately transitioned to Roam Research in part because the mobile experience is better.
I still use org mode to write my blog and journal but my knowledge management is all in Roam.
SELECT
t.passenger_name,
t.ticket_no,
bp.seat_no
FROM Flights f
JOIN Ticket_flights tf USING (flight_id),
JOIN Tickets t USING (ticket_no),
JOIN Boarding_pass bp USING (ticket_no, flight_id)
WHERE f.arrival_airport = 'OVB';
Have you given sqlx a try? Manual query writing like database/SQL but convenience wrapper functions that handle the row scanning part for you. I haven't felt the need to use anything else for years now.
It's bad at directly working on classical computer problems like math and data processing. But you can do it indirectly by having it write a program that produces the correct result. Interestingly, I didn't even have to have it run the program, although usually you would
write a tool which counts the number of w's in "strawberry" and return the result
Which produced:
Here's a simple Python function that counts the number of 'w's in the word "strawberry" and returns the result:
```python
def count_w_in_strawberry():
word = "strawberry"
count = word.count('w')
return count
# Call the function and print the result
result = count_w_in_strawberry()
print(f"The number of 'w's in 'strawberry' is: {result}")
```
This tool does the following:
1. We define a function called `count_w_in_strawberry()`.
2. Inside the function, we assign the word "strawberry" to a variable called `word`.
3. We use the `count()` method on the `word` string to count the occurrences of 'w'.
4. The function returns the count.
5. Outside the function, we call `count_w_in_strawberry()` and store the result in the `result` variable.
6. Finally, we print the result.
When you run this code, it will output:
```
The number of 'w's in 'strawberry' is: 1
```
This tool correctly identifies that there is one 'w' in the word "strawberry".
I always thought the halting problem was an academic exercise, but here we see a potential practical use case. Actually this seems pretty dangerous letting the LLM write and automatically execute code. How good is the sandbox? Can I trick the LLM into writing a reverse shell and opening it up for me?
I'm not sure it's still the case, but I've had ChatGPT run shell commands. But I don't know what you could do since it's ephemeral, doesn't have internet access or root. Plus I'm sure they have security scanning.
This is excellent as well. I don't really jive with the Collapsnik aspect but I absolutely love powerful systems that can run in constrained environments.
Thanks for sharing, I'll be diving into this for a while
> This made me realize that Go was always promoted as "do not use frameworks, do not use libraries, use standard library, everything you need is in there".
I've been writing Go since 2012 and have no idea where you picked up this sentiment. The stdlib is there to give you many useful capabilities but it's focus has always been on correctness and flexibility rather than performance.
If performance is your concern, it's always been recommended to reach for other libraries that share that focus.
There's plenty to dislike about the direction Go is moving but stdlib performance isn't one of them. Just find a package that suits you better.
i have been coding exclusively in Go for 5-6 years and it was never not the case. So you might have some remaining bias if you started in 2012 when things might have been different.
Having bugs imposed on you from outside your project is a waste of time to deal with and there are dozens of other languages you can pick from if you enjoy that time sink. Most of them give you greater capabilities as the balance.
Go's stability is a core feature and compensates for the lack of other niceties. Adding features isn't a good reason to break things. I can go use something else if I want to make that trade.
reply