So a while back I was cold-emailed by a recruiter at source{d} (the makers of this library). He wrote that after analyzing my Github profile, he has a great opportunity for me in Country A. I responded back by sending him my private phone number and showing interest in talking to him about this opportunity on the phone.
Usually At this point, serious recruiters will do call you. But instead, he wrote that before going any further, he would like to ask me "a couple of quick questions" and requested if I could email him back my answers.
The kind of questions I was supposed to answer were pretty amusing: for example, one of the questions involved telling "If I live near Country A."
But he could easily find this out by looking at the country code of the phone number I just gave him in the previous email. My location is also public on my Github profile, so he could have easily found out that I live in Country B. which is around an hour away from Country A. The rest of the questions were also showing the recruiter's minimal knowledge of my actual Github profile.
At this point it was pretty evident that I was corresponding with a bot. They were running different set of algorithms against different set of people, trying to analyze the results.
Hey Toni, Founder of source{d} here. First of all my apologies for the bad experience. This should have not happened. We're a team of developers ourselves (no recruiters) working on making sure that these kind of situations don't happen to any developer (we started this because we were fed up with the bad practices in recruitment). We're definitely not a bot, I can promise you this. Every email gets read by a developer themselves (our team: http://sourced.tech/about) and personally answered. If you send me an email (eiso@sourced.tech) I'll personally figure out what happened here.
I got one saying my experience with Go would "be a good fit" with a company.
My Go codebase at the time, on that account, consisted largely of hacky products, no tests, no web-server stuff, high coupling and complexity, and below average documentation. If that indicates experience with a language, I'm almost afraid to ask what WOULDN'T be a good fit.
That, and their stated "real-time" requirements for said company's product made me laugh.
This is actually a really cool idea, like I'm kind of obsessed with the idea of using custom attributes / aspect oriented programming using C#. I don't expect to ever be contacted by a recruiter for purely that fact... but if they saw my code... they might. That's cool.
On the other hand, i'm more of a consumer of open source software than a producer. I tried submitting a pull request once, it got rejected, and I decided it wasn't worth the time.
Our analysis of code is algorithmically (hence we created go-git, to analyse every git repository on the web). We're doing some cool things here, everything from feature engineered models based on extracting attributes from code to turning code into vectors using deep learning.
However, when we have a conversation, it is never a bot speaking, always a real developer. This actually helps train our system (we are humble about being wrong) and makes sure that every developer has a good experience working with us.
Yep is a very similar approach, I'm not familiar with gitgo, but we started to work on go-git before gitgo was published, so this is the reason why we have our own project instead of collaborating on a existing one.
Hi Gustav! It is, all though these days we're named source{d}. We're working on some very cool visualisations to release later this year that allow you to dig in on all of the insights we've learned from your code. Right now there is no way yet, we're completely emerged on focusing on improving our backend (and doing some very cool stuff around deep learning to analyse your code). I'll keep you posted once we release.
What are the chances someone could use this to build a tool to provide structured output for git commands.
SVN had the --xml flag for pretty much every command, allowing for 100% parseable output, with git ( in particular git log) there is no 100% solution - the best you can do is use --pretty=format and create delimiters you hope aren't used in the commit message (or author names/emails, etc) itself.
The output doesn't have to be XML. JSON or even escaped CSV would be fine.
Golang is the new Java. Google designed it for legions of corporate systems coders. It is ultimately destined to be seen as the enterprise language that it is [twenty years ago all the cool kids loved Java]. Google policy is no map function for you, it's just more palatable to bake it into the language than an HR document...it's still pure policy steeped in pointy haired logic.
Don't get me wrong, it's better than it could be: at least it doesn't have something equivalent to UML diagrams. But it's still a corporate policy. It just feels refreshing because...wait for it...it brings garbage collection to C++ programmers. And where have we heard that before?
But with a statically-compiled executable that skirts all the problems with java classpaths and JARs and makes deploys trivial. It's almost like engineers at Google wrote a ton of Java, realized it's faults (along with being sick of paying patent ransoms to Oracle) and wrote a language that was similar but addressed the major pain points for them.
Maybe, in the sense that Go is designed for the use case of large teams of everyday coders (i.e., not PL enthusiasts). A similar use case to Java, no doubt.
That said, Java (and C#, which is where my experience lies) are fundamentally bureaucratic languages. Things like hierarchical namespaces and several layers of accessibility very much mirror their human-org counterparts. Explicitly implemented interfaces are a way of saying “I comply”.
Go, by contrast, is much flatter. Which, perhaps, is where organizations are heading. And interfaces are implicit, which is a way of just doing the job instead of declaring compliance.
I also feel the same. I pulled src code of OpenJDK and Go. JDK code is sprawling over 1000s of directories and deep hierarchies and so many folders just to contain other folders. Go code looks far more cleanly organized.
I wonder if you have taken the time to use Go. I no longer use it but I found it much more enjoyable than C++. I went back to Python for my side projects.
On the one hand, I was responding to the Atwood's law reference. On the other hand, I have become interested in the way corporations use open-source as a strategy and implement that strategy tactically via sort of "basic fighter maneuvers" energy management discipline. [1]
Incipient potential competitors who adopt Go draw a dependency on Google because for all practical purposes, Google will determine the direction of Go: it's core team works there. And incipient potential competitors have radically different needs.
We can differ in opinion upon whether Unix was seen an ATT operating system. For me the legal and licensing histories suggests that it was in a strong sense and the "Open" and "Free" and "Li___" are the heritage.
Go is an incremental improvement over the C++ ecosystem without all the legacy baggage.
By controling the platform, Google can leverage the ecosystem to attract and cherry-pick early adopters to the language.
Once the language becomes populat enough that the Enterprise starts to adopt it, Google will already be onto their next 'ground breaking' technology.
Once people settle on a perception they tend to hold on to it for life. One day soon people won't want to use Java. It'll be seen as "our Dad's language". Steve Yegge (ie now a Googler)
said as much during his OSCON 2007 talk.
The value isn't in the language/platform, it's the people who adopt/build/use it.
Microsoft knows this, developers are what kept them afloat during a decade of stagnation in product development. Oracle thought they could buy their way in by acquiring Sun; except, while they were busy suing Google, Amazon sprinted ahead of the pack with their cloud services platform.
This is how the biggest players make long-term investments. Guarantee an abundant stream of top tier talent and success will follow.
Strategically, the hiring pipeline for Google doesn't matter. It can train new hires in Go or whatever, it's historically hired around non-language competencies to some degree. What matters is being able to introduce breaking changes by leading the development effort and hosting critical repositories: e.g. 1.4 broke subrepository references by changing locations.
Strategically, incipient potential competitors have a dependency on Google and those little breaking changes means that Google can add friction to their development pipeline. Google will, even if it didn't say so on the package, Angular 1 vs. 2 is an example of how willing Google is to leave developers in the lurch and create ecosystem FUD...think of all those now dubious tutorials and "should I wait" forum questions.
I don't think its just happenstance that Erlang allowed Whatsapp to become an existential threat to Facebook with a handful of engineers. Language stability matters for startups more than the big boys.
Go is an incremental improvement over the C++ ecosystem without all the legacy baggage.
Go has little to do with C++, it throws away many useful features (generics, const-correctness, RAII). Also, where C++ encourages reuse of existing C libraries, Go 'penalizes' it by making C calls expensive and placing restrictions on interaction with C (e.g. you cannot store pointer to Go data structures). There are reasons for doing this, but all these things make Go pretty much unacceptable for people who are in C++'s niche.
If Go can be compared to any language with traction, it's the later Pascal family of languages (Oberon) and Java pre-generics. It even makes some of the same mistakes (first no generics, then probably retrofitted generics).
Even if this were true, would it be a bad thing to address some of Javas shortcomings like notorious boilerplate, 100 different ways to package & run your app, multiple seconds to boot up, and "write once, run nowhere"? Many go apps are command line tools, the kind of things people avoided using java for, and where GC does not apply.
When learning a new language for a real problem, I'll go back to things I've written before and rewrite them in the new language.
The core logic is already figured out, so the exercise helps me match up constructs and try to apply the new language idiomatically. Then I can go back to my original problem with more ideas about how to use the new language effectively.
That kinda sorta makes sense given the feeling that "cgo is not go" (http://dave.cheney.net/2016/01/18/cgo-is-not-go). Without cgo no FFI, without FFI you have to reimplement whatever you need in the host language.
Yes, it's a sign of maturity to many developers, many of whom won't touch a language until there are hundreds of libraries, etc for everything. Marco Arment was ranting on his podcast that's it's better to use PHP over Go, for example, because there's so much more support.
Go's lexical scoping and first class function/method's owe a lot to JS for leading the way IMHO. That said, it's "object" system is almost the complete reverse. JS is methods with data, Go is data with methods. It's an interesting contrast.
Javascript leading the way? What are you talking about?
First class functions is a concept from mathematics and many programming languages had this feature way before javascript existed, and I simply don't understand exactly what concept of Go's lexical scoping resembles anything exclusive of javascript.
I don't understand the last paragraphs about methods with data and data with methods, but Go's structs resembles C's structs, binding methods to a struct is an thing I've only seen in Go, but maybe some other programming language had this before.
IIRC, the only difference in C++ between a struct and a class is the default visibility, and maybe some other bizarre quirky corner case or two.
Despite it technically not being in the Go lingo (the word "object" only appears once in the entire Go spec, and that's referring to composing arrays/slices together to get multi-dimensional arrays/slices), I generally don't kick myself too hard for referring to things in Go as "objects". They are. Sure, officially they're "structs with methods" (method is the official term), but given the diversity of other things the term "object" is applied to that's plenty close enough for me.
Go's structs resembles C's structs, binding methods to a struct is an thing I've only seen in Go, but maybe some other programming language had this before.
> Go's lexical scoping and first class function/method's owe a lot to JS for leading the way IMHO.
I don't think this comment deserves the downvotes. JS deserves a lot of credit for doing scoping right in 1995, at a time when most popular languages (i.e. not Lisp or ML) were doing it wrong. (A notable exception was Perl 5, which did scoping right in 1994.) Thanks to JS, a lot of working programmers who would never be exposed to Lisp learned lexical scope. Remember that Emacs Lisp famously chose dynamic scope over lexical scope (a serious blunder) due to RMS's belief that lexical scope couldn't possibly be implemented in a performant way!
I argued for the design of and wrote the implementation for Go's lexical scoping and first class functions, and I can tell you they were in no way influenced by Javascript.
Scheme, Lisp, ML: yes. I'd written sizable programs in each of those, I'd worked on rewriting a programming languages course textbook with a professor in college, and I'd studied On Lisp. One of the initial test cases was Paul Graham's accumulator generator: https://github.com/golang/go/blob/0f4f2a6/test/closure.go
Javascript: no. At that time (Feb 2009) I doubt I even knew Javascript had lexically-scoped closures. I know I didn't buy 'Javascript: The Good Parts' until March 2010. Even today I don't think the fact that Javascript got closures right is particularly remarkable, except that, as Crockford demonstrates, that fact serves as the fundamental saving grace that enables forgiveness of many other problems.
I wasn't suggesting that JS directly influenced you. Rather my point was that JS was of the most important languages that brought lexical scoping and closures to the masses. By the time Go came around, it was considered a bog-standard feature, because of languages like JS (and others) that popularized it. That meant that programmers could more easily pick up Go.
Even if JS was not in the back of your mind, you have to admit that the design of "LISP in Cs clothing" (to quote Crockford) turned out nearly identical - certainly much closer than to Scheme, LISP or ML. And JS did it much earlier than Go. My point was that it owed developer comfort with the design to JavaScript, and not necessarily direct design influence.
What languages without lexical scope are you thinking of?
Aside from literally only (pre-Common and Emacs) Lisp, I can't think of any language without lexical scope (outside some constructs etc).
[edit:] Or are you thinking of "only a single global namespace"? Even that exists only in otherwise highly restricted scripting languages, I think? ("Everything global" is technically lexical, but I see why you wouldn't want to call it that.)
How does PHP have dynamic scope? It's been ages since I touched it, but if I remember right...
Global is just a flat namespace. Functions have their own, separate flat namespace each. I tried the following in a REPL:
function two() {
echo $a;
}
function one() {
$a = 1;
two();
}
one();
as the standard dynamic scope example, and I get an "undefined variable" error. Did that use to be dynamic? (I wouldn't be surprised, though, especially given PHP's implementation history...)
There is an explicit "static" modifier that looks dynamic, but I couldn't get it to run that way. It seems to just retain state in recursive calls of the same function, or something?
[edit:] (And PHP doesn't predate Javascript, but regardless, "no first-class functions" isn't "no lexical scope".)
Yeah, I shouldn't have used the term "dynamic scope" there. PHP has dynamic environments that can be mutated at runtime, which languages like JS don't (well, outside of direct eval).
Remember that Javascript was literally bashed together in just over a week. That's not a slur, that's a description of reality. Javascript is a minor miracle on its own, but even in that minor miracle, Brendon Eich did not have time to also prototype something brand new. Everything in Javascript was decades old when it was created. The prototype system was probably the craziest thing that went in, but even that was old, if not popular.
That is certainly not true, and therefore, not mysterious.
In fact this website, ycombinator, is the result of a nice pay day that Paul Graham enjoyed for selling web service he built in the 1990s using functional programming techniques... and it was not JS.
>> first class function/method's owe a lot to JS for leading the way
Javascript's lambdas were inspired by Scheme which has been around since the 70s.
"Remember, I was recruited to 'do Scheme', which felt like bait and switch in light of the Java deal brewing by the time I joined Netscape. My interest in languages such as Self informed a subversive agenda re: the dumbed down mission to make 'Java's kid brother', to have objects without classes. Likewise with first-class functions, which were inspired by Scheme but quite different in JS, especially JS 1.0." - Eich (on HN)
I once had a cold-call recruiter tell me Go was worthless. I asked the recruiter to never call me again and hung up.
People whom are both disrespectful and unable to see where their hockey puck sports analogies will be later on have marginal utility and are likely liabilities... don't get involved with those sorts.
Usually At this point, serious recruiters will do call you. But instead, he wrote that before going any further, he would like to ask me "a couple of quick questions" and requested if I could email him back my answers.
The kind of questions I was supposed to answer were pretty amusing: for example, one of the questions involved telling "If I live near Country A."
But he could easily find this out by looking at the country code of the phone number I just gave him in the previous email. My location is also public on my Github profile, so he could have easily found out that I live in Country B. which is around an hour away from Country A. The rest of the questions were also showing the recruiter's minimal knowledge of my actual Github profile.
At this point it was pretty evident that I was corresponding with a bot. They were running different set of algorithms against different set of people, trying to analyze the results.