Autocompletion is the only feature it doesn't have compared to these, and it's significantly easier to work with, and works with more databases. Autocompletion will be done early next year.
My cynical side can't help but think they will do this first, then later disable uBlock / other ad blockers (or the APIs they rely on) and claim that "we can do it better." I can't imagine that this isn't a violation of some kind of law (RICO, antitrust, or otherwise), but I don't imagine this would ever be prosecuted.
It's an impossible to comply with demand, that gives the person evaluating entirety to claim compliance or non-compliance based on whim. Not a far cry from a poll test.
Yes, you can access everything via the underlying APIs. chromedp is a relatively new project (only about 4 months old), so there isn't much yet in the way of high level timing / profiling, but we hope to add that to the code base when we have some bandwidth to do so.
With either Chrome in headless mode, or "headless_shell" (a minimal Chrome app part of the Chromium source tree), you first enable the remote debugging port (via --remote-debugging-port=9222), and then you can then simply browse to http://localhost:9222/. That web page will list the various Chrome "pages" (ie, tabs) which you can then click on. Clicking on those tabs will open the Chrome DevTools inside of Chrome, as a web app served from http://localhost:9222/.
This is the internal API that DevTools uses, and is what is referred to as the "Chrome Debugging Protocol" (ie, chromedp). Since 57+, the built in DevTools UI displays whatever the active viewport Chrome "sees" using the screencast APIs. It's just a PNG that's updated every couple hundred milliseconds with the output of Chrome's headless renderer.
If you're using Go, you might want to check out https://github.com/knq/chromedp ... There is also a similar package for NodeJS. Otherwise, you can use Selenium in other languages.
I also can't access this article -- would love to check it out, if/when it's back online.
No idea if this article mentions the book, "The Knowledge" by Lewis Dartnell (see above) -- however I would highly recommend the book if anyone is interested on the actual "knowledge" necessary to reboot a civilization. It goes into some depth on the actual chemical/mechanical processes involved in building modern technology, and more-or-less outlines the steps to go from "stone age" (or at least "post-apocalypse") tech back to something like "modern" technology. Really interesting read, that also is illuminating on how modern technology (and thus civilization) is so much more deeply complicated than most probably realize.
I had encountered sqlcl before, but it requires the JVM, and I don't believe it is open source. With usql, it's open source (MIT), already works with more databases than sqlcl does, and very soon I will have built releases for Windows, OSX, and Linux that one will simply be able to download a single, relatively small (roughly 8 megs) binary and be able to work with any SQL database using the exact same command-line interface for each.
I've already looked into adding ODBC support, and will try to add it. The real limitation here is that I am not working with a ODBC setup locally, so writing/testing anything for it is not really possible at the moment. Also, I believe all the ODBC Go driver implementations require the use of a C lib/dll, so it would need to be similar to the Oracle support and not "out of the box". The beauty of this, is that at the moment you can simply do a 'go get -u github.com/knq/usql' and have a working SQL client that is exactly the same for the 4 "natively supported" databases, and with Oracle support if you have the right local client libraries.
Auto-completion will come in time. I don't know if I would allow "relative" pathing via @@, I'm not sure why you wouldn't just use general paths. As for the other options, such as -f, etc., yes those will be put in place. I am hoping to make this a 100% drop in replacement for psql, so whatever psql supports on the command line, as well as the various backslash commands (ie, \f) will be added.
Yes, I already have a working branch with syntax highlighting and autocomplete hacked together, but the issue is that it breaks for some of the databases. When I can get it stable, I'll make available publicly.
No. You need to use the native SQL dialects for each database. It provides a standard readline-style interface and uses various Go SQL database drivers to talk to the actual databases.
Yes, the plan is to add support for any database (relational or otherwise) that has the ability to be controlled through a "command and query" style interface. This project is only about 1 day old at this point, but I'll make a point to rapidly integrate as many other DBs that are supported by Go as fast as humanly possible.
Btw, it would be relatively straightforward to add support on your own. PRs always are welcome!
This is not about making a generic SQL implementation. This is simply about being able to execute SQL consistently, and to use the same CLI interface for doing so. The user would still need to know the individual SQL dialects for each database they are using. However, at least then if you become familiar with, let's say, mysql by using this tool, the same configuration/settings/etc. will be used for all the other databases.
Thanks for the input! I already have written the introspection SQL for all the current databases in my related project, xo, that I'm planning on putting into this, so I'm not really worried about the implied additional complexity. As well, I don't think that implementing the backslash commands is too difficult, and the real point/motivation is to have a standardized interface for all the databases. I've used both pgcli and mycli, which are nice (thanks!), but I need a single common interface that supports all the databases that xo supports (which is entirely why this was written, as there's no pgcli/mycli equivalent for mysql/sqlite3/oracle -- until now).
This is a new tool (literally only started in the last 24 hours), but already provides a common, usable interface to PostgreSQL, MySQL, Microsoft SQL Server, SQLite3, and Oracle databases. Plans to add support for other NewSQL databases (VoltDB, etc) in the future, as well as to make it have feature parity (and the same interface as) postgres' psql command line tool.
When it's politics, it's not "trolling" -- it's sampling the constituency's appetite for the candidate, and getting early testing poll / focus group data feedback for free.
This is because nil is not the same as SomeInterface. They are different types. In the above example, the correct code would be this:
fmt.Println(bar.(SomeType) == nil) // this will print true
You need to explicitly convert the interface to a specific type (as above) before you can compare whether or not it points to a concrete value. Since SomeInterface could point to any type (by implementing all the members of SomeInterface, you can make any type be of SomeInterface). This is because variables that have a interface type are never nil.
I wouldn't call this a design issue, I believe this was done very purposefully and it makes perfect sense to me and other long time Go developers. The biggest problem I've seen with learning Go is for others coming from Ruby / Java / PHP / etc languages, who have this expectation of what "null" is (or nil as the case may be) and what "interfaces" are. The key to learning Go is to come at it with the thinking of C/C++.
We released a tool, xo, that generates safe and idiomatic Go code from a database schema that does not make any use of an ORM. I have been meaning to add support for generating code for other languages but have not yet had time to do that. That said, it is very easy and very straightforward to do so.