<story><title>Another go at the Next Big Language</title><url>http://dave.cheney.net/2012/09/03/another-go-at-the-next-big-language</url></story><parent_chain></parent_chain><comment><author>InclinedPlane</author><text>Here&apos;s the core problem with next generation languages. Languages that come out of academia focus too much on syntax and computer science level functionality, and it&apos;s extremely rare for a language of that sort to make it in the real world. The languages we use today either come from big companies with the ability to promote anything long enough to get traction on any language that is at least &quot;good&quot; or they come from the &quot;streets&quot;. From extremely small teams who create incredibly flawed languages that are immimently practical and go on to rule the world. Perl, Ruby, Javascript, PHP.&lt;p&gt;It&apos;s &quot;worse is better&quot; again in spades. Ivory tower language designers try to come up with perfection when what we really need is to improve on the basics.&lt;p&gt;The next big language is probably not going to be something like Haskell (as nice as all that functional purity is) it&apos;ll be something that builds profiling and unit testing and better source control support right into the language, compiler, and tools.&lt;p&gt;Edit: if you look at where the average developer is spending most of their time and especially where the majority of the pain is it&apos;s typically in things like testing, debugging, performance profiling and optimization, and deployments. And if you look out there in the field you&apos;ll see lots and lots of awesome tools and systems helping peoplee tackle those problems. But it&apos;s exceedingly rare to see a new language which approaches those problems or tries to codify those tools into first class language features.</text></comment>
<story><title>Another go at the Next Big Language</title><url>http://dave.cheney.net/2012/09/03/another-go-at-the-next-big-language</url></story><parent_chain></parent_chain><comment><author>nyan_sandwich</author><text>I was really excited about Go. Designed by some gurus, seemed to get everything right, google app engine supported it.&lt;p&gt;Then I tried to build something.&lt;p&gt;Java-like verbosity. Meh, I can deal with it.&lt;p&gt;[]byte and string aren&apos;t the same. Whatever, a few extra lines and thot cycles here and there, no big deal.&lt;p&gt;Overly complex library functions. Let me explain this one. In Lua, markdown (discount) is a single function. In Go, there was a bunch of extra stuff that just seemed like noise. Likewise for cypto, Base64, stringwriters, bunch of other stuff.&lt;p&gt;A bunch of little annoying stuff like that adds up. Eventually I just said fuck it. Maybe I&apos;m not hardcore enough or something, but now I&apos;m back with LuaJIT.&lt;p&gt;Goroutines are cool, tho. Lua&apos;s synchronous threads aren&apos;t quite the same. Also google&apos;s app engine datastore is sweet. Nice and simple, no screwing around with SQL. If I had to do systems stuff, I&apos;d reach for Go.&lt;p&gt;LuaJIT is faster anyways.</text></comment>