Bitcoin Forum
June 23, 2017, 12:10:33 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: language of choice for a secure orderbook ?  (Read 1616 times)
anorphirith
Newbie
*
Offline Offline

Activity: 14


View Profile
February 01, 2014, 02:26:27 AM
 #1

what would be the language of choice to create a secure and relatively high volume orderbook used on an exchange ?
thanks !
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1498176633
Hero Member
*
Offline Offline

Posts: 1498176633

View Profile Personal Message (Offline)

Ignore
1498176633
Reply with quote  #2

1498176633
Report to moderator
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
February 01, 2014, 02:27:17 AM
 #2

C for the trade engine, and PHP compiled for the front-end

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
grue
Global Moderator
Legendary
*
Offline Offline

Activity: 1974



View Profile
February 01, 2014, 03:05:47 AM
 #3

PHP compiled for the front-end
python would be a better choice.

It is pitch black. You are likely to be eaten by a grue.

Tired of annoying signature ads? Ad block for signatures
empoweoqwj
Hero Member
*****
Offline Offline

Activity: 518


View Profile
February 01, 2014, 03:15:46 AM
 #4

If you are talking security, the language is relatively unimportant. Its whether you understand the security risks and guard against them. You can achieve this in several languages. For a speedy trading engine, certainly C.
rethaw
Sr. Member
****
Offline Offline

Activity: 378



View Profile
February 01, 2014, 03:54:17 AM
 #5

If you are talking security, the language is relatively unimportant. Its whether you understand the security risks and guard against them. You can achieve this in several languages. For a speedy trading engine, certainly C.

Best bet is to get some implementation. Most services fail due to lack of traction, not failure to scale.

cinderflame
Newbie
*
Offline Offline

Activity: 2


View Profile
February 01, 2014, 09:59:09 AM
 #6

If you are talking security, the language is relatively unimportant. Its whether you understand the security risks and guard against them. You can achieve this in several languages. For a speedy trading engine, certainly C.

Best bet is to get some implementation. Most services fail due to lack of traction, not failure to scale.

I concur.. C would be my choice as well..  Wink
coinrevo
Member
**
Offline Offline

Activity: 70


View Profile
February 01, 2014, 03:48:31 PM
 #7

I hear good things about Plankalkül these days. Its a bit old, but it has excellent support for electric vacuum tubes.

More serious answer: if you can't answer that question its a long road ahead. Essentially there are only 8-10 languages which cover 99% of the market. and for ultra high performance there are 4-5 choices: C, C++, Erlang, Skala, golang + maybe Java, C#.
empoweoqwj
Hero Member
*****
Offline Offline

Activity: 518


View Profile
February 02, 2014, 03:34:00 AM
 #8

Why not assembler? - that's well faster than even the best C++ compiler if properly written. It would just take 10 years to write  Cheesy
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
February 02, 2014, 03:58:39 AM
 #9

I hear good things about Plankalkül these days. Its a bit old, but it has excellent support for electric vacuum tubes.

More serious answer: if you can't answer that question its a long road ahead. Essentially there are only 8-10 languages which cover 99% of the market. and for ultra high performance there are 4-5 choices: C, C++, Erlang, Skala, golang + maybe Java, C#.

Maybe java? If you don't know most trading engines and blackboxes (Basically stock market trading bots) are written in java, the only reason I didn't say java was because C is the better choice. But if you are going with C++ and Erlang I would choose Java before them.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
daybyter
Legendary
*
Offline Offline

Activity: 965


View Profile
February 02, 2014, 03:43:56 PM
 #10

I also prefer java for some reason. The only reason, I would consider C++, would be operator overloading (I know: dangerous). But those BigDecimal statements just look ugly. Maybe Scala or some jvm language as a compromise?

empoweoqwj
Hero Member
*****
Offline Offline

Activity: 518


View Profile
February 03, 2014, 03:26:37 AM
 #11

I also prefer java for some reason. The only reason, I would consider C++, would be operator overloading (I know: dangerous). But those BigDecimal statements just look ugly. Maybe Scala or some jvm language as a compromise?


What's dangerous about operator overloading???
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
February 03, 2014, 07:19:32 AM
 #12

This is so very much the wrong way to ask the question. Figure out what your orderbook design will be, and how you will make it consistent at scale. Your strategy for that will determine what databases or locking frameworks you intend to use, and then look at which languages integrate best with that infrastructure.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
rethaw
Sr. Member
****
Offline Offline

Activity: 378



View Profile
February 05, 2014, 03:42:20 AM
 #13

Quote
"Best bet is to get some implementation. Most services fail due to lack of traction, not failure to scale."

can you elaborate on this ? what do you mean by lack of traction ?
thanks

Lack of traction means people not choosing to use it, and come back to it. If Mt. Gox had waited until they had a full featured socketed API, or DDoS protection, they may not have become such a popular exchange, for example. I would call this the businessman's answer.

This is so very much the wrong way to ask the question. Figure out what your orderbook design will be, and how you will make it consistent at scale. Your strategy for that will determine what databases or locking frameworks you intend to use, and then look at which languages integrate best with that infrastructure.

This is the engineer's answer.

empoweoqwj
Hero Member
*****
Offline Offline

Activity: 518


View Profile
February 05, 2014, 03:51:32 AM
 #14

Quote
"Best bet is to get some implementation. Most services fail due to lack of traction, not failure to scale."

can you elaborate on this ? what do you mean by lack of traction ?
thanks

Lack of traction means people not choosing to use it, and come back to it. If Mt. Gox had waited until they had a full featured socketed API, or DDoS protection, they may not have become such a popular exchange, for example. I would call this the businessman's answer.

This is so very much the wrong way to ask the question. Figure out what your orderbook design will be, and how you will make it consistent at scale. Your strategy for that will determine what databases or locking frameworks you intend to use, and then look at which languages integrate best with that infrastructure.

This is the engineer's answer.

Yeah, Gox have still got a dead slow trading engine, and they gone the full business cycle from roaring success to near collapse. Well done Gox!!
doof
Hero Member
*****
Offline Offline

Activity: 764


View Profile WWW
February 05, 2014, 09:54:04 AM
 #15

Language won't make much difference. The bottle neck will be at the database.  Depending if your models are just DTOs, or you add business logic in there or get SQL to aggregate on the fly or persisting aggregated values in SQL.

As your grow, you can improve performance by horizontal partitions, or using OLAP cubes to pre aggregate.  Use a cloud provider and just scale when required.  Hosting is cheap, developers are not.

The online retailer i worked for where doing about 4million rows a month in the order items table, without too much pain.
r3wt
Hero Member
*****
Offline Offline

Activity: 686


always the student, never the master.


View Profile
February 05, 2014, 10:00:02 AM
 #16

Language won't make much difference. The bottle neck will be at the database.  Depending if your models are just DTOs, or you add business logic in there or get SQL to aggregate on the fly or persisting aggregated values in SQL.

As your grow, you can improve performance by horizontal partitions, or using OLAP cubes to pre aggregate.  Use a cloud provider and just scale when required.  Hosting is cheap, developers are not.

The online retailer i worked for where doing about 4million rows a month in the order items table, without too much pain.

hmm interesting perspective, and i agree the bottle neck will always be the db, though i certainly don't have the experience to be making to many statements in this thread.

for the record, i'm using php compiled with hhvm executed from a shell script. pretty damn fast. takes a second to bitbash the trade table, then about 3 seconds to query all the wallets and check for new deposits.

My negative trust rating is reflective of a personal vendetta by someone on default trust.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!