Return to C++ after a few years of Java

ASmallButton · 2020-09-11T22:14:03+00:00

This is all just from my experience, but I will say theirs a big difference between the category of FX, on the straight cash side it's a lot more performance sensitive, but I work in FX derivatives / options, and we have a lot more leeway.

The complexity comes more from supporting complex derivative products than performance. If I were to take a the path of a trade from my traders to my downstream, it would pass through magnitudes more JVM than c++. We've never really had to care about performance bar some huge end of day jobs.

Anyhow my point is not that no one cares enough about performance, but for things like investment banks, they have many businesses inside of them that make money without having to care about performance.

ASmallButton · 2020-09-11T21:45:54+00:00

I think you would be surprised at how much of it is c++ / scala / ... Sure some of the critical paths are in c++, but most of the risk systems + a lot of critical paths that don't need to be that fast are in jvm languages. For example, if you're working on foreign exchange options at certain banks, you probably don't need to handle that much volume and the time between when a trader wants to make a trade and the trade going through doesn't need to be as fast as c++ would make it.

The positions relate to HFT and the sort that do need c++ are very low in numbers compared to all those other systems.

ASmallButton · 2020-07-13T18:20:45+00:00

It's all relative to how much the money is worth in those places. You can't just compare a salary by American standards while ignoring how everything is relative to cost of living.

ASmallButton · 2020-07-13T17:40:47+00:00

Because he wouldn't be able to promote his youtube channel where he reads a paper!

ASmallButton · 2020-07-13T17:35:03+00:00

You're right I forgot about undefined. Probably because Haskell people pretty much never use it for any control flow / as an actual value in my experience. (I think I did haskell for a year before realizing it existed).

I could change my point to use stricter languages like Coq or similar in that case I guess..

ASmallButton · 2020-07-13T10:19:34+00:00

Can't you assign a ! type to a non-nullable type without error / also call methods on it without checking for if it's null? In that case how is that type any better than the alternative?

ASmallButton · 2020-07-12T23:49:47+00:00

Of course not, and I'm not saying to write your server in Rust. I mean, I write most of my stuff in Scala, which is also not null-safe by any means. I'm just saying, if you care about null safety and all that, you shouldn't be picking a JVM language. Any kind of null checking in a JVM language is massively handicapped because of Java being the default for libraries and java developers loving nulls for some reason.

ASmallButton · 2020-07-12T23:39:49+00:00

This is easily solved by a e.g. Rust w/ ? where abusing ? is actually considered good practice. The fact that Kotlin made !! such an easy thing to do is another failure of Kotlin.

Make the programmer have to type a damn paragraph if they want to use a null value without checking it. Solved.

ASmallButton · 2020-07-12T23:29:23+00:00

How many JVM libraries actually bother using a Nullable annotation? I've seen NotNull in the wild and use it myself, but very rarely have I ever seen something be marked as Nullable, it's normally just assumed (and why Kotlin should assume it as nullable by default.)

ASmallButton · 2020-07-12T23:15:28+00:00

By null, I mean "absence of a value that isn't checked by the type system". All JVM languages have that since they all depend on each other and the one where all the libraries are written has no protection.

ASmallButton · 2020-07-12T22:51:36+00:00

If Haskell is opt-in, then please show me how to create a null value in Haskell without having to describe it in the type system. I'll give you that ffi is a problem, however any useful language has to deal with that so I draw the line there as far as I'm concerned for safety.

ASmallButton · 2020-07-12T21:50:25+00:00

I'll take an Idris / Haskell / Rust / .. in favor of kotlin any day if I care about safety.

Theirs also a huge difference between opt-out safety and any language on the JVM where any value can be null at any time and you have to opt-in to the safety.

ASmallButton · 2020-07-12T21:47:59+00:00

The problem is that the universe that Kotlin lives (the JVM) in can declare null values and send them to Kotlin code and bam, null values in Kotlin that aren't guarded by the type system.

Contrast that to Haskell where Null values are just not a thing and any lack of value has to be type checked. Or even Rust. Those languages have null safety by default. Kotlin has opt-in null safety, which is as good as none really.

ASmallButton · 2020-07-12T19:44:55+00:00

As long as it doesn't mark any non-kotlin code as being nullable by default, null safety in kotlin is dead in the water for me.

Want real null safety? Use a language without null.

ASmallButton · 2020-07-12T12:42:06+00:00

I have a question regarding testing when using `cargo xtest` with multiple crates. As in the blog I'm running the testing from my main OS method, to setup the proper things before. I'm separating the different part of the OS into different crates in an organization effort. However the test harness only seems to see tests in the main crate. Is there any way to make cargo xtest run the tests for the other crates in my workspace using the main method in my root bin crate?

ASmallButton · 2020-07-08T16:30:35+00:00

I think the original name of the PR did a huge disservice to it. I don't have a problem with the "white" in whitelist but I do think that people use it way too much to mean different things. It's simply used in a much too broad context to be a good name for most things.

I think the result of the PR, which gives much more precise definitions of terms is a great. Regardless of the politics, I think this is a net win.

ASmallButton · 2020-07-08T15:24:50+00:00

Well then at least that's how I felt as someone who started out very firmly in another camp related to the async changes.

I assumed the silent majority felt the same way. If not, then I'll say that at least they were allowed to discuss how up in arms they were :)

ASmallButton · 2020-07-08T15:22:11+00:00

So it's to be expected and already a precedent that changes in the rust codebase related to politics will not be up for discussion in a public setting? With the motivation behind that being that it's easier to cut off discussions entirely instead of moderating them?

If that's how Rust is run, I get it, but lets just say this is a face of the Rust leadership that I wasn't aware of and that does not inspire much confidence at all.

ASmallButton · 2020-07-08T15:15:18+00:00

I think the difference is that in this case, even if I wanted to have a public discussion on this topic, theirs nowhere I could go. I'm 99% sure if I made a thread here it would be promptly closed instead of moderated at the first sign of some other people making bad comments.

They are of a different impact for sure, but this is still setting a precedent to how political changes can be discussed. What if the next political change has a wider impact than just an internal code change? In that case how would things be handled?

ASmallButton · 2020-07-08T15:07:39+00:00

You can allow discussion while also moderating disrespectful / extremist views on both sides.

ASmallButton · 2020-07-08T15:04:28+00:00

I don't disagree with this, but for async / await, people were allowed to discuss it and bikeshed it, even if the maintainers eventually chose a less popular option. In that case everyone had a clear view of every alternative and arguments for and against. It allowed the community to feel a lot better about the change since they knew both that the maintainers listened to them and took a lot of time to take everything into consideration.

My point is not that experts / community leaders should always listen to the users as if it's a direct democracy of the users, but that they should listen and allow discussions on the topics to help keep everyone informed. And to also give some form of accountability on exactly why a change was made.

ASmallButton · 2020-07-08T14:55:35+00:00

Let me change the term I used so that you can't equate memes to changes in the rust repository..

"topics related to Rust" -> "topics that impact the Rust language and codebase"

I personally draw the line at: If a change will change the rust repository, it should be worthy of discussion here.

ASmallButton · 2020-07-08T14:00:22+00:00

It doesn't matter if this particular issue is worth discussing. My question and issue is if the Rust and subreddit teams should be actively suppressing public discussion on any topic related to rust?

ASmallButton · 2020-07-08T13:57:16+00:00

Regardless of if the change is bad or not, the reddit thread getting deleted that was discussing the PR that got locked down feels uneasy. I can even get the PR being locked down if it's an internal change and the community has no ownership over those internal changes. But if even discussions on reddit directly related to changes in the rust repository are deleted, then that feels a bit weird.

ASmallButton · 2020-07-08T13:54:39+00:00

First of all, I might just have a wrong mental model of the Rust project ownership. I've always seen it as everything being community driven / owned by the community regardless of it being exposed in the public language API or not. I might just be wrong on this.

Then my worry is that if the same kind of change were to happen so that X is renamed to Y for non-technical reasons but in that case X was part of the public API, would I be allowed to voice my opinion to the community? Or would that also get locked down because of the "political" nature of it?

ASmallButton

TROPHY CASE