JSON schemas let programs specify how JSON data should be structured. Basically, you can say things like ‘this JSON data must have a field “name” which is a string and a field “age” which is a number.’ Of course you can get much more complicated than that. JSON schemas can themselves be represented as JSON values, and there is a metaschema that verifies whether a JSON value is a valid JSON schema.

For Genkit we needed Go code that could

• Read the JSON form of a JSON schema
• Construct a JSON schema by hand
• Construct a JSON schema that described a Go struct type
• Validate a JSON value against a JSON schema

The overall Genkit system could use JSON schemas to help people enter data in the expected format, although that was implemented in TypeScript, not Go.

At the time we couldn’t find one Go package that could do all of those operations, so we used a couple of packages (github.com/invopop/jsonschema and github.com/xeipuuv/gojsonschema). We converted between their data structures as needed by marshaling one implementation to JSON and unmarshaling into the other implementation.

Since then Jonathan Amsterdam and others at Google have written a package that does everything necessary: github.com/google/jsonschema-go. However, at the time we didn’t have that.

JSON schemas are moderately complex, with multiple drafts of the specification, support for cross-referencing within a schema and to external schemas, and checks like “every field that wasn’t explicitly mentioned must satisfy this subschema.” The specification is somewhat abstract and seems to have evolved over time as people have found interesting uses for schemas, especially when working in a dynamic language like JavaScript.

I’ve always enjoyed the implementation of complex specifications, and it’s led me to side projects like demangling C++ identifiers (github.com/ianlancetaylor/demangle in Go and the first draft of the current GCC demangler in C) and doing stack backtraces in C code (github.com/ianlancetaylor/libbacktrace, which had to be async signal safe and required implementing three (3) different decompression algorithms).

So I started working on a JSON schema implementation on the side. It took a while, but I finally published it at github.com/ianlancetaylor/jsonschema.

Rather than implementing JSON schemas as a struct, as the other Go implementations do, JSON schemas are represented as a slice of keyword/value pairs. This is somewhat more space efficient, which doesn’t matter much. It is also more efficient at validating JSON objects: rather than checking every field of the JSON schema struct, it only has to validate the keywords that are actually specified.

Not using a single struct also makes it easier to implement multiple drafts of the JSON schema. The current implementation supports draft-07, draft2019-09, and draft2020-12. Adding support for more drafts should be straightforward.

Now that I’ve written this package, I have no particular use for it. If other people find it useful, I’ll fix bugs and tweak the API for usability. In particular it’s a bit awkward to change any aspect of an existing JSON schema in Go code, which might be useful for some applications. It also doesn’t have full support for JSON schema annotations, as it’s not clear to me that they are useful in Go. And I’m sure there are a number of other infelicities.

Let me know if you find this package useful. Happy hacking.

I’ve come to believe that this is misleading. I don’t deny that ChatGPT, and the many other AI chatbots that have been created in the last couple of years, have a form of intelligence. AlphaGo, which in 2017 defeated the number one ranked (human) Go player, also has a form of intelligence. So does Deep Blue, which defeated the number one ranked (human) chess player in 1997. And likewise for Chinook which won checkers in 1994.

Of course, those other programs are playing games, while AI chatbots are just talking. Those seem like significantly different things. But I’ve come to believe that they are actually similar, and that seeing that similarity helps to clarify the gaps that remain between chatbot intelligence and AGI.

I think it’s accurate, and useful, to see chatbots as playing a game, just like AlphaGo plays a game. Chatbots play what I call the conversation game. This is a simple game with two players who take turns. At each turn the player says something. It can be anything at all. The goal of the game is to keep the conversation going. There is no winner or loser. A game keeps going until time expires or there is nothing left to say.

Humans play this game all the time. It’s practically default human behavior: it’s what we do when we are with another person and there is nothing else to do.

Chatbots play this game quite well. They aren’t as good as a typical human, but they are very good. Playing this game well requires a lot of general knowledge and a lot of intelligence. Chatbot technology is very impressive.

However, there are a lot of things that are not required to play the conversation game. You don’t need to be able to solve problems. You don’t need to deal with the unexpected, except to say something like “What do you mean by that?” You don’t need to have a goal, except to keep playing the game. Although you need to be able to make associations of ideas, you don’t need to actually understand any of those ideas, or those associations. You just need to be able to mention them when it’s a good move in the game.

Making a better chatbot means making a better player of the conversation game. It’s possible to imagine a chatbot that plays the game better than any human. But that need not be an example of AGI.

In order to get to AGI, we need something beyond chatbots. The refinements I’ve seen published, such as reinforcement learning, just give us better chatbots. They aren’t steps toward AGI.

Of course, somebody may come up with a new idea to move toward AGI. But that will be a new idea. What I’m saying is that refining and improving the current ideas won’t get us there.

I’m aware that this critique follows a long line of critiques of AI, which is that as soon as a computer can do something, we redefine “general intelligence” as being something different from what the computer is doing. From one point of view, we are constantly moving the goalpost.

From another point of view, though, AI is investigating the nature of intelligence, an idea that we still don’t clearly understand. AI is helping to clarify what general intelligence is, by showing us what it is not. It’s not chatbots.

For most of that time I’ve been fortunate in being able to work on the Go programming language. Go was started by Rob Pike, Ken Thompson, and Robert Griesemer in the fall of 2007. I joined the team in June, 2008, about the same time as Russ Cox. I’ve been very lucky to be able to work with such remarkable people on such an interesting project.

I am astonished at how much use Go has gotten over the years. Go has reached the status of being just another programming language, one that any programmer can choose when appropriate. That is far beyond what any of us expected in the early days, when our best hope was that Go might serve as an example for useful ideas that other languages and programming environments could adopt.

I started on Go by adding a Go frontend to the GCC compiler. The Go project already had a compiler, of course, based on the Inferno C compiler. Having two compilers helped ensure that the language was clearly defined. When the two compilers differed, we knew that we had to clarify the spec and figure out what the right behavior should be.

In general my self-appointed role on the Go team consisted of tracking everything I could about the project and looking for areas that needed help. Among other things in the earlier years I added Go support to Google’s internal build system, and to the SWIG tool. For a couple of years I was the team manager. From the first days of Go people asked for support for some sort of generics or type parameterization; working with Robert Griesemer I developed a series of language change proposals, and generics were added to the language in the Go 1.18 release in 2022.

My approach had its good points and its bad points. I was quick to see the problems that people were running into today, and the problems they would run into tomorrow, and I was often able to get those problems addressed. But I was slow to see the ideas that would help people do new things that they weren’t trying to do and thus weren’t missing, things such as the Go module proxy and the Go vulnerability database.

Overall I think my approach was a good one in helping to build a successful project. But Google has changed, and Go has changed, and the overall computer programming environment has changed. It’s become clear over the last year or so that I am no longer a good fit for the Go project at Google. I have to move on.

I’m still interested in Go. I don’t think that the language is done. I don’t think that any programming language is ever done–the programming environment changes all the time, and languages must evolve or die. That is doubly true for a language like Go that comes equipped with a substantial standard library, one that must adapt to the new needs of programmers.

I will be taking a break for a while, but I hope to be able to contribute to Go again in the future.

According to the EPA, commercial and residential use is the fourth largest source of carbon emissions overall in the U.S., generating about 12% of carbon emissions. Some sizable chunk of that is fossil fuels burned in the home for heating, for hot water, for gas dryers, and for cooking.

This matters because this use of fossil fuels is widely distributed and is controlled by homeowners. The largest source of carbon emissions, transportation, is also widely distributed, but we know how to reduce those emissions: we must switch to zero-emission cars. This is a fairly easy switch for an individual: when you must buy a new car, buy an electric car. There are many good electric cars out there, and, speaking as someone has owned one for some seven years now, electric cars are better for most uses.

The second and third largest sources of carbon emissions, electricity generation and industry, are problems that can’t be tackled by individuals, beyond general efforts like education and voting. These problems require work by the groups that run the plants. Fortunately, this work, while complex and expensive, is mostly a set of discrete large scale projects.

That is not true for home use of fossil fuels. Reducing fossil fuel use in the home requires tens of millions of individual small changes. Government can encourage these changes via the tax system, but it’s implausible for government to actually do it. Each individual home owner must make the changes themselves.

The goal is to remove any use of fossil fuel in the home. In our case, it meant no longer using natural gas. For other homes it may mean getting off oil or, occasionally, coal.

At present the only reasonable alternative is electricity. This may seem counter-productive, as electricity is also often generated by fossil fuels. Fortunately, non-carbon sources of electricity are available and are spreading fast. For example, in California, where we live, less than half of the electricity in the grid is produced by non-renewable sources. Where we live more specifically, in Berkeley, we can pay slightly extra to get only electricity from renewable sources (though of course this is something of a fiction as electrons are fungible). Also, in our case, we have solar panels.

More generally, as mentioned above, reducing carbon emissions from electricity is a set of discrete large projects. By shifting our energy use to electricity, we reduce the scale of the problem from the impossible (tens of millions changes) to the possible (there are fewer than 2500 fossil fuel electrical plants in the U.S.). It becomes possible to either replace the electricity generation with renewables, or to capture the carbon emissions at a set of locations many orders of magnitude smaller than the number of households in the country.

Moving on to what we actually did, we had three uses of natural gas: our furnace (forced hot air), our water heater, and our cooktop. As it happened, we already had an electric dryer and an electric oven.

I am strictly a software person, so the work was going to be done by other people. The first obstacle we had to overcome was explaining what we wanted. I expect that this will become easier over time. In talking to several different companies, we would explain that our goal was to stop using natural gas entirely, and they would respond with ways to reduce our overall energy use. Typical examples of this were installing better windows and improving our insulation, especially in the attic. We were also offered options like an electric water heater with natural gas for backup. We had to go back and forth with explanations of “sure, reducing energy use is great, but what we really want is to stop using natural gas.”

The second obstacle was our electrical panel. While there are many details and I don’t understand all of them, the simple view is that electrical appliances require a certain number of amps. (There are also volts and watts, but when it comes to electrifying your house they don’t actually matter.) Your house has a bunch of circuit breakers, or, in older houses, fuses, that limit the number of amps that will flow at one time. If you turn on too many appliances they will try to pull too many amps and your circuit breaker will flip. A house will have several circuit breakers, and each one is responsible for some set of lights or plugs or specific appliances. There is also a limit on how much the whole house can draw at a time, which is the size of your overall electrical service. All of these circuit breakers are there to prevent the electrical wiring from heating up too much and starting a fire.

This matters because a house that was built for fossil fuels is typically not built to have everything done by electricity. There may not be enough amps coming into the house. And the existing circuit breakers may not be large enough for the requirements of your new electrical appliances.

It turns out that getting more amps is not just a matter of swapping in a larger fuse. Upgrading electrical service is expensive. Replacing the electrical panel to get bigger or more circuit breakers is expensive. In our case we had to spend on the order of $10,000 for all the electrical improvements, though that required an additional subpanel in a different part of the house, which might not be required in every home.

The point is, if you don’t know how all of this works (I certainly didn’t), an early step in the electrification process is going to be to have an electrician come out and take a look at your system and tell you what will have to change.

The third obstacle is choice of systems. For the cooktop, this is easy: use an induction cooktop. For anything that doesn’t require actual flame, an induction cooktop works just as well as a gas cooktop. For some things, like a low simmer, an induction cooktop is actually better. Some kinds of pots and pans don’t work on an induction cooktop, but as it happened all of ours did work. You can get induction cooktops to replace any standard size gas cooktop. Since you aren’t burning gas, the air in the kitchen is cleaner. This is a straightforward change, once you’ve set up the electrical service: our new cooktop can use up to 50 amps, which is a lot.

For the furnace and hot water heater, the best choice at least in California is a heat pump system. These are two part systems: the heat pump, which goes outside, and the tank or air handler, which goes inside. The heat pump is basically a large fan, and is something like the external part of a whole house air conditioner. It is not terribly noisy, but it’s not silent. And you have to find some place to put it. One nice feature about a heat pump furnace is that you can run the heat pump backward and get air conditioning; no need for a separate unit.

You can get combined water heater/furnace systems that use a single heat pump, but for our house configuration it was simpler to get two different systems. For us each heat pump takes 20 amps, and then the air handler takes 40 amps (the water heater doesn’t need any electricity beyond the heat pump). So you can see how the amps add up pretty quickly.

Specifically our cooktop is a Gaggenau CI 292-601, our water heater is a Sanden SanCO2, and our furnace is a Carrier Performance Series heat pump and air handler. We’ve had them for over a year now, with no problems at all.

While we did all of this at about the same time, I expect that most people would do it as needed. When your water heater breaks, replace it with an electrical one. The main thing is to make sure your electrical service is ready.

Of course it’s also worth asking how much you have to pay beyond the price of installation. In our case, since we replaced the systems at about the same time, it’s an easy comparison. The year before installing them, we spent $250 per month for combined electricity and gas charges. The year after installing them, we spent $270 per month, just for electricity (with no gas charges). (These prices include charging our electric car, by the way.) So the electrical appliances are a bit more expensive, but it’s in the same ballpark.

And, of course, no more natural gas. Our local gas company, PG&E, removed our gas line entirely, cutting it off at the street, for no charge. This may make our house slightly safer in case of an earthquake: no danger of a spark from a gas leak.

If you’ve read this far, remember: check your electrical service, and the next time you have to replace any fossil fuel powered appliance, make sure to replace with an electrical one. The planet will thank you, and it’s the right thing to do.

The container/vector package was deleted in October, 2011, before the Go 1 release, because by that time it added nothing that was not available more simply using slices.  But it was useful once; in October, 2010, it was used by 18 packages in the standard library.  By the time it was deleted one year later, it was not used by any.  This change occurred because of a key feature added to the language: the built-in append function.

The append function was first proposed by Robert Griesemer in an internal e-mail sent in November, 2009, during a discussion of whether to add the built-in copy function (as a result of that discussion copy was added to the language in CL 156089).  At that time I replied about both copy and append saying “It seems to me that these functions are not useful if we figure out a way to implement generics. Not necessarily a strong argument against them, I suppose, but do we want to introduce new builtin functions if we may not need them?”

In 2009 we added copy but not append.  In October, 2010, David Symonds proposed append independently, saying “It’s been getting tiresome having to write the same old boilerplate to grow a slice on demand. container/vector would be suitable if it were generic, but cluttering code with type assertions is worse than the expansion.”  Robert picked this up and outlined the function we know today, adding “Should we ever have some form of genericity, this could even become a library function. For now, the implementation would be a built-in.”  I replied to the thread, essentially repeating myself from a year before: “I’m not really opposed to a builtin append function but I want to make the obvious comment that, like copy, this is a function we are only considering because we don’t have generics.”  The result of this discussion was to add append as we know it today to the Go language (CL 2627043).

The point I want to make here is that because we had no way to write a generic Vector type with an Append method, we wound up adding a special purpose language feature to implement it.  A language that supported parameterized types with methods would not have required a special built-in function that only works with slices.  An append operation makes sense for other sorts of data structures, such as various kinds of linked lists.  The built-in append function can not be used for them.

I am writing this note as a user experience report to add to the Go wiki.  To fit the format there, what we wanted to do was to add a generally useful mechanism for extending a slice.  What we had to do was extend the language.  That wasn’t great because it made the language more complex by adding a special purpose, non-generalizable, non-orthogonal, feature.