I've been using vim (now neovim) for almost 20 years now.
In terms of efficiency/productivity/time saved, my guess is that it's not worth it.
In terms of happiness, I love it. I live in vim+tmux+bash. My setup is extremely personalized. If anything annoys me about my day-to-day activities, I can just change it. It can be a time sink, but I enjoy it.
> In terms of efficiency/productivity/time saved, my guess is that it's not worth it.
For me, I wouldn’t be using vim if there wasn’t a productivity bump. When I became comfortable with vim I was appreciably faster, but it took maybe a year to get to that point. Not having to reach for the mouse is a huge benefit. Macros turn repetitive manipulations to a from O(n) to O(1). Using the dot key to repeat a change can be very powerful too
In terms of happiness, I agree. Productivity is not bad too (understatement of the year :). But as for any powerful tool, to get the most or even a lot from it, you have to spend some time. But IMO at least, the learning curve is shallow, for easy to medium tasks.
And anyone not knowing the basics of vi, can get started very quickly with my vi quickstart tutorial below.
I had first written it at the request of two Windows sysadmin friends of mine, in a company where we were working at the time.
They had been given additional charge of two Unix boxes, so, being busy people, as sysadmins usually are, they asked me to write a tutorial that would let them hit the ground running for common sysadmin text editing tasks. After reading it and using Unix for a few days, they told me that it was useful and met their need.
The tutorial is small, so it can be read soon and you can start applying it right away:
It enables you to start with just some basic vi commands, and as you go, you can build more vim-fu by reading the docs, blogs, videos, practicing, etc.
Also be sure to check out this famous StackOverflow answer to grok the zen of vi:
"Your problem with Vim is that you don't grok vi.":
>> at the end of the day, we're trying to exchange useful products for money
> If you're just trying to make money, then you shouldn't call yourself a hacker.
I hate gatekeeping like this.
For anyone who needs to hear it: you don't need to be a starving artist. You are not a sell-out for wanting to exchange useful products for money. You can call yourself a hacker.
Great job! How were you able to do a stand-alone binary for Mac? I was able to for Linux via their Alpine/MUSL image, but never figured out how to for Mac.
Just using Crystal as installed with Homebrew and then running `crystal build --release`. Very simple, see the Github Actions workflow in the repository :)
ah, are these are "standalone" or static binaries with no dependencies then? I think end users may need to have the crystal runtime installed as a dependency.
At the moment they are not static, so on Linux you may need to install a couple of packages depending on your system. I am going to try and compile a static version. On MacOS AFAIK it is not possible to compile a static binary.
I've had my car broken into twice in SF. Everyone's response to this is always "you can't leave valuable things in your car". Both times, my car was empty. Nothing was stolen. I have never left anything valuable in my car -- visible or hidden, trunk or otherwise. Not sure why people keep giving me this advice.
I always keep a roll of duct tape and some cardboard in the car now. I tape up my quarter glass (the smallest of the rear windows that thieves love to break) and cover it with cardboard, to make it look like its already been broken into. I also leave my back seat down w/ a clear view into the empty trunk. That's the only thing that works.
It's not in the official binary releases yet. You'll have to compile your own Crystal via `make interpreter=1` to use it. Instructions here: https://crystal-lang.org/install/from_sources/
We don’t have an app/ directory in our Rails project. All of our code is either in gems/ or engines/.
Gems contain Ruby code that does not depend on Rails. We use ActiveSupport, but we do not use ActiveRecord or ActionPack. The gems are all stateless.
Engines contain Ruby code that does depend on Rails. Persistence happens at this layer through ActiveRecord. API and Web interfaces are exposed at this layer through ActionPack.
Is it a good trade? To me it seems like maintaining a gem/library is less complex than maintaining a service that exposes the functionality of said gem. No networking, deployment configuration, request handling, parsing, host monitoring, logging, access control, etc to deal with.
Right, but then they say "Although structuring GitLab as a monolith has been extremely beneficial for us, we are not dogmatic about that structure." And looking at their source code, they aren't following that very strictly.
