Rye as Rebol (that it derives from) doesn't use parenthesis in general. In Rebol you can use them optionally for explicitly defining evaluation priority. But not in the same form as in Algol based languages:
print(inc(x))
But like Lisps. I've used them when I wanted to be very certain about evaluation, but not in general.
(print(inc x))
In Rebol (or Rye) this is usually just:
print inc x
That's why all function in Rebol/Rye have fixed arity and yes, you generally have to know it or deduce it from the code, which is a minus.
Rye currently doesn't have parenthesis option, but it might get it at the end. It does have op and pipe words, an optional left to right flow, which can also better hint about the structure than pure polish notation of Rebol I think. For better of worse, these Rye expressions all do the same :) --
print inc x
print x .inc
x .inc .print
inc x |print
Ha, I'm the opposite. Every time I'm writing python I have to stop and think "is it response.json or response.json()?" And then I think about how Ruby (I think nicely) solved the attribute/method decision problem.
Yes, and IDE that would know the arity of functions (which is not totally simple, because of the very dynamic nature of the language) would be able to display the "parenthesis" or the grouping of function calls. I plan to make sort of visual editor for it too as an experiment so that could be a first demo of it.
I hope we see this kind of exploration with Unison, which is stored as an AST in a database and not as text.
Of course you could just take existing text from a codebase and reformat it for viewing, but then there's this ambiguity about which version is real that you'd have to deal with.
In Unison it's understood that none of the text is real, it's only the resulting AST and its hash that matters, so if you're seeing text at all you know it's just for your benefit in that moment. It's such a cool idea.
Given how those discussions usually go, and the scale of the change, I find that discussion extraordinarily civil.
I disagree with the negative tone of this thread, I'm quite optimistic given how clearly the parties involved were able to communicate the pain points with zero BS.
I found myself reading this more for the excellent notetaking than for the content.
I suspect the discussion was about as charged, meandering, and nitpicky as we all expect a PL debate among deeply opinionated geeks to be, and Jake Edge (who wrote this summary) is exceptionally good at removing all that and writing down substance.
We are talking about extremely competent people who worked on a critical piece of software for years and invested a lot of their lives in it, with all pain, effort, experience, and responsibilities that come with that.
That this debate is inscribed is a process that is still ongoing, and in fact, progressing, is a testament to how healthy the situation is.
I was expecting the whole Rust thing to be shut down 10 times, in a flow of distasteful remarks, already.
This means that not only Rust is vindicated as promising for the job, but both teams are willing and up to the task of working on the integration.
Those projects are exhausting, highly under-pressure situations, and they last a long time.
I still find that the report is showing a positive outcome. What do people expect? Move fast and break things?
I am definitely of the opinion we need to rush away from C. Rust, Go, Zig, etc does not matter, but anything which can catch some of the repeated mistakes that squishy humans keep repeating.
That being said, the file system is one of those infrastructure bits where you cannot make a mistake. Introduce a memory corruption bug leading to crashes every Thursday? Whatever. Total loss of data for 0.1% of users during a leap year at a total eclipse? Apocalypse.
There is no amount of being too careful when interfacing with storage. C may have a lot of foibles, but it is the devil we know.
I agree. And ideally, every time you raise the question and get the "no" response, you learn something about the system you're modifying or the reviewer learns something about your solution. Then you improve your solution, and come back.
Eventually consensus is built - either the solution becomes good enough, or both the developers and the reviewers agree that it's not going to work out and the line of development gets abandoned.
Large-scale change in production is hard, and messy, and involves a lot of imperfect humans that we hope are mostly well-intentioned.
Moving using a 70's technology breaks things. Rust is tested already on other OSes like Windows, Mac (or iOS) and Android and solves several pitfalls of C and C++. Some quotes from the Android team [1]:
"To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code."
"Safety measures make memory-unsafe languages slow"
Not saying Rust is the perfect solution to every problem, but it is definitely not an outlandish proposition to use it where it makes sense.
Despite abundance of evidence, journalists revealing everything, and myriads of high-ups involved, only 2 people have been sentenced, for 4 and 2 years of prison.
My grandmother contracted Hep C from a contaminated blood transfusion in the 1960s. When the cure was approved within the past decade, she was one of the first given the treatment.
I don't know that this was the common practice or even intentional, and giving a new therapy to an elderly person does amount to medical QA, but despite half a century elapsing, it worked.
You're replying to sarcasm, but I do want to point out...
> Insulin is insulin, you can't make it "10 times better"
Other details aside, this part is not true. There are multiple kinds of insulin on the market today, and they span the glucose immediacy gamut from a large rapid burst to prolonged slow conversion.
Financial institutions have to log a lot just to comply with regulations, including every user activity and every money flow. On an exchange that does billions of operation per seconds, often with bots, that's a lot.
Yes but audit requirements doesn't mean you need to be able to search everything very fast.
Binance might not have a 24/7 constant load, there might be plenty of time to compact and write audit data away at lower load while leveraging existing infrastructure.
Or extracting audit logging into binary format like protobuff and writing it away highly optimized.
Binance boss just came out of prison, so he is not above the law.
And yes, they likely have this problem, because crypto is less regulated and full of geeks, so they have way more automation compared to traditional finance, at least proportionally to its size. You have bots on top of bots (literally, like telegram bots that will send orders to other bots copy-trading other bots).
In fact, there is even an old altcoin dedicated to automation: kryll (https://www.kryll.io/). They have a full no-code UI to create a trading bot with complex strategies that is pretty well done, from a purely technical perspective. They plug into many exchanges, including Binance.
Also, because it's less regulated, copy trading/referral/stacking is the Wild West, and they generate a lot of operations and fees.
