> I'm calling you not particularly self-aware.

Based on no real data except your prejudices.

> Unless that language is so domain specific that there's no room for design or so derivative that you can apply another language's style 100%, you almost definitely still have more to learn after 2 weeks.

There's a vast chasm between "understands the language's semantics" and "has no more to learn." I've been programming for over a decade now and there's no language about which I can say "I have no more to learn." If all you're saying is that it takes more than two weeks to know a language completely, you're not saying anything useful at all.

With regards to the language's domain specificity, it's a standard procedural language, with types and functions and values and loops and all the ordinary stuff that languages like C and PL/I and FORTRAN and Modula-2 all have had since the 60s and 70s. It has first-class and higher-order functions, like Lisp has had since 1958. It has a few declarative features mildly reminiscent of Prolog to enable transparent parallelization.

Hell, look it up yourself if you're especially interested. It's Sawzall: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.169....

There is extremely little that is new in production programming languages these days. Practically every feature of every language that anyone significant is using in production has some analogue in the languages I know. What little remains is not difficult for me to learn because programming languages are my personal area of interest in computer science. I'm not being arrogant here, I'm just being real.

Take a look at Go. A fun post was made soon after Go was released which compared it to "Brand X", an unnamed language few people have heard of: http://www.cowlark.com/2009-11-15-go/ . It turns out that practically every idea in Go is also present in Brand X; it wouldn't be unreasonable to call Go "derivative" with regards to its nature, if not the process by which it was created. I'll spoil the big reveal for you and save you the time of reading the post: "Brand X" is Algol 60, designed and implemented half a century ago. Practically every language can be dismissed as "derivative" if you're looking for a way to negate good programmers' abilities to learn something new.

> Semantics, that's all true, but if you don't have enough experience in the language to even say you kinda know the library, you probably don't actually grok the semantics.

You're wrong. Understanding of a language's semantics is prerequisite to understanding its library. Before a person can even consider understanding and learning the libraries for a language, he must understand the semantics of function calls, conditionals, loops, etc. He must understand whether the language is call-by-value or call-by-name or call-by-need or call-by-object-reference. He must understand how the language handles scoping. He must understand which entities are first-class and which are not. All of this is necessary (though not sufficient) for even beginning to grok the standard library. On the other hand, understanding the standard library is absolutely inessential to understanding the semantics of a language: if a programmer doesn't know what functions and types are available in the standard library, with knowledge of the language's semantics he can reimplement them easily.

> For example, Java, can you tell me the difference between volatile and synchronized as it regards the memory model without looking it up? What's a happens-before relationship and how is it relevant to those keywords? What's the transient modifier do?

I didn't claim to be a Java guru. Very few Java programmers actually need to know the answers to those questions in day-to-day programming; I could probably (if asked to, which I'm not, thankfully) write thousands or tens of thousands of lines of Java without ever needing to know the answer to those. There's certainly a difference between my understanding of Java's semantics and the understanding necessary to answer the questions you're asking, but for the vast majority of tasks, productivity happens far closer to my end than yours.