1

I currently don't know either of the two languages. Design of a piece of software is close to complete.

The intriguing:

  • Ruby: Enjoyable. Follows thought process. Made for humans.
  • Go: Good performance. Fast compile times.

I don't know about Ruby's performance. If it's a lot slower than Go, I'll go with the latter (talking about typical speed here).

I'll learn both eventually, but right now, this will determine which one first.

Update: It's a very basic image-editing program. Technical and especially perceived speed should be high. Startup time is especially important.

Jonta
  • 393
  • 5
  • 25
  • 3
    The closer to human language, the slower it is. – Itay Moav -Malimovka Jul 07 '11 at 02:03
  • Hm, have I perhaps overlooked something important I should also take into consideration? – Jonta Jul 07 '11 at 02:04
  • 1
    I am not familiar with Go. You need to tell more what is performance critical, the difference between the two in a desktop environment can be less then a second. – Itay Moav -Malimovka Jul 07 '11 at 02:05
  • 1
    I haven't seen enough ruby desktop programs to recommend it to you. And if you ever choose C/C++/Go, go Go. – Zippo Jul 07 '11 at 05:00
  • phresnel: Sure? -- http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all – Zippo Jul 07 '11 at 12:36
  • @Zippoxer: I think it was pretty clear that @phresnel meant this as a joke about the generalisation @Itay Moav made in his comment :) – Jonta Jul 07 '11 at 12:51
  • @Jonta >>It's a very basic image-editing program<< What C libraries wrapped in Ruby can you find to do the computations you need? – igouy Jul 07 '11 at 17:24
  • I would recommend jruby [easy gui] unfortunately the startup time is poor...and runtime performance also a bit suspect. Go has some GUI bindings maybe that would work... – rogerdpack Jun 06 '14 at 14:57

3 Answers3

9

Sadly, neither language is appropriate for a desktop image editing program.

You haven't told us which desktop you have in mind, I'll assume it's either Windows or Mac.

Ruby is not appropriate because it fails 2 of your requirements:

  • it has a terrible startup time because at startup it has to initialize a rather complicated VM, which involves loading quite a big part of its standard library
  • it's very slow (compared to C/Java/Go) doing the kind of computations that image processing entails

Go is statically linked and is compiled to machine code, so its startup time is excellent and the speed is close to C (i.e. it's the fastest language you can hope to choose after C/C++).

However, Go has no support whatsoever for writing Mac desktop apps (i.e. it has no bridge to Objective-C/Cocoa runtime) and the support for writing Windows desktop apps is extremely poor.

If you're doing Windows, the only language that gives you fast startup time is C/C++/Delphi. C# might have acceptable startup time and it's fast enough for the task (very popular paint.net is written in C# and you can find an old version of the code which is BSD-licensed and re-use a lot of its code).

For Mac, I would recommend Objective C - it's the native language of the platform, best documented and with the best, free dev tools (XCode). You can use https://github.com/philippec/Pixen as a starting point.

Krzysztof Kowalczyk
  • 3,513
  • 28
  • 28
  • Or for vector image editing, Sketch is a good starting point for Mac OS X. It's included with Xcode. –  Jul 23 '11 at 22:53
2

You really need to give us some idea as to what you consider to be good and bad performance because it's a very subjective subject.

For example, people are usually willing to trade a certain amount of technical or perceived speed for a system that easier to work with or develope. Plus it also matters what you are tying to do. Each language has it's own strengths and weaknesses. Ruby may be faster at some things than Go. Then again, if you really need speed, perhaps you should be looking at a language that is closer to the metal such as C.

Sometimes though, requests for speed from users are subjective too. I once had a system that the users thought was taking too long to do a specific task. There was no way technically to speed it up, so I animated the "Processing ..." window. Because the users could now see something "happening" on the screen, they thought it was going faster. On a stop watch, it actually took a couple of seconds longer.

drekka
  • 20,957
  • 14
  • 79
  • 135
0

I think those languages are the worst you can choose for performance-critical application. I don't know much about Go, but Ruby is similar to Python (even slower) and Python is slow as hell. As i've been reading, Go is much faster than Ruby, but still is like two or three times slower compared to other programming languages... It depends on what are you trying to do, of course, ie. I wouldn't choose any of those for real-time physics or something like that.

http://shootout.alioth.debian.org/u32/performance.php?test=nbody

Why is go language so slow?

http://attractivechaos.github.com/plb/

I've been working with python for a couple of years and it's really slow and I'm sure you will hate it and Ruby is very similar to Python and it's slower but as Go is too new I don't really know much about it, I can't tell..

Community
  • 1
  • 1
Pablo Ariel
  • 251
  • 3
  • 16
  • 1
    If that's the case, Ruby is probably out of the question. – Jonta Jul 07 '11 at 02:39
  • 5
    What the hell? You linked to the slowest go benchmark available. Why not link to the [averages](http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all)? Go is *much* better looking when you look at the big picture. You just picked one benchmark, and given how that benchmark is so far off from the average, it's probably just written poorly. – ryeguy Jul 07 '11 at 02:41
  • The benchmarks are not optimized. In [this post](http://blog.golang.org/2011/06/profiling-go-programs.html) a code optimization made Go go faster than all it's competitors (including C++). But in regexp benchmarks, go has [a little problem](http://groups.google.com/group/golang-nuts/browse_thread/thread/e9dd6669e7f88d0f) right now. Don't forget Go is still new compared to it's competitors. – Zippo Jul 07 '11 at 04:53
  • @ryeguy >>You linked to the slowest go benchmark available<< NOT TRUE. The n-body task Pablo Ariel linked to shows median Go performance compared to C++ and better than median performance compared to Ruby. http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=go&lang2=gpp#faster-programs-approximately – igouy Jul 07 '11 at 17:17
  • @Zippoxer >>The benchmarks are not optimized<< How do you know? And why not? – igouy Jul 07 '11 at 17:18
  • @Pablo Ariel - Note: The 6g Go compiler on x64 seems to produce faster code than the 8g Go compiler on x86. – igouy Jul 07 '11 at 17:21
  • @igouy: I don't care, that wasn't my point. My point was that he linked to only one benchmark, and he didn't even pick a benchmark that represented an average performance case. – ryeguy Jul 07 '11 at 18:02
  • @igouy: I've read it somewhere - so you may believe it or not. In the last [benchmark that was optimized](http://blog.golang.org/2011/06/profiling-go-programs.html) Go did better than C++. Anyway, in the [link I gave before](http://groups.google.com/group/golang-nuts/browse_thread/thread/e9dd6669e7f88d0f) Russ Cox & others talks a little bit about those benchmarks. There's another link when this is the main talk, but my memory and Google doesn't cooperate sometimes. – Zippo Jul 07 '11 at 18:17
  • @ryeguy - If you don't care whether what you say is true or not then why should anyone care what you say? 1) Pablo Ariel did pick the benchmark task that represented average (median) performance 2) It's better to pick benchmark tasks most like the task being considered than to settle for an average. – igouy Jul 07 '11 at 19:54
  • @@Zippoxer >>I've read it somewhere - so you may believe it or not<< The question is why do you *want to believe* it? Presumably you don't believe everything you read :-) – igouy Jul 07 '11 at 19:57
  • @igouy: Because I also remember it was trusted source and as I said, Go is new and ofc that the benchmarks are not fully optimized yet. – Zippo Jul 08 '11 at 06:04
  • I think those benchmarks are ok for what he wants to do, now that I know, and probably will do fine with Go, as long as he chooses the right graphics library, trying to get the lowest level possible, and prevent copying the bitmap many times in a paint call – Pablo Ariel Jul 09 '11 at 17:25
  • Actually I thought he was asking about which language between THOSE TWO. Of curse if I can start a discussion about this, I would say he should use SIMD ASM and __declspec(__align(16)) in every data structure, but hey isn't it a better answer to say "you should use C++/Delphi"? oh of course, how I didn't notice. – Pablo Ariel Jul 13 '11 at 07:44