The memory footprint for Go seems to makes it ideal for mobile devices. Also, considering that Dalvik performance is much slower than Java, it really seems like have Go on Android would be a huge win. http://en.wikipedia.org/wiki/Dalvik_(software)#Performance Go compiles to native, so "compile on install", would probably be needed.
NDK on Android is native (C++/C) and it's there to boost performance and avoid GC in game loops. I've seen too many devs discussing how to mitigate the effects of GC in games to consider Go to be a worthy upgrade at this point in it's development , the NDK would probably still be needed...
Go After 2 Years in Production
161–170 of 178 posts
Re: Go After 2 Years in Production
#162Earlier quoted context omitted.
> I think Scala is an Academic language Sometimes "academic" seems like a catch-all for stuff people don't like. Scheme has a strong academic history in its use and implementation, yet it seems to be described as "academic" only when someone is unhappy with how minimalistic it is, which is the opposite issue described here.
Has anyone here used Haskell in a production environment? I want a language that is small, clean, and can provide a lot of static guarantees . I know many people find static guarantees and unacceptable curtailment of their "programming freedom", but frankly I think it's the answer to many of the problems we face in software today. Small is another thing. E.g. Go and Scheme are small . C++ and Scala are large . You kn…
ATS [2] is my go-to language for static guarantees with C's efficiency. Not sure if it counts as small but the implementation is not big.
[1] https://github.com/adamgundry/inch [2] http://www.ats-lang.org
Re: Go After 2 Years in Production
#163Another Scala user here. And I've been using Scala for the last six months. Mostly developing web applications on Scalatra and Play. I love Scala - It still has its goodiness and it's an excellent alternative to Java. If you notice in all of the Scala books (I've read the one by Martin and the One by David Pollak as well), they all seem to push you towards the functional programming model instead of the much more com…
I've historically been pretty pro-Scala 'round these parts, so my response to this should be considered in that light. So, with that disclosure out of the way... =) I have to admit, I don't agree with the assertion that the cognitive dissonance associated with programming in an imperative way versus a functional way is a major problem to Scala. I realize personal preference is a very big part of this, but there are m…
And since my background used to be client-side Javascript mainly (I was a front-end designer), I find it fairly confusing to switch myself between the two mindsets (FP and IP), which like you said is something more of a personal preference.
And like I said, I still love Scala, for the reasons you've cited. But then again, there are a couple of reasons which I have in mind for going with Go.
The main problem with Scala for me:
1) Difficult to find good Scala engineers. IF you find one, you still need to figure out if he's comfortable with the Functional or Imperative model.
2) Syntax:
This is an example from one of my previous commenters (dxbydt, thank you) on my thread:
scala> def test1 = println ("hello world")
scala> def test2(f: =>Unit) = println ("hello world")
scala> def test3(f:Unit) = println ("hello world")
scala> test1
hello world
scala> test2()
hello world
scala> test3()
hello world
scala> val t = test2 _
scala> t apply Unit
hello world
scala> t()
hello world
scala> t(())
hello world
It is mostly a personal preference, but I still feel too many ways to do one thing is a recipe for disaster.With all that said, I know of people writing a Scala program and not touching it for a year or two unless they wanted to update their OS on their servers.
Re: Go After 2 Years in Production
#164Earlier quoted context omitted.
Go doesn't lend itself to functional programming, in part because of its lack of type parametrization. In a language like Scala or Haskell, using functions like map, fold, and filter is clean an idiomatic. In Go, it is so ugly and convoluted that you immediately reject this approach and use for loops instead.
Standing firmly in one paradigm is a good thing for a language IMHO. I've worked in multi-paradigm languages and they suffer from the fact that their communities can't find a common style. "Should I use a fold or a loop or a tail recursion?", or some library designers want to be as typeful as possible, others don't, etc.
Neither, use a combinator, like map or traverse. (And that applies to all languages that support this style.)
Re: Go After 2 Years in Production
#165Earlier quoted context omitted.
It's not cliche, it's just personal. For instance, most of the code I write is numerical code. To that end, any language without operator overloading is a non-starter, since it's far harder to find a bug in: div(add(mult(-1,b),sqrt(sub(pow(b,2),mult(mult(3,a),c)))),mult(2,a)) than it is in (-b+sqrt(b^2-3 a c))/(2*a) On the other hand, if I wrote server code, operator overloading would be far less useful. I'd probably…
If you don't mind me asking, what sort of work do you do where you mostly write numerical code? Academia?
At my previous job most of my day-to-day work was on algorithms for speech recognition and topic modeling, which is pretty well doubles flying left and right. That wasn't academia either.
Re: Go After 2 Years in Production
#166Earlier quoted context omitted.
It's not quite that bad in Go, (-b + math.Sqrt(b b - 4 a c)) / (2 a) though if you're using a ton of matrices it could be. I for one have found Go great for computing. The really quick compile times with static checking plus the composability are great. It definitely depends though; while the native concurrency is great there aren't a lot of easy solutions for non-shared memory computations. (I saw an MPI package at…
It's more than just matrices, though. For instance, I have a little library that propagates uncertainty for me. Without operator overloading, I'm back to descending into the rpn hole from my example. Another poster pointed out unit analysis. I've done this before with custom types that keep track of the units on measurements. Since you mentioned parallelization, that's another fun toy I've played with. By overloading…
What are you doing with uncertainty that you can do operator overloading with? You usually want to do Bayes rule with probabilities, but that gets intractable fast.
Re: Go After 2 Years in Production
#167Earlier quoted context omitted.
I've historically been pretty pro-Scala 'round these parts, so my response to this should be considered in that light. So, with that disclosure out of the way... =) I have to admit, I don't agree with the assertion that the cognitive dissonance associated with programming in an imperative way versus a functional way is a major problem to Scala. I realize personal preference is a very big part of this, but there are m…
I agree with everything you say. I think functional vs imperative is a matter of taste, though. Even I tend to incline towards Functional Programming (FP) in most scenarios, but in some cases imperative languages are 'good enough'. And since my background used to be client-side Javascript mainly (I was a front-end designer), I find it fairly confusing to switch myself between the two mindsets (FP and IP), which like…
I'll agree that this set of cases does not reflect well on Scala; at the very least, it supports your point that the syntax is too large. Still, I don't mind it too much. Although the "multiple ways to skin a cat" nature of Scala means you can get very WTF-y code like above, it also means that you can construct a list by writing `1 :: 2 :: 3 :: Nil`, or send an actor a message with the Erlang-inspired `actor ! Message("hello")`.
I don't want to be an apologist for it, though. You're correct that there are some nasty corner cases. Using Scala for serious work is difficult if people don't agree on a consistent style.
Re: Go After 2 Years in Production
#168Earlier quoted context omitted.
Well, then write for me a type-agnostic map function that does not rely on introspection.
If you understood how to write Go, you would write an imperative ad-hoc loop instead of composing generic functional combinators. But you have to be mature enough to jump over the shadow of your functional pride and write clean imperative code.
But you have to be mature enough to jump over the shadow of your functional pride and write clean imperative code.
By that reasoning we can go back to assembly ;): you just have to be mature enough to jump over the shadow of your portability pride and write clean assembly code.
Abstractions exist to help us and in that respect Go feels like a throwback to the past. It's pretty much a Java 1.0 that compiles to machine code.
Re: Go After 2 Years in Production
#169Earlier quoted context omitted.
The Go team at Google consists of a handful of people: http://thechangelog.com/100/
Please, let's not have an argument over which dev team is smarter. The fact is that Go and Rust are very different languages with different goals and feature sets, with different levels of ambitiousness and which started development in earnest at different times.