Hacker News new | ask | show | jobs
by tmikaeld 4137 days ago
Why was Golang not a consideration?
3 comments

My guess is probably the same reason why the author writes "NONE" in the "Ease of / Desire to programming" section for Java... because brackets, pointers, for loops, using : to declare types, and other such C-derived language constructs / tokens.

This may be a generalization, but from my experiences so far, it seems there are two major schools of programmers in today's world: those who come from Java / C, and those who come from Python / Ruby.

The Java/C school likely did a lot of low-level stuff, hardware, OS, compilers, and the like college. If required, they can probably crack open the gnu debugger and crank through assembly. They concern themselves primarily with systems that the computer can efficient perform. In their work, the reader will find lots of loops, indexing temp variables, and comments documenting that does what. Today, they tolerate working with higher level tools like Go, vanilla js, Rust, Typescript, etc.

The Python/Ruby school likely did a lot of math and scientific computations in college. In their hard drives, you can probably find Matlab, R, or (more recently) Julia files containing everything from implementations of Newton's method to routines for calculating Navier Stokes. They concern themselves primarily theory and models, and prefer elegant and beautiful models/code to optimized performance. In their work, the reader will find tons of maps-filter-reduce chains, "arrows", and few comments (they argue their code is clear). Today, their higher-level tool chain include things like Haskell, Coffeescript, HAML, etc.

The guys who made Go (Robert Griesemer, Rob Pike, and Ken Thompson) actually found that it was Python and Ruby devs that were adopting Go, rather than C++ devs like they expected [1].

[1]: http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

In their hard drives, you can probably find Matlab, R, or (more recently) Julia files containing everything from implementations of Newton's method

This is a caricature at best. Lots of great, fast, commonly-used libraries for scientific computation are actually in C++. See e.g. Eigen, Blaze, Armadillo, MLPack, CGAL, Caffe, libsvm/liblinear,and GNU Scientific Library.

The ecosystem for such libraries in Haskell is currently (unfortunately) sparse. And in Python they are mostly wrappers around C and C++ code (apparently, Python programmers also like to dive in C or Cython when it needs to be fast).

Hrm, I'm pretty sure I'm not alone in the Java/C cohort around ~2004-2006 who discovered Ruby/Python and friends and felt.. liberated. Java 1.3/1.4 was so thoroughly completely awful and unproductive, I'm quite sure the uptick in dynamic language popularity was a reaction to that.

Funnily enough, it's the few years of Perl+Moose I've done since which has made a switch back to python just over a year ago a bit hard to stomach. Now that I've tasted something resembling an expressive type "system" (however narrow, incomplete and warty it is), which encourages immutable objects, and does so in a very painless and idiosyncratic way - while still bringing many of the benefits of declarative/"up front" programming for free - I really, really miss it.

So of all the things that could have made me realize I've had enough of dynamic languages, it certainly feels odd that a Perl OO bolt-on would show me a glimpse of what I've been missing out on. And even weirder that the closed-mindedness of the average pythonista made up my mind to move on.

Rust has all the hipster functional programming aspects that this high-level language hipster wants...
Except for HKT.. the true litmus test of the highest of high lvl lang. We're waiting Rust.. we are waiting.
Rust seems to take far more from the ML school than it does from Miranda/Haskell, however.
Haha this reply cracked me up! So stereotypical and somehow true.
If you're going to satisfy a type-checker, you might as well negotiate with a reasonable one that understands what you mean and doesn't confuse the obvious :)
Type-driven development, purity, equational reasoning, exhaustiveness checking, pattern matching, STM, Maybe/option types, generics, and alternative concurrency methods?

These are many of my reasons at least.