Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Doomed from the start (Score 2) 325

The main problem that killed (is killing?) smartwatches is not only the limited use scenarios for them - is that battery times sucks. 24-48hs is already miserable for a phone, let alone a device you are supposed to attach to your wrist. My watch is a Citizen EcoDrive: rugged, accurate and never ever needs recharging.

I have several acquaintances who stopped using their iWatches or 360s just because it is annoying to put it to charge every night next to their phones. Been thinking about buying a 360 from one of them because there're some interesting apps for pilots out there but, in the end, its more a novelty than anything else.

Comment Re: But what is it used for? (Score 2) 252

Sheeze. Ok, to wrap it up: goroutines are not OS threads like you originally suggested. There's not a a clone syscall associated with every goroutine; in fact, you can limit the number of concurrent threads on a Go process to 1 if you like and have them all run under a single process. See GOMAXPROCS.

Now, the concept of goroutines is arguably much closer to what's commonly known as "green threads". But again, this is not what you originally stated.

Comment Re:But what is it used for? (Score 1) 252

I humbly disagree. Not like i have ran any scientific benchmarks on this, but from my limited experience Go binaries tend to be blazing fast.

Just found a site comparing different languages solving a number of computing problems. Now, i know these are to be taken with a grain of salt, but their results is that Go runtimes are comparable with C++ and way ahead of Java.

Comment Re: But what is it used for? (Score 3, Informative) 252

Let's not pretend that go has some magic concurrency primitive that is anything other than a normal thread launched by the clone syscall.

Oh, but it does - though i wouldn't call it "magic". Don't take my word for it: write a small program spawning, let say, 100000 goroutines. See how many system threads are launched.

From the documentation itself: "They're called goroutines because the existing terms—threads, coroutines, processes, and so on—convey inaccurate connotations. A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space. It is lightweight, costing little more than the allocation of stack space. And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management."

You're mixing up concurrency with parallelism. Rob Pike had a couple of very interesting talks on the matter.

Comment Re:But what is it used for? (Score 1) 252

Excuse me, but it is complete nonsense to suppose that inheritable classes or templates reduce performance, if that is what you mean by generics. In fact, in the hands of skilled programmers, templates are often used to improve performance. And inheritable types has nothing whatsoever to do with performance, again improving it if anything (by allowing you to express a design in a way that is both extensible and performant).

You're wrong. Depending on the implementation, generics can indeed come with a performance hit; the main example is Java, where type erasure and runtime casts are involved.

There's currently no generics support in Go but, based on what the language currently is it (statically typed, no operator overloading, type interference on variable declarations, etc.) a generics implementation will have to be "magic" in some way - that is, it cannot simply be implemented as a code rewrite before compiling.

Comment Re:But what is it used for? (Score 0) 252

Modern data structures without classes or generics? This is where I checked out on Go after initially being interested.

Well, it is your loss. The lack of classes (a blessing) and generics (a curse) means that the language is very performant, at the cost of expressiveness.

And no way to avoid the memory management, a crippling problem shared with Java that makes it a bad choice for many applications (e.g., low latency financial transactions).

I've seen a shitload of financial transaction code written in Java. Now, i'll admit that C++ is usually much better suited for the task, but "lack of memory management" is normally not an issue for that application - or for most ones, i'd add.

Slashdot Top Deals

"I have not the slightest confidence in 'spiritual manifestations.'" -- Robert G. Ingersoll