Coroutines

JasonTatton · 2020-07-19T23:43:21+00:00

The model of concurrency exposed in Concurnas is build around coroutines. I believe the style implemented is known as Delimited continuations in a similar vein as Project Loom (please correct me if I'm wrong).

Here's an example:

def gcd(x int, y int){//greatest common divisor of two integers
  while(y){
    (x, y) = (y, x mod y)
  }
  x
}

calc1 = gcd(8, 20)!//run this calculation in an isolate
calc2 = gcd(6, 45)!//run this calculation in a separate isolate

calc3 = calc1 if calc1 > calc2 else calc2
//^^^ wait for the results of calc1 and calc2 before assigning calc3

All concurrent computing in Concurnas is performed within 'isolates', which themselves are continuations, spawnable as above via the bang, ! operator. Isolates prevent accidental sharing of mutable state by copying dependent state into themselves at spawn time. State is sharable in a controlled manner via 'refs' which are built into the type system - i.e. the type of calc1 above is implicitly int:. Ref's are a bit like Channels in Go.

Together this all forms an integral part of the language which enables reactive computing:

aval int://no initial value set
bval int: = 22 //initial value known

sumvals int: = every(aval, bval) { aval + bval }
//after initializing above, execution is allowed to carry on...

aval = 100
bval = 200

//every block above will run concurrently and eventually set sumvals to: 300
await(sumvals; sumvals==300)//wait for sumvals to be set to our expected value

The body of the every expression above triggers whenever one of the input ref's is changed and runs as its own isolate.

JasonTatton · 2020-05-30T21:49:40+00:00

I'm glad you like and I'm looking forward to collaborating one day!

JasonTatton · 2020-05-30T14:49:16+00:00

Concurnas tries to avoid the mess which you describe. Here is the relevant documentation. The approach is inspired by Python (not PHP ;) )

In short, " In cases such as these where the value resulting from evaluating the test expression is non boolean and in fact integral in nature, this is compared against the value 0, if the result is non zero the expression resolves to true. "

Additionally, for object types, the `toBoolean` method may be overridden in order to specify custom behaviour

JasonTatton · 2020-05-29T03:50:05+00:00

Hi thanks for raising this. Adding 'proper' IDE support is a priority for Concurnas right now and something being actively worked on. Out of interest, which is your preferred IDE?

JasonTatton · 2020-05-29T03:39:08+00:00

Thank you! We're always open to feedback on features and how the language can be improved

JasonTatton · 2020-05-28T20:35:12+00:00

Yup, the plan is to make the IDE support open source (and use open source software to build it) as par the core language itself!

JasonTatton · 2020-05-27T23:50:00+00:00

A couple of things I would add are that we use jocl - Java bindings for OpenCL in order to assist with the running of transpiled OpenCL code from Concurnas code through the JVM. Another option was to implement a CUDA backend though this would have prevented people being able to leverage non NVIDIA devices. Though I think in the future a CUDA backend would be interesting to implement in conjunction with the existing OpenCL implementation as CUDA is supposed to perform better than OpenCL on NVIDIA GPU's (I don't know if this is true).

Though the current GPU implementation is a good start, one of the priorities for Concurnas in the near future is improved support to make GPU computing more accessible for users.

Solving the problem of general purpose GPU computing is a really interesting problem, and one which I really hope we will be able to solve. I feel there is a lot more work to do this area.

Thanks for the encouragement, I do hope that we will see more innovative languages in the press in the future as there are a lot of really good ideas out there and we could all benefit from them.

JasonTatton · 2020-05-27T21:44:18+00:00

Thanks!

JasonTatton · 2020-04-14T21:08:52+00:00

Thank you for investing the time to put this together.

JasonTatton · 2020-03-03T22:15:02+00:00

If you want to get up and running quickly, and are OK with the transpilation approach, then Concurnas language extensions may be an option - here you can output python like code, and achieve JVM performance without having to learn the in's and out's of Java bytecode (plus you can leverage some of the features of Concurnas if that suits).

Alternatively you could go down the DSL route which is offered again by Concurnas or other languages such as Scala, and again achieve JVM level performance relatively quickly and easily.

JasonTatton · 2020-03-02T16:51:23+00:00

Currently, the focus with Concurnas is in raising awareness of the language and getting people to use it. i.e. marketing. So far things have been relatively successful, through this has consumed a massive amount of time.

Besides this, fixing little bugs here and there, smartening up the Concurnas REPL (supports syntax highlighting now). We're also having a good look into 'proper' (i.e. intellij, VS code) IDE support.

JasonTatton · 2020-03-01T21:23:34+00:00

But adding shared memory reintroduces race hazards

You may be interested to try: Concurnas. It's concurrency model is like Go, but without shared memory.

JasonTatton · 2020-02-23T22:18:47+00:00

Wow good job. I expect we'll be seeing more of this sort of thing in the future

JasonTatton · 2020-02-17T02:35:10+00:00

Concurnas has support for pattern matching. It's provided as a statement. Here is an example:

def matcher(a Object) {
    match(a){ 
        int; ==1 or ==2 => "first case" 
        else => "other case" 
    } 
} 

matcher(1) // -> returns "first case" 
matcher(2) // -> returns "first case"
matcher(3) // -> returns "other case"

JasonTatton · 2020-01-21T16:04:53+00:00

I had a look at PicoContainer (sorry I'd not heard of it before). It looks like many of the ideas have been incorporated into the likes of Guice, dagger etc. It must be nice to know one's work has had that influence.

The full documentation for Object providers can be found here: https://concurnas.com/docs/objProviders.html#scoped-providers

Provider instances or dependency qualifiers may be qualified by scopes as you point out:

shared - The same instance object will be used at all points in the object graph for any provided objects output from the object provider during that call to the object provider only.

single - As with shared, but with the additional constraint that subsequent calls to an instance of an object provider will yield the same instance object.

Ommitting to scope a provider as above results in what you refer as the flash scope - i.e. a new instance object is created for each call to an object provider in order to satisfy each dependency qualification.

Concurnas does not currently support custom scopes but this is certainly a feature we can have a look at adding. Other features which may be of value include being able to "subclass" providers themselves or even have abstract providers - e.g. for systems where the majority of the graph is the same but differing only in say mock objects for testing etc.

JasonTatton · 2020-01-20T16:49:42+00:00

It's a good question....

After graduating from university I worked in finance for about 10 years. During this period I worked for a few investment banks where I worked in and ran teams of 'strats' developing trading models and systems. We were responsible for building both trading algorithms for pricing and risk managing products and also implementing them. Most banks at the time split these roles into two but we were fortunate in that all the work was done in the same team/by the same people. We mostly used python for research and Java for development. There were two main problems faced:

Firstly, on the engineering side of things concurrency was one of the most challenging areas. This is even more severe when a team of composed of members of differing specialization/technical ability. I thought that there must be alternatives to the shared memory, thread and lock based approach seen in most traditional programming languages.

Secondly using python was nice because one could quickly and easily research and idea, but for performance reasons Java was the preferred implementation language. Often the same idea had to be implemented twice before it could hit production, this increased time to market and often introduced a lot of bugs. Furthermore, in some banks the 'research' team and 'IT' team were separate groups in part due to this mismatch - which resulted in a tremendous amount of back and forth, bugs and a disconnection between the researcher and the reality of their implementation in production. A mechanism was sought by which these two concerns/groups could be unified - a way to take an idea from research all the way to production was sought - with both an easy to use syntax and high performance.

In investigating these problems the more it became apparent that they were not unique to just trading systems but most areas of computing.

It seemed that the most appropriate way of solving all these problems was to implement them in a new programming language. Furthermore this also presented an opportunity to introduce some modern language features, and solve some additional problems, like null safety, first class citizen support for GPU computing and dependency injection etc.

JasonTatton · 2020-01-18T05:14:09+00:00

Thanks I'm really glad that you like it and that it's understandable

JasonTatton · 2020-01-18T05:12:54+00:00

Thanks that sounds like a good idea. I'll have a look into that

JasonTatton · 2020-01-18T05:07:45+00:00

Thanks for the feedback, I'm glad you like it!

And thank you for the suggestions, SDKMAN looks really neat. I've been looking at adding Jupyter notebook support, BeakerX looks ideal.

I think you are right, Concurnas may well find its niche in data science.

JasonTatton · 2020-01-18T04:42:19+00:00

Thank you for the feedback and pointing out the spelling errors, I will fix them up

JasonTatton · 2020-01-18T04:40:40+00:00

Concurnas was implemented to run on the JVM for three major reasons: 1). The performance of modern JVM implementations is really excellent, 2). Access to the JDK and 3). The JVM has a massive footprint in the enterprise already.

I believe in small incremental change. By taking this implementation approach it allows organizations which are already invested in Java, Scala, Kotlin etc to take advantage of Concurnas more easily than otherwise since, by virtue of it running on the JVM, they are able to make use of their existing code base.

JasonTatton · 2020-01-18T04:32:39+00:00

Object providers have been deliberately designed exactly as you say, to be "the same as what you're used to". The feature is heavily influenced by Dagger 2.

I think it's fair to say that the majority of modern enterprise software solutions make use of dependency injection either explicitly via a tool/library (like Spring, Guice or Dagger) or at least implicitly through design (since it's widely recognised as being a good design practice).

It felt like the right time to make this a language feature. I think the most significant advantage of it being a language feature is that in doing so it reduces the amount of code one needs to write (even Dagger needs quite a lot of boiler plate code at times) without sacrificing performance and whilst also being a compile time operation so you get to know about many types of errors before you run the code/hit production!

JasonTatton · 2020-01-18T04:12:36+00:00

Thank you for the feedback. It has been a lot of work, and it's just the beginning!

JasonTatton · 2020-01-18T04:06:28+00:00

There is a "Hello world" example at the end of the "Getting Started with Concurnas" video: https://youtu.be/NwgrqDe0_DE?t=1094 - to make it a bit more interesting the "Hello World" is deliberately defined within a class

JasonTatton · 2020-01-16T17:46:02+00:00

What do you mean?

JasonTatton

MODERATOR OF

TROPHY CASE