Toward a more approachable Rust

Posted Mar 2, 2017 16:16 UTC (Thu) by kjp (guest, #39639)
Parent article: Toward a more approachable Rust

I'm very sad that swift still isn't anywhere in the discussion. To me, swift seems like a good candidate for this. It wouldn't have memory overhead (good for a constantly running daemon) and the cycles you burn for refcounting wouldn't matter for something with as little load as an ntp client. To be honest, I think google is setting back programming by decades by pushing GO - if you want to use go, just use java 1.0 without exceptions.

Toward a more approachable Rust

Posted Mar 3, 2017 1:16 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

Does Swift have a stable command line interface yet? Or does it still require driving by Xcode or some other external tool? I seem to remember some parts of swiftc being black boxes for calling (though I only lightly followed the thread seeking to add support for it to CMake).

Toward a more approachable Rust

Posted Mar 4, 2017 11:45 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Looking at CMake, Swift support is there for Xcode, but not other generators.

Toward a more approachable Rust

Posted Mar 3, 2017 13:07 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

An interesting proposal for Swift: https://github.com/apple/swift/blob/master/docs/Ownership...

Toward a more approachable Rust

Posted Mar 3, 2017 14:46 UTC (Fri) by karkhaz (subscriber, #99844) [Link] (2 responses)

As far as I know, Java (1.0 or otherwise) is using shared-memory concurrency rather than channel-based (message passing)?

The two are theoretically equivalent in terms of their expressivity, but shared memory is known to trip programmers up a lot more---deadlocks, races, all the bad concurrency bugs that don't typically occur when you're using channel-based concurrency.

Go's big win is bringing this sort of concurrency to a (hopefully soon-to-be) mainstream language. The language that came closest to this, I suppose, is Erlang, but that's still fairly niche. Channel-based concurrency is apparently the canonical style in Rust also (AFAIK), although in that language it's implemented through the library rather than as language primitives.

Toward a more approachable Rust

Posted Mar 3, 2017 16:34 UTC (Fri) by kjp (guest, #39639) [Link] (1 responses)

What is stopping you from passing a message in java? Or in any language?

Toward a more approachable Rust

Posted Mar 3, 2017 17:36 UTC (Fri) by karkhaz (subscriber, #99844) [Link]

The lack of primitive support. I was mostly arguing against your assertion that Go "is setting back programming by decades". Quite the contrary---I'm hoping that future languages follow Go's trend of having channel-based concurrency as part of the language model.

Obviously you can do anything in any language and you can write a kernel in javascript and a web application in OpenCL if you really want to. But having domain-specific linguistic constructs shape our perception of how to think about solving the problem at hand. Nothing is _stopping_ you from passing messages around in Java, but there isn't anything that makes it particularly compelling either. The Thread/Mutex/etc classes in the Standard Library are mostly modelled after pthreads, and there isn't any Standard Library interthread channel implementation AFAIK---never mind language support.

It would be great if tomorrow's programmers end up thinking about concurrency in a message-passing style, rather than shared-memory style, by default. Having languages that express these ideas as primitives will go a long way toward ensuring that this happens. Pthread-style concurrency should be something that you only learn if you have to use it, rather than the default way of doing concurrency. Go is a pioneer in this regard (well, Erlang is even more of a pioneer, but it never caught on).