For what it’s worth, I write Scala for a hedge fund as my job. I find it’s actually really good precisely for modelling all sorts of complex financial situations with lots of numbers all meaning diffferent things flying around, thanks to its strong type system and easy introduction of “newtypes”, lightweight (or no-weight in the case of AnyVal) case classes whose only purpose is to tag e.g. an integer or BigDecimal with a domain-specific type. You can then define your business logic in terms of operations on these higher-level objects more specific to your actual domain.
mjadczak
1
dimitarvp
Well, Erlang has been around for 30 years already.
But in Erlang/Elixir you’ll end up writing almost everything from scratch. There were efforts and ideas about it but let’s be real: without real funding and somebody’s livelihood depending on coding that, nothing will happen. We all have jobs to do and families to support. And free time to enjoy.
Outside of that, either Solidus (Ruby isn’t a very good idea for the scale you’re looking for) or Java – although scale might be a problem there as well.
I’d naively pick Elixir and work my way through the difficulties, asking first if I’ll get guaranteed 3 years of funding first. Erlang/Elixir are technologically best equipped for the scale and longevity you’re looking for. But again, it’ll be a custom-tailored and hand-crafted solution.
2
mmmrrr
Hey Sammis,
before giving any technical advise, or seeking technical advise, I would always recommend to lay out the requirements as precisely as possible.
You state that
Let me put it this way: maybe. But this is most certainly not your real concern right now. Every choice you can make will inavitably have its downsides.
So the real questions are:
- Why is money a problem? If you’re going to do business for 20-30 years you need to make millions yourself with this enterprise. So if money is a problem now, developing from scratch is maybe not a smart option.
(That beeing said: economically it makes sense to keep costs down. Just remember that licensing costs will almost always be lower than development costs if you can get the same system. This is true for almost any part of the world) - What are you up to? Are you a startup? Are you a development department or agency for a company that wants to expand or change its business? Is this a public government sector type of thing, where paying people is not a problem because they are “there anyway”?
2b) How many people will be working on the project.
Pointing to any particular technology is not doing any good, without answering at least question 2). Because it massively depends on what to optimize for.
That beeing said: if you are sure (and I mean absolutely, rock solid, super dooper, “I have seen the contract” sure) that this project will be very long running you need to optimize for one thing: changeability / refactoring. Don’t hardwire stuff, keep everything as separated as possible. Create clean APIs that stabilize fast and don’t change. Keep the scope of every part of the system as small and focused as humanly possible.
This advice is, I think, universal for large systems and does not depend on any particular technology. Just like: try to introduce as little side effects as possible and only in well defined and understood places.
So, if you can, please give us a little more info about your project 
(Not that I don’t enjoy a good technology discussion but I think this isn’t helping OP as much 
)
7
Sammis
OvermindDL1
Those are still HM level types though, meaning actually dealing with the monetary values has to be done in runtime code. As a basic comparison take Idris, where you can enforce how the money values change in the type system itself (not just the money type, but rather how it changes), or a not near as powerful Rust where the refined typing can ensure that money is not mishandled at runtime (that is of course if you use rust’s typing system for that), neither of which Scala’s types handle.
Still though, I entirely state that use something off-the-shelf that is well tested and well used.
1
Sammis
mmmrrr
Thank you for your insight.
This is really great advice I am receiving.
Much appreciated.
0
Sammis
mjaric
If I were you, I would start with language and database I know the best. If you are learning language now then you will be lost for some time doing nothing about your business nor building your sales skills.
- Define what is your MVP,
- set KPIs
- do MVP it (implement) and then release it and see what happens.
- Do some cheap marketing, e.g. put some $ on FB adds and wait for result. Check what audience is best for you and then add more $ just for such audience. Open FB page, Instagram or what ever is popular thees days.
At some point, you will see that you are spending 10 grades more on marketing than on licenses and infrastructure. But that marketing money is returned in revenue probably. If you do this carefully you will quickly build some value. Then go with this value to some investors and present it and give 15-30% of your company so you get funds, BUT prepare new plan how you will spend that money to create bigger value.
As you see above, only one point is about coding.
If you are still concern about what platform and tools to use, I can say from my 20 years experience that every company I worked for or consult, had smaller or bigger platform change at later point, did some “rewrite” in same or new language or add new service using new platform. What so ever, people that should work for your company (developers) will always try to find new DB engine or language to replace current. Luckily the change happens rarely otherwise it would slow down business development.
2
mjadczak
(This is getting offtopic so perhaps a thread-split is in order.)
I do quite a bit of Rust on the side, and I love it, but I actually don’t see how its type system would be superior for the types of business logic problems that we solve. In fact, the couple of feature of Rust that I occasionally miss in Scala are the Result type (but mostly just because it’s consistent across libraries) and move semantics—I’d love to be able to express that a function uses up a value and it can no longer be accessed—but even then that mostly comes up when I’m interfacing with some mutable outside Java thing. Neither of these are really a property of the type system. I can do ADTs/enums (sealed trait), I can do traits (“typeclasses” aka implicits), and even some more heavyweight functional stuff with scalaz (though only a few projects use that).
I’m not sure what you’re picturing exactly when you say
Rust where the refined typing can ensure that money is not mishandled at runtime
—do you just mean that I won’t e.g. add 100GBP to 100USD? That I won’t accidentally mix up balances on two different accounts? Because all of those things we can ensure with Scala, with e.g. overloaded operators. Yes, the checks happen at runtime, but I really don’t think they could happen statically, because all of this data is only seen at runtime, and we cannot make static assumptions about our data sources, because they are sometimes unreliable. I’m no expert with Idris or other languages with real dependent types, so perhaps I am missing something there, but no matter what the compiler / type checker must work with static information only, and I’m not sure whether we could capture any more static information about our domain using dependent types, than we already do.
If what you mean by the fact that Scala doesn’t “guarantee” this things is “if you tried, you could write code which would compile and do the wrong thing”, e.g. by explicitly extracting 100 from the object representing 100 USD, and another 100 from the object representing 100 GBP, and adding them together, and packing it back into a 200 USD object, then sure, I agree. However, we have the luxury of a reasonably small team of extremely competent people and always doing code review, and we enforce disciplined code which does things the “right way”, to allow all of the necessary checks to occur.
I do have complaints about Scala, but they’re pretty much all about the JVM itself, or the ecosystem (Akka is extremely painful after having programmed Elixir), and not the type-system.
0
OvermindDL1
Hmm, perhaps, I’ll keep succinct for this:
Not at all, that is enforced via standard HM typing, pretty trivial. The harder parts are things like enforcing not performing improper math on the values, like taking $2.53 and dividing it by 2, it is super easy to forget things like the half cents in each and that you actually need to pick a place (still can be done via HM though enforcing usage is not), and things like the move semantics (which is part of the refined typing since it linearizes the usage of a type) so you can’t do something like accidentally add a payment twice or deduct $50 from a $60 account twice in two different threads (since you can’t forget a synchronization primitive for example on your type access).
Idris on the other hand goes far far beyond. Dependently typed type systems not only hold type information (HM typing), and linearized types and all that, but far far more, including even having knowledge about the values that will be held at runtime. The prime simple example of a dependently typed language is a language that can take something like a list that you can pass into, say, a head/1 function, and it will fail to compile unless you verify that it is not empty, and that check is not a check built in to the language, those are checks you can ‘build’ on any type. In essence it lets you program in the type system, thus making check and bounds that are impossible otherwise. Why something like Idris and Coq are so useful for monetary systems is that they can absolutely prove the flow of a value through a system, ensure it is only accessed properly, that nothing is forgotten about, and I’m still only scratching what a full dependently typed language can do.
Now because the types are so powerful in dependently typed languages the programs also tend to be a good bit bigger, with type signatures that are…impressively large to put it mildly, but once it compiles you can be sure that not only your types are correct in their usage but you also aren’t breaking any potential runtime logical contracts either.
You have this ability now, but will that remain in the future? What if Scala finishes dying off (it almost has really…) and they start writing interface code in Java or Kotlin then? A small team of competent people ‘now’ does not equate the same to the maintainers in the future, and over a multi-decade timescale spoken of prior, then I’d still vote on grabbing a pre-made, very well tested and used prior-existing product instead.
(I do like Scala, much more so than Java or Kotlin, it just doesn’t have much backing anymore…)
3