I am curious what problems the author had editing from WSL in the windows file system. /mnt/c contains the whole c drive and in my case I have symlinks set up in wsl to redirect me to specific parts of the windows directory structure from there, like for example my one drive synced folders. And as for editing windows files with a WSL vim, well a simple :set ff=dos will do the trick. Also WSL supports more than just Ubuntu now for the linux instance.
I have 2 I use, most frequently a T440 for running OpenBSD current. I am a recent convert to OpenBSD and targetting older thinkpads I grab used off of craigslist works well for me. Other than that I am a fan of chromebooks for the hardware working well with linux out of the box. I have been a crouton user on ChromeOS for a while now and with the linux app support if linux is your main OS I consider it a no brainer. I like my laptops to be efficient, not high horsepower workstations in laptops. For high horse power I prefer going to my thinkserver workstation. I want laptops I can run all day and need the touchpad as little as possible. Possibly not the best answer for someone looking for something new. But if it helps, best of luck.
As much as I can agree with the basic premise I think the author misses the other side is that even in the traditional RDBMS space SQL is slightly different. This is the reason that although I end up having to dive in the SQL Alchemy docs quite frequently when I use that library it tends to guarantee my program can be used more easily with more DB without having to worry about their individual quirks in how SQL is implemented.
And dare I say it I kind of like mongos query language, once you get your head around it, there are some cool things it can do. It is not the slick declarative syntax of SQL, but it has its merit for that domain.
If a project has an explicit requirement to support multiple databases, then SQL differences can become a problem. However, my experience is that it’s not the case for most projects. Typically you pick a database that you’re going to be using up front, and you’re not going to be switching databases in the middle of development.
I also think that the approach taken by Honey SQL is a good middle ground. It represents queries as structured data, so you’re able to easily manipulate and compose them programmatically. However, it maps directly to SQL avoiding the problem of having a leaky abstraction on top of it.
I am curious what problems the author had editing from WSL in the windows file system. /mnt/c contains the whole c drive and in my case I have symlinks set up in wsl to redirect me to specific parts of the windows directory structure from there, like for example my one drive synced folders. And as for editing windows files with a WSL vim, well a simple :set ff=dos will do the trick. Also WSL supports more than just Ubuntu now for the linux instance.
It’s the other way around. Editing a Linux file directly from Windows can mess things up badly.
I have 2 I use, most frequently a T440 for running OpenBSD current. I am a recent convert to OpenBSD and targetting older thinkpads I grab used off of craigslist works well for me. Other than that I am a fan of chromebooks for the hardware working well with linux out of the box. I have been a crouton user on ChromeOS for a while now and with the linux app support if linux is your main OS I consider it a no brainer. I like my laptops to be efficient, not high horsepower workstations in laptops. For high horse power I prefer going to my thinkserver workstation. I want laptops I can run all day and need the touchpad as little as possible. Possibly not the best answer for someone looking for something new. But if it helps, best of luck.
As much as I can agree with the basic premise I think the author misses the other side is that even in the traditional RDBMS space SQL is slightly different. This is the reason that although I end up having to dive in the SQL Alchemy docs quite frequently when I use that library it tends to guarantee my program can be used more easily with more DB without having to worry about their individual quirks in how SQL is implemented.
And dare I say it I kind of like mongos query language, once you get your head around it, there are some cool things it can do. It is not the slick declarative syntax of SQL, but it has its merit for that domain.
If a project has an explicit requirement to support multiple databases, then SQL differences can become a problem. However, my experience is that it’s not the case for most projects. Typically you pick a database that you’re going to be using up front, and you’re not going to be switching databases in the middle of development.
I also think that the approach taken by Honey SQL is a good middle ground. It represents queries as structured data, so you’re able to easily manipulate and compose them programmatically. However, it maps directly to SQL avoiding the problem of having a leaky abstraction on top of it.