hierro

I do remember using that tool to publish the very first aMule packages for Debian. I think it was called watchinstall.

I don't think Xamarin has open sourced anything that they didn't have to. All tools developed exclusively by Xamarin are closed source (e.g. Xamarin build host, the Mono packager, Xamarin.Insights, Objective Sharpie, etc...).

We're using an internally developed ORM in Go and it saves us a lot of time.

Pros:

- Less typing, which means less bugs.

- Type-checked queries, although this is technically not part of the ORM. We have a custom tool which statically examines the code creating ORM queries, checks the types of the output and lets you know of potential errors (e.g. the field you're querying on does not exist anymore). Writing the same tool for SQL would be incredibly difficult.

- No need for long ugly SQL strings in code (well, except for the ORM implementation itself).

- Easier refactoring. If we make changes to a model, the ORM makes the schema modifications for us (with some limitations - e.g. if you rename a field you have to tell the ORM the old name, so it renames the field in the table instead of creating a new one). Coupled with type-checking this is god-send.

- Complete SQL database abstraction (database/sql does not provide that - placeholders, quotes, etc... vary by database driver).

- SQL / NoSQL / KV-store / whatever transparency. We have SQL drivers for sqlite, postgres and mysql, as well as drivers for mongodb, the GAE datastore and redis. Of course, some drivers have limitations, like the NoSQL ones can't perform JOINs, but we still get incredible flexibility. We had one app running on GAE with a data model which was a good fit for the datastore. Some months later, a few requirements were added and moving to a relation database was the best solution. So we spun off a Google Cloud SQL instance, migrated the data and started using JOINs for the new features, while the previous code continued to work unchanged.

- App Engine / vanilla Go cross platform (well, you'd also need our full web framework for that, but the ORM is one of the key components). We have some applications running in GAE. If they ever get too costly to run on GAE we can just execute three of commands and deploy it to our own servers (and by "three" I mean the exact number: one command to move the ORM data from the datastore to the new database, another one to move the stored blobs from the GAE blobstore to S3/GCS/filesystem and another one to deploy the app to the new server).

Cons:

- Overhead. Negligible in most cases, but when it matters we can drop down to raw queries.

At the end of the day, I think using an ORM or raw database queries is just an engineering decision you have to make depending on your project constraints, not on the language you're using.

You're right, the example does have a glaring bug - and I completely agree with you, examples should not include incorrect code.

Just to clarify, maps can be read concurrently without locking as long as you're not writing to them. As soon as any concurrent operation might make changes to the map (as the example does) you need locking, preferably a sync.RWMutex (a sync.Mutex will also work but will be way less efficient for no good reason).

The tooling is excellent, but the author wasn't aware of it. In fact, the stdlib and the go.types repository provide almost anything required to write a front-end for a Go compiler.

This is way more complicated that it needs to be. Use code.google.com/p/go.tools/go/types to process the AST and you'll get basically the same information that the compiler sees. With that you can generate the code pretty easily. For comparison, our JSON code generator implementation is just ~350 lines and supports having different JSON representations for the same type, which vary depending on the container type.

Also, if you want to make the serialization faster you need to understand exactly what makes encoding/json slow (hint: is not only reflect) and remove all reasonable bottlenecks. You state that megajson does not support the MarshallJSON interface like that's a bad thing, but I'm pretty sure that's deliberate because it's indeed a feature. When encoding/json encounters a type which implements MarshalJSON it does the following:

1 - Call MarshallJSON to obtain its JSON representation as []byte 2 - Validate the produced JSON using a slower-than-the-bad's-guy-horse function based state machine which processes each character individually 3 - Copy the []byte returned by MarshallJSON to its own buffer

Unsurprisingly (after reading encoding/json's code, of course) having a MarshalJSON method is way slower than letting encoding/json use reflection if the JSON you're generating is anything but trivial and without almost any nesting, because it avoids extra allocations, copies and the validation step.

Depends on the country. Most people in the eurozone use "10 €", not "€10". However, when adding SI prefixes most people would append the prefix to the amount, rather than prepending it to the unit e.g. "100k €".