The most painstaking development area. Calling all core devs! 📞

Querying all core developers. Of all the different areas/modules (routing, crust, messaging, etc) in SAFE, which would you say was or has been the most difficult for the team to develop? What has been your favorite personally? Have any of you ever feared a critical aspect/module of SAFE could not be accomplished? Ever felt like giving up? Which do you predict would be most likely to cause significant delays in the release of SAFEnet? Which will require the most tweaking after the network is live? Any major functions or features that will be added to the core well after the network is live?

Sorry for the bombardment. I know my curiosity is in itself is a potential cause of delay, but I would really like to peer further into the development chronicle for each great mind that has contributed to this incredible system. :smile:


Network layer - crust, least amount of innovation, most amount of hassle

Routing for me, complex and had lots of issues to solve, Client has most of the inventions, vaults now reduced to passive logic though.

Nope :slight_smile: that is only interesting parts when folk say impossible, I live there and love it.

Nope, too important. Hardest part by a country mile is personnel issues, although they have been minimal indeed, thankfully. Those drain me beyond belief, logic puzzles are a dream in comparison.

If any, network layer.

Hopefully we get the code down to the most basic features with strong security. The tweaking will be removing all if statements if possible and for sure all raw loops and magic numbers and any state we can.

Computation will be introduced which will be a real game changer. Archive nodes and republish of data on worldwide outage all need to be considered as well.

No worries, helps everyone. Nice one :wink:


Holy moley! For you this seems like an arrived conclusion you’ve casually tossed into the thread. For me, lets just say my brain is splattered all over my room… :astonished: A clean event driven system capable of processing input without wasting cycles on parallel listening is freaking magical. :heart_eyes: Please, when you get the chance, further expound that idea/concept!!! Few discus the artistry of code. :sunglasses:


I’ll second @Tonda and say that’s something I’ve never heard before.

Tonda I can see partially what you’re suggesting he means. It’s just adding event listeners to passively wait instead of active querying.

But… is it really possible to remove all if statements? I’ve never even considered if that was possible, and across all languages it is the most basic of logic operators.

Furthermore, what would the benefit be? Is that logic check so costly that it noticeably hinders performance?

“if” or “match”, some match statement have multiple check. Using event correctly can remove this check. If it failed, if it’s an error, what kind of operation I have to do next. I think he mean be that. but normal “if” statement or “match” are fundamental and I don’t think we can’t get rid of that.

I confuse myself on that reply. Maybe not for error checking but mainly for the next task to do.

1 Like

Yeah!! I can’t wait for this. It will be totally amazing.

Maybe it’s a Rust thing. I.e. a lot of decisions are encapsulated in the Rust language??? If not, I cannot imagine SAFE having no If-statements unless David meant if figuratively by making the code as linear and streamlined as possible.

I think is trying to reach the limits of the functional programming paradigm. You eliminate IF when you can break the logic into smallest step allowing you to apply extreme factoring.


On david’s blog he wrote somewhere about factoring everything down to its lowest possible form, like we did in math.

I think that’s why he switched from C++ to Rust, and if he’s serious about removing all if-statements, it holds the same concept.

1 Like