It has not been updated for a few years, so, yeah, I'm sure it's synchronous.

But I think most of the operations available through that API, should be synchronous. SQL could be asynchronous, but it does not support it.

I think I could make an asynchronous adapter, I have a driver which supports SQL, not async, yet, but I have not have such task yet.

Yeah, it would be kind of ok, if I would have the option to write SQL Query. But in my case, it's not an option kind of.

For instance, using ORM in Python, the table above is defined this way

        Table(
            "some_table",
            metadata,
            Column("id", Integer, primary_key=True),
            Column("x", Integer),
            Column("y", Integer),
            Column("z", String(50)),
        )

Insert some data, into this table

        connection.execute(
            cls.tables.some_table.insert(),
            [
                {"id": 1, "x": 1, "y": 2, "z": "z1"},
                {"id": 2, "x": 2, "y": 3, "z": "z2"},
                {"id": 3, "x": 3, "y": 4, "z": "z3"},
                {"id": 4, "x": 4, "y": 5, "z": "z4"},
            ],
        )

And now, select that data. This code is a part of a test, but I hope the idea is quite clear. Where stmt will be compiled to SELECT id from some_table ORDER BY id

        table = self.tables.some_table
        stmt = (
            select(table.c.id)
            .order_by(table.c.id)
        )
        self._assert_result(
            stmt,
            [(1, ), (2,), (3,), (4,)],
        )

This particular test will fail. It gets [('1', ), ('2',), ('3',), ('4',)] while expects [(1, ), (2,), (3,), (4,)]

And generated code for those parameters

ROUTINE User.Test.G1 [Type=INT,Generated]
	;User.Test.G1
	;(C)InterSystems, method generator for class User.Test.  Do NOT edit.
	Quit
	;
pCOMPILETIME(%class,%parameter) public { New %classname Set %classname=%class
 Quit $ZDateTime($ZTimeStamp,,,3)
}
ROUTINE User.Test.1 [Type=INT,Generated]
 ;User.Test.1
 ;Generated for class User.Test.  Do NOT edit. 10/03/2022 07:50:07AM
 ;;3043524C;User.Test
 ;
ztest() public {
  Write !,"RunTime: ", ..#RUNTIME
  Write !,"CompileTime: ", ..#COMPILETIME
  hang .5
  Write !,"RunTime: ", ..#RUNTIME
  Quit 1 }
zRUNTIMEP() public {
	Quit ($ZDateTime($ZTimeStamp,,,3)) }

From my point of view, the main issue is ObjectScript. Any new developer, would not see it as something that may help him in the future. Developers should not work at the same company and with the same technology for a lifetime. Every developer, should check the potential to change the job, and get a promotion. In comparison to more popular programming languages, ObjectScript can offer nothing at all. Python developers for instance can change work and get a better salary, much easier.

Even though, InterSystems products are supported by other programming languages, such as Java, .Net, and NodeJS. It's real pain, to make that work, even with the last trending Python, quite tricky to start. 

I'm sure, that to gain more people on our IRIS side, we have to look at the popular tools, frameworks, and libraries used by developers, and make them work with IRIS as well. Many libraries support a huge amount of databases, including some proprietary, but no IRIS at all. So, developers who know well Java, have a lot of possibilities to start a project very quickly which would work with any database, but IRIS.

I'm personally, trying to help with these issues. Even for ObjectScript, I managed to upgrade the developer's experience with modern IDE VSCode (So, the young developers who know what a modern development process should look like, would not be so shocked by so outdated Studio). Help with using Docker in the development process, package managers, and continuous integration, all with ObjectScript, and even static syntax analyzer. But I want that all the new projects would not use ObjectScript at all, to help with it, I have built Django driver to IRIS. I want to see IRIS support in as many programming languages as possible, and as many libraries and frameworks as possible. So, the developers would not have any issues in switching jobs, they have to use their knowledge which could be applicable anywhere. Want to build an application that uses SQL, that's ok, here is the driver, connect it and use it, as you would do it with another relational database.  NoSQL, ORM, or something else, is not an issue as well. But it's still too far to this point.