[Announce] Project Quixote - BitShares, BitNames and 'BitMessage'

[AnonyMint]

2. Why C++ yuk!? If you used Scala (3 times less verbose than Java), and stub in C for performance only where needed (through the JNI), then I might contribute coding (maybe even for free) instead of creating my own altcoin. No way I am going back to 1990s with C++. Been there, done that.

See this from core developers discussion:

If I were doing it, I'd want to do the bulk of the implementation in bitcoinj of course, just because that's what most users are going to end up using (given current trajectories). It also has the advantage that using a managed language like Java eliminates entire classes of security holes, always a concern when writing financial software.

Note Scala is a better Java and runs on the JVM, so it is a managed language also.

[CIYAM]

So it's strange then isn't it that still the majority of banking and insurance back-end software is written in COBOL not Java.

(something to do with *security holes* like we are seeing with Java implementations perhaps?)

Am not really into language wars, however, recent *thefts* that have occurred have been due to Android and Java (not heard of anything similar in that horrible language C++ which Satoshi himself stupidly decided to use).

[AnonyMint]

Regarding gmaxwell picking on you upthread over the PoW algorithm, I just challenged his logic skills w.r.t. to anonymity.

Seriously gmaxwell is more knowledgeable about the details of crypto algorithms than I am.

[bytemaster]

Whereas, if the market value decreases 50% below the long position's deposited collateral, the miner issues a margin call against the long.

There is never any reason to call margin on the long.  The long isn't in 'debt' and the result of the price move is to increase the margin of the short.  As a result Longs only ever voluntarily sell.

[AnonyMint]

Whereas, if the market value decreases 50% below the long position's deposited collateral, the miner issues a margin call against the long.

There is never any reason to call margin on the long.  The long isn't in 'debt' and the result of the price move is to increase the margin of the short.  As a result Longs only ever voluntarily sell.

How is this not an arbitrary definition, given that the short is never in 'debt' either if there is no obligation to pay the long any more than the market value of the BitAsset?

So then where does the collateral of the long go?

How does the short profit?

[AnonyMint]

So it's strange then isn't it that still the majority of banking and insurance back-end software is written in COBOL not Java.

(something to do with *security holes* like we are seeing with Java implementations perhaps?)

Am not really into language wars, however, recent *thefts* that have occurred have been due to Android and Java (not heard of anything similar in that horrible language C++ which Satoshi himself stupidly decided to use).

As far as I know, security holes have been in libraries and Java code not in the JVM (Java Virtual Machine), i.e. it doesn't apply to Scala unless we use crappy libraries.

Code written in C++ also has security holes, just as severe and numerous as Java code if not more.

The difference is:

1. Managed code (JVM) removes a large class of security errors that you can make in unmanaged code like C/C++, e.g. buffer overruns and erroneous pointers.

2. Scala is 2 - 3X more concise than Java (and C++), and concise code enables clearer code study.

3. Using vals and pure functional programming concepts, a whole other class of security errors (referential transparency) are eliminated.

COBOL is still used because of legacy code, not because it is more secure (is it?).

And Scala is just a hell of lot more fun to program with  

The downside of Scala is if you don't restrict yourself to commonly known idioms, it is possibly to write code that no one can read except yourself (write-only languages are bad for open source). However, if you avoid the unnecessary use of such constructs, then Scala is more readable than Java.

P.S. I am working on a language that removes those constructs to limit Scala to a more readable subset. The name of my language is Copute and it is often even more concise than Scala.

[CIYAM]

1. Managed code (JVM) removes a large class of security errors that you can make in unmanaged code like C/C++, e.g. buffer overruns and erroneous pointers.

Perhaps you've never heard of std::string and std::auto_ptr (i.e. these problems were fixed back before the Java vs. C++ language wars had even really started and a big reason why I really don't buy the whole Java is safer argument).

You can't *overrun* a std::string (unless you're trying to) and std::auto_ptr's look after the memory and validate the pointers themselves - did you miss something?

COBOL is still used because of legacy code, not because it is more secure.

COBOL and DB/2 SQL (with pre-compiled queries) is used because it does *not allow anything dynamic* period (i.e. it is more secure than *anything* else available today).

Understand that it is simply *not possible* to do a SQL Injection attack when you use DB/2 pre-compiled queries (which is what COBOL apps normally do).

Also understand that I am a C++ programmer (and advocate) but I understand and respect what is used in banking and insurance industries because I spent years *working* with them (and no it's not just because of the legacy code being there - they can afford to get it re-written anytime they like just as they spent billions sorting out the Y2K issues with the COBOL programs they are still running today).

[AnonyMint]

1. Managed code (JVM) removes a large class of security errors that you can make in unmanaged code like C/C++, e.g. buffer overruns and erroneous pointers.

Perhaps you've never heard of std::string and std::auto_ptr (i.e. these problems were fixed back before the Java vs. C++ language wars had even really started).

That doesn't even catch half of the issues.

And it doesn't force you to use them.

In the JVM it is absolutely impossible to get a pointer and change where it points to in memory.

I wanted to say "Geez  " because of the way you scolded me for my suggestion to use Scala. I can be nice, if you are too.

Be careful with getting all pompous on me, I know my shit.

COBOL is still used because of legacy code, not because it is more secure (is it?).

COBOL and DB/2 SQL (with pre-compiled queries) is used because it does *not allow anything dynamic* period (i.e. it is more secure than *anything* else available today).

Understand that it is simply *not possible* to do a SQL Injection attack when you use DB/2 pre-compiled queries (which is what COBOL apps normally do).

Also understand that I am a C++ programmer (and advocate) but I understand and respect what is used in banking and insurance industries because I spent years *working* with them (and no it's not just because of the legacy code being there - they can afford to get it re-written anytime they like just as they spent billions sorting out the Y2K issues with the COBOL programs they are still running today).

So write a Bitcoin client in COBOL please?

It is more secure for its narrow area of applicability because as far as I know, COBOL can't realistically be used to program generally any kind of personal computer application. Thus, it isn't any more secure for the things we need to program.

And here you are making the argument for managed code, not against it.

Also you did not address my points #2 and #3.

[CIYAM]

That doesn't even catch half of the issues.

So this is just getting pointless - now your argument has conveniently changed into one that I can write *shit* in C++ - so I can't possibly write *shit* in Java?

(again - the only BTC lost though shitty programming seems to be via Android and Java - nothing from C++ but of course I *must* be wrong so please correct me)

So write a Bitcoin client in COBOL please?

It is more secure for its narrow area of applicability because as far as I know, COBOL can't realistically be used to program generally any kind of personal computer application. Thus, it isn't any more secure for the things we need to program.

I made the point in regards to *financial software* (traditional banking and insurance apps) and as stated I am a C++ guy first and foremost.

Once again I would just like to ask - if Satoshi posted here again would you criticize him for his (according to you) *stupid* use of such a *crappy* language?

In regards to Scala I know nothing about it so am not qualified to comment about it (apart from to say that languages are languages - there is no *perfect* one).

[bytemaster]

I assume that long and short owners can sell their position at any time thus transferring it to another keyname (i.e. anonymous entity)?

Yes, and they are divisible and have all of the properties of Bitcoin.

Can the short and long enter an algorithmic contract to exit the position at a preset expiration date?

Yes, Options also work this way.

8. What is the redeemable concept? Do you mean to say the long or short can close their position at any time without permission of the counter-party? How can that be fair?

Aside from margin calls, positions can only be closed by finding a buyer and trading out of your position.  Fortunately the market is liquid and all BitUSD is fungible.

9. In the margin call, the BitAsset is destroyed, so what happens to the collateral of the counter-party which did not receive a margin call? If it goes to them, why are they forced to redeem their BitAsset prematurely? Wouldn't a better design be let the BitAsset remain for the counter-party? Also why does the redeemed money go to the dividend pool (for that BitAsset or all BitShares?) and not to counter-party, so that the counter-party gets some leverage?

When a short 'covers' their position they do so by BUYING the BitAsset on the market using the collateral.  Thus some owner of BitUSD is now the proud owner of the some of the Bitshares held as collateral based upon the price. Any left-over collateral is returned to the owner of the short position.

There is the risk that the market value moves to more than 100% of one-side of the collateral before than the miner can issue the margin call. There is no default here, it is just the redeemed money is not as great as it should be. If the redeemed money was going to the counter-party instead of the dividend pool, then the counter-party would lose some real-time time-preference, but this isn't designed to a be a real-time trading system any way.

First of all, BitUSD is composed of 1000's of positions entered at different prices by different people.  The price would have to fall 50% in 5 minutes and even then there are no losses because the collateral would still be able to purchase the BitUSD at market price.   Obviously the short positions would be entirely wiped out in such a rapid movement in price as they are forced to buy as much BitUSD as their collateral will allow and bid up the price in a short squeeze.  Worst case outcome is that some people will end up with BitUSD with no backing at all and thus 0 interest.   Fortunately, new BitUSD is always being created as new shorts / longs enter the game and the new BitUSD would be fungible with the old so only someone attempting to sell BitUSD in a very narrow window may face a discount to face value.  Because market forces always push the price back toward parity, speculators would readily buy up BitUSD at a slight discount created during such an insane price move.  

11....  It is presumed that the market will try to maintain the market value of the BitAsset proportional to the price changes in its designated asset.... then the expiration period should be relatively short...

There is no reason to ever have expiration on longs (see above).

But couldn't a miner also exclude bid and asks, thus manipulating the market price? This appears to be a major flaw in the design.. I don't have idea for a solution yet.

A miner could exclude a new bid or ask in the most recent block, but would be unable to do anything about limit orders placed in prior blocks that were not filled.  The miner will always have a slight advantage in picking which bids get into the block chain and thus how the price moves in the 5 minute window of the block they win.   But in a given 1 hour window, there will be 12 different miners who win and they will have different goals with respect to which way they want the price to 'move' based upon their individual position (short or long).    The reality is that the offers placed on the block chain are generally spread in a collar around the current bid ask and therefore the order book will be full on both sides of the trade at the start of mining.  No single block would be able to budge that order book by more than the 'new bids/asks'.    So margin calls will be based upon a wider bid/ask spread than the 'real-time market'.  Most people who care about price fluctuation in time periods of less than 1 hour should be trading on an Open Transactions exchange that is funded with BitUSD / BitShares.    

I suspect that the small market advantage garnered by generating a block would further motivate miners and ultimately help secure the network.   Of course, the reason why decentralizing the hashing algorithm is important is to keep a large percentage of the hash power in the hands of non-professional miners and thus limit the ability to control the market by any one actor.

Why canceling bid/ask takes 24 hours when blockchain becomes secure after roughly 6 blocks, e.g. 60 minutes?

Any action that could be taken by a miner must wait for the 'chain reorg window' to pass.  Bitcoin currently uses 100 blocks before miners can 'spend' their rewards because during a re-org, decisions of the miners based upon then-current prices are no longer valid.   If I cancel my order and then a re-org occurs, a miner in the reorg may have executed my order prior to the cancel.     Obviously, re-orgs are a risk for any trade executed by a miner and those that care about having instant spends should use the off-chain system to exchange and sign an atomic transaction that could survive a re-org.   This is another example where the only bids/asks that will end up in the block chain are the 'open orders' / backlog that will only be executed if the price moves significantly (1% or so) in one direction or another.  

14. Dividends allow idle capital to not invest in mining, we want to maximally secure the blockchain.

We want the minimal security required to prevent chain forgeries and ensure things are decentralized.  You don't go around paying for the MAXIMUM security for your house because after a while additional security has a marginal ROI.  Dividends provide the following benefits that ultimately improve security of the network:

1) then encourage saving and value accumulation within the chain.
2) they create an incentive to bring the unwashed, greedy, masses such as Grandma, into the system because they can get a better ROI than their bank with a better risk profile.  
3) having a relatively secure way to generate passive income will help make this go viral
4) increased adoption means more small time users, each of which can profitably mine with their CPU, and thus there will be more hash power in the network.



Thanks for all of your feedback, it is nice to see some deep conceptual thinkers picking through the paper and design.!






 

[bytemaster]

That doesn't even catch half of the issues.

So this is just getting pointless - now your argument has conveniently changed into one that I can write *shit* in C++ - so I can't possibly write *shit* in Java then?

(again - the only BTC lost though shitty programming seems to be via Android and Java - nothing from C++ but of course I *must* be wrong so please correct me)

So write a Bitcoin client in COBOL please?

It is more secure for its narrow area of applicability because as far as I know, COBOL can't realistically be used to program generally any kind of personal computer application. Thus, it isn't any more secure for the things we need to program.

I made the point in regards to *financial software* (traditional banking and insurance apps) and as stated I am a C++ guy first and foremost.

Once again I would just like to ask - if Satoshi posted here again would you criticize him for his (according to you) *stupid* use of such a *crappy* language?

In regards to Scala I know nothing about it so am not qualified to comment about it (apart from to say that languages are languages - there is no *perfect* one).

Guys, language choice is a holy war and not productive debate for this thread.    All I will say on the subject is that making asynchronous applications easy to read and develop is hard.  Designing software that can handle the number of async connections, encryption demands, database demands, and memory demands of a block-chain that is running at full capacity (1 MB of trx every 5 minutes) with the ambitious goal of operating in the background as an always-on app like your email client means that picking a language with a lot of overhead would be enough to push us over the threshold that is ambitious to achieve even with optimized with C++.  Fact of the matter is, native C++ apps with Qt provide a better user experience than apps built with a host of other languages where your cross-platform support is limited by the availability of a runtime environment.   Runtime environments represent a source of bugs and security holes that are unacceptable for this application.     Even if you assume all of these things are a wash, as the primary developer C++ is the only option for the core code because I can write the best code in C++.    THe core components can be compiled into a library and then provide bindings to any language. 

If you think that Scala is so much faster to develop in, then you should be able to catch up to the work I have done in the past 6 weeks within a couple of weeks.   I would gladly work with you to define an open over-the-wire spec and if you really can get the kind of improvements you are talking about and can catch up then that would be great.  In my experience though, those types of gains are mostly on paper.

[AnonyMint]

That doesn't even catch half of the issues.

So this is just getting pointless - now your argument has conveniently changed into one that I can write *shit* in C++ - so I can't possibly write *shit* in Java then?

You completely missed the point. Try reading again.

(again - the only BTC lost though shitty programming seems to be via Android and Java - nothing from C++ but of course I *must* be wrong so please correct me)

Everyone who breathes eventually dies.

Correlation is not cause and effect.

If those who code in C++ did not use the bad libraries that caused the problem, does not mean that coding in C++ is inherently more secure (and not less secure).

Also the sample size is way too small to make any statistically relevant conclusions.

And the main issue here is to write a lot of compelling s/w as efficiently (quickly, correctly, etc) as possible.

Scala fits that bill better than C++ if we are evaluating purely on the productivity of an expert Scala programmer vs. an expert C++ programmer.

However, we have to factor in there are a lot more C++ programmers than Scala programmers. And the learning curve for those who don't know Scala.

And factor domain specific expert knowledge (in this field) may be reside more amongst C/C++ programmers.

Yet more programmers does not always trump the quality of the best few programmers.

In any case, I was only sharing my personal opinion of what I would contribute to. You did more than share back your personal opinion of what you would contribute to. You thought you could scold me, yet you got caught with bad logic. You deserve the embarrassment because your intentions were to embarrass me, but it backfired on you.

So write a Bitcoin client in COBOL please?

It is more secure for its narrow area of applicability because as far as I know, COBOL can't realistically be used to program generally any kind of personal computer application. Thus, it isn't any more secure for the things we need to program.

I made the point in regards to *financial software* (traditional banking and insurance apps) and as stated I am a C++ guy first and foremost.

We are writing altcoin clients here with networking, bit twiddling, GUIs, etc.  

Once again I would just like to ask - if Satoshi posted here again would you criticize him for his (according to you) *stupid* use of such a *crappy* language?

I would express my opinion that I would not wish to code in C++ ever again after learning Scala.

It is like going back from C to assembly language. I wrote 5MB of 68000 assembly language for my WordUp before C arrived on my radar.

In regards to Scala I know nothing about it so am not qualified to comment about it (apart from to say that languages are languages - there is no *perfect* one).

Imagine the assembly programmer who never tried C.

[CIYAM]

I think I'd have to agree with bytemaster that this had crossed into "Language Wars" which is not productive for anyone (so will not further it with more fuel).

If you have found your nirvana with Scala then I am not against that at all - so please don't argue that my nirvana with C++ is somehow *inferior*.

Enjoy your programming and *change the world* - that is what we are really striving to do here (rather than win a silly argument about which compiler/interpreter/parser is the best).

We are really only going to have the greatest influence by working together rather being at each others throats about our choices of computer languages.

[AnonyMint]

I think I'd have to agree with bytemaster that this had crossed into "Language Wars" which is not productive for anyone (so will not further it with more fuel).

If you have found your nirvana with Scala then I am not against that at all - so please don't argue that my nirvana with C++ is somehow *inferior*.

Enjoy your programming and *change the world* - that is what we are really striving to do here (rather than win a silly argument about which compiler/interpreter/parser is the best).

We are really only going to have the greatest effect by working together rather being at each others throats about choices of computer languages.

I agree let's work together.

I will just say it is hard for people who learn Scala to go back to C++, just as it would be painful for you to go back to ASM or only C.

Languages do progress.

[CIYAM]

Well you have piqued my interest in finding out about Scala but I think that after more than 15 years of C++ programming I am probably not the right person to become a convert.



(maybe we can end the OT language stuff now and get back to what I think could be a very interesting project)

[bytemaster]

Discouraging domain squatting is also a good thing.

I have been involved with domain for over 15 years.  I can absolutely assure you that there is no way to even define "domain squatting."  Waiving your hand and claiming to discourage things are really "feel-good" statements and there is no way to actually do it in practice.  Even if there was a way I don't want a system that replaces a "nanny state" with "nanny developers."  If you ever hung out with anti-spam people you will know what I mean.  If they had their way they would eliminate just about every privacy law there is and cut half the world off from the Internet in their pursuit of stopping spam.  Sure, you can say discouraging spam is a good thing and most will agree but just try to actually do it without disrupting things.

Domain squatting is a creature of price fixing combined with first-come, first-serve awarding of names.   The goal is to maximize the economic utility of each unique piece of real estate.  In my approach, imagine all available names as being real-estate in the New World.  No one knows which acres have gold, oil, or nice views until they can be explored.   It is absolutely ridiculous to create a system where all lots are the same price and then sell them all to the first person in line.    To solve this problem I have created a name crypto-currency that acts as 'stock' in all names and owners of this stock make a profit anytime a name is sold.  To ensure proper price discovery names are auctioned.   The result is that the most profitably way to 'squat' is to own the crypto-currency because it sees almost all of the profits from every name actually sold and no need to tie up capital in names speculatively.  It puts everyone on a equal playing field in the domain squatting game because whether you have $100 or $1M to invest, you can get the same rate of return by investing in 'unclaimed' names via owning 'stock' in the crypto-currency.

My motivations are always economic and never about 'social justice' or redistribution for 'feel good' or 'nanny' reasons. The goal is efficient allocation of resources and profit while avoiding socialist concepts of 'fair prices', price fixing, and other economic policies.   THe result is a better system that can compete on the market, not 'nanny developers'.

[CIYAM]

I think the domain squatting problem is an interesting one - few (apart from Aussies) would know about the whole Burger King vs. Hungry Jacks issue (someone incorporated a company called Burger King in Australia before the USA chain tried to do so).

Strangely enough even after "Hungry Jacks" finally got back its name ("Burger King") in Australia - it failed as the name "Hungry Jacks" had become more popular (so they closed down the one and only "Burger King" in Melbourne only about a year after opening it and just continued under the name "Hungry Jacks").

This was some years back though so am not sure if they have managed to change the public perception since then but it does show that a name is really only as important as the publicity that surrounds it (as an Aussie I hadn't even *heard* of the name Burger King until I learned about the legal case and didn't even initially know that "Hungry Jacks" == "Burger King" as I am pretty sure many other Aussies would also not have known).

[bytemaster]

Btw, I think I may have already solved the level playing field for GPU/ASIC-resistant PoW (some details buried in my posts, no code written yet). I see you are coming closer to my ideas on that since the astute (obviously very intelligent) core Bitcoin developer Gregory Maxwell challenged you.

I would love to hear what you have to offer in this area.

[charleshoskinson]

Scala fits that bill better than C++ if we are evaluating purely on the productivity of an expert Scala programmer vs. an expert C++ programmer.

However, we have to factor in there are a lot more C++ programmers than Scala programmers. And the learning curve for those who don't know Scala.

Yet more programmers does not always trump the quality of the best few programmers

I'm most comfortable with python and Haskell. I think everyone has a pet language and honestly If I could choose any language for this project, then I'd choose Go: https://en.wikipedia.org/wiki/Go_(programming_language). I've used Scala and I actually met Martin Odersky while at a conference in Switzerland. I really believe Scala is an amazing language and I'd highly encourage anyone interested to take Martin's course on Coursera: https://www.coursera.org/course/progfun.

But here's the reality, I'm a CEO and we are running a business with timetables and talent pools. Daniel, and others on the project are experts developing in C++ all with over ten years of experience. It's my job to best use the resources I have at hand and the community has at its disposal. If we choose C++, then we can write code from day 1 and it will be solid, secure code conforming with the best practices of software engineering. If we choose a new language, then we have to spend resources learning it. I just can't justify the months it will take to migrate.

[AnonyMint]

Well you have piqued my interest in finding out about Scala but I think that after more than 15 years of C++ programming I am probably not the right person to become a convert.



(maybe we can end the OT language stuff now and get back to what I think could be a very interesting project)

Allow me one more transgression on OT.

Scala is much more concise (lots of boilerplate you don't need to write), even on common patterns. For an example of more high-end pattern, see the convoluted C++ templates required to emulate higher-kinds. An important use case of higher-kinds is concisely explained on this page.

Higher-kinds are all about code reuse, which is very important if we want to build a lot of varied s/w faster and more correctly (less bugs), but that is probably going to be difficult for you to get a mental picture initially. In practice, it is very elegant once you play around with it.

The conciseness of Scala is not hinged only on such an esoteric concept of higher-kinds.

Guys, language choice is a holy war and not productive debate for this thread.    All I will say on the subject is that making asynchronous applications easy to read and develop is hard. Designing software that can handle the number of async connections, encryption demands, database demands, and memory demands of a block-chain that is running at full capacity (1 MB of trx every 5 minutes) with the ambitious goal of operating in the background as an always-on app like your email client means that picking a language with a lot of overhead would be enough to push us over the threshold that is ambitious to achieve even with optimized with C++.

Scala (under TypeSafe) is especially targeting this with their Akka library. Twitter uses Scala because it scales better to such real-time, asynchronous needs.

Besides, it is well known that profiling is and hand-coding only 5 - 15% of your application in C/C++ is a more correct and efficient paradigm than unnecessarily writing the entire uncritical sections of the program (usually the majority) in low-level code (C++ is low-level from my stance now).

On language shootout tests Java and Scala are usually within 2 - 3X of C/C++ speed, but this doesn't matter for most of your code. Only a few sections of your code are the limiting factor.

Whereas, being much more productive with the bulk of your coding is the big win of high-level semantic language programming.

Fact of the matter is, native C++ apps with Qt provide a better user experience than apps built with a host of other languages where your cross-platform support is limited by the availability of a runtime environment.   Runtime environments represent a source of bugs and security holes that are unacceptable for this application.

Does Java (JVM) not have the necessary runtimes, or all them inferior to Qt?

Even if you assume all of these things are a wash, as the primary developer C++ is the only option for the core code because I can write the best code in C++.  THe core components can be compiled into a library and then provide bindings to any language.

Agreed the languages preferred by the core developer(s) is crucial. I made that point also before reading your post.

And yes one could write portions in Scala/Java and the core in C/C++. You probably know is best practice to put an API between your core library and the GUI code any way (even if you use C++ for both). Then anyone could code another GUI in any language they want and call into your native code API.

If you think that Scala is so much faster to develop in, then you should be able to catch up to the work I have done in the past 6 weeks within a couple of weeks.   I would gladly work with you to define an open over-the-wire spec and if you really can get the kind of improvements you are talking about and can catch up then that would be great.  In my experience though, those types of gains are mostly on paper.

I am too slow on domain specific knowledge w.r.t. this field. I have the big picture, I am a good coder, and I am good with details, but I haven't been in this field long enough, so my domain specific gap exists. I learn fast, but not fast enough to catch up with you if you are already coding.

I may be interested to contribute to a C++ code if it is 100% modularized by an API away from the GUI and other support code. So then I could reuse it, if I decide create a Scala version.

Scala fits that bill better than C++ if we are evaluating purely on the productivity of an expert Scala programmer vs. an expert C++ programmer.

However, we have to factor in there are a lot more C++ programmers than Scala programmers. And the learning curve for those who don't know Scala.

Yet more programmers does not always trump the quality of the best few programmers

I'm most comfortable with python and Haskell. I think everyone has a pet language and honestly If I could choose any language for this project, then I'd choose Go: https://en.wikipedia.org/wiki/Go_(programming_language). I've used Scala and I actually met Martin Odersky while at a conference in Switzerland. I really believe Scala is an amazing language and I'd highly encourage anyone interested to take Martin's course on Coursera: https://www.coursera.org/course/progfun.

But here's the reality, I'm a CEO and we are running a business with timetables and talent pools. Daniel, and others on the project are experts developing in C++ all with over ten years of experience. It's my job to best use the resources I have at hand and the community has at its disposal. If we choose C++, then we can write code from day 1 and it will be solid, secure code conforming with the best practices of software engineering. If we choose a new language, then we have to spend resources learning it. I just can't justify the months it will take to migrate.

Agreed. Understood. That is why I mentioned those other factors to consider.

I found many flaws in Go. I will find my link.