Topic: What do you look for in a programming language made for decentralized projects? (Read 276 times)

I never say programming language correlated with scalability, but i should've mentioned it explicitly.

It's like comparing apples with oranges because centralized system could scale easier and doesn't require any consensus. Besides, few other things such as protocol which used on decentralized system and internet connection also affect how fast/scalable is it.

Scalability has nothing to do with programming languages - in fact I think the Visa and MasterCard systems are still running on COBOL and mainframes. But it has everything to do with how you design the protocol - and how much crosstalk nodes and miners have to do among each other before a block reaches them.

I made a similar thread so hopefully that will help:

https://bitcointalksearch.org/topic/m.58025958


Regarding your Flogram language, it will be a new language, lets say for example compared to C++ that came out over 35 years ago.

Why should crypto developers use your new programming language when there's already a language that has already been established for over 35 years?

Is there risks especially security risks when a crypto developer uses a brand new programming language to create a blockchain that one day potentially can store all the world's wealth and finances on there.

Can Decentralized Flogram be more faster and scalable than centralized services such as Mastercard/Visa?

Thank you Trojane, appreciate the feedback and encouragement.

There were only a few places.. specifically it was a matter or do I allow undefined behavior or do I always add in a runtime check for it. But yes, security is very important, particularly if we are targeting blockchains as initial customers. So undefined behavior is going to be a new feature.  We've got a lot of great security features, thread safe, memory safe, a powerful yet simple typing system

Congratulations first of all !
When you talk about creating FLOGRAM' ,innovation comes into play ..you can't say you want to make it perfect,you could only try to improvise!
Because even with your concept,technology advancement will one day degrade it.
So all am saying is that you sit down and think of special features,the likes of formidable COMPILERS and SPEED should be automated to synchronise.
Lastly,everything boils down to Security. IF IT ISN'T SAFE,THEN IT ISN'T WORTH CREATING.....!
Try as much as you can to develop inbuilt security options that are customised!!
Then maybe, a few user security options that could be deactivated depending on the CONCEPT OF CREATION..


Don't always forget to keep improvising as per time ..
It doesn't end here!!
Trojane 💎

Yes, it does. There is a "catch" when it comes to threading:for the most part, we thread your programs for you and you don't have to think about it.

Two ways threading works:
1) Functions are analyzed by the compiler and automatically parallelized.
A couple ways you can influence this parallelization:
  "Atomic" objects may be created which work like very flexible go channels inspired by go. Basically any function called on an atomic object or variable read/write is done in a thread safe manner using something similar to locks (technically it's lock free for performance but you can imagine it like locks). While automatically parallelizing we'll provide a suggestions that if you were to mark certain objects as atomic, the parallelization can be more efficient but we require marking it atomic and don't automate this because it may not make sense in certain cases.

  It's harder for a computer to estimate how many times a loop or recursion will execute than a human, so we allow humans to provide hints to the computer about this. Otherwise, computers can actually estimate more accurately and easier than humans.

2) Programmers can force functions to run in their own thread, again inspired by go and similar to go routines. This is particularly useful for say forcing a frontend and backend to run in parallel guaranteeing both get some CPU time.

Sounds interesting. Will it work in a multi-threaded environment without introducing race conditions, etc.?

Security above all.. ok in that case I'll put no undefined behavior ahead of allowing coders to skip the occasional if statement for slightly more speed. A couple of other things like this.

@NotATether Not planning on getting old coins to rewrite their code bases from scratch, more like write a second miner for improved security and performance. Additionally writing your miner in multiple languages is great for decentralized security.. a single bug is quite unlikely to take down the entire network more likely just those using that miner and coin will live on. But even more so targeting the smaller startups in the crypto space to help deliver them a language that gives them the security and performance they need while getting their projects up and running quickly. Not to mention being able to iterate faster and add new features faster.  Actually already have the first two future clients once I get this thing running.

@Syke Rust is actually what inspired this language.. it's got great ideas but the ownership and borrowing is a pain and I've come up with a much easier solution to the problem while achieving similar performance and security.. partly a matter of the compiler doing the ownership part for you, though there are a few cases where it isn't capable of it. It's sort of like the C to Rust's C++.. capable of anything Rust can do but much simpler. And I've both simplified a lot of things languages have taken for granted because the last language did it that way while providing a lot of flexibility and a nice set of core features. The goal is to make the language as intuitive and easy to work with as possible while maintaining peak performance.

Regarding the features you like:
#1 Rust ownership.. like I said I've automated this away so it'll have the performance of Rust, but be roughly as simple as garbage collected languages. Every once you'll need to worry about strong vs weak references but that's rare. Basically you don't need to think about it unless the compiler/IDE has a problem with the occasional edge case and there will be extra checks to make sure you didn't make a mistake in those cases.

#2 Type inference.. planning on it. Initially static and have to fill in the types but one of the first things the IDE will do is fill them in for you so it's as simple to write as dynamic typing but you can see the explicit types should you need them

#3 I agree.. Rust compiler errors/warning are a wonderful example for writing our own.

Regarding beating the Rust ecosystem.. if I can provide an easy way to wrap libraries made in other languages, I can allow integrating their libraries. So I don't need to beat them. It can be like Python that uses lots of C libraries under the covers, though over time there will be incentives to move to pure Flogram. Namely better performance and security as we can reason about native Flogram code better as the language was designed with that in mind.

Thank you for feedback!

Well the features that will be used in a programming languages depend on whether they will be used to build frontends such as wallets, or backend daemons, CLIs and RPC invokers.

Bitcoin is built in C++ and it's optimized for security more than anything, in the sense that the code is painstakingly reviewed for security vulnerabilities and consensus violations.

So for Bitcoin and a lot of the other older coins, they most likely have some of their own standard library functions, e.g. secure RNG.

But in some of the more recent altcoins (I'm a RYO currency dev, Node frontend & C++ backend), their daemon and wallet are more optimized for speed and usability than security, meaning compared to e.g. Bitcoin, you don't see a lot of audits before a new release. So the features in your language that you should focus on depends on whether you want newer coins or older coins to use your language.

And a spoiler alert, you'll have a hard time getting the older coins to overhaul their codebase  

First and foremost, good luck on your project!


Security, security, security. *cue the ballmer gif*


#1, The Rust ownership model. I can easily use random libraries, multiple threads, old code I forgot what I meant when I wrote it, etc., and never have to worry about who owns what. If it compiles, 99% of the bugs have already been eliminated.

#2, Type inference. I'm lazy. When I define a vector, I don't want to specify the type, because I know I'll only be inserting Ints into it. If I later decide it needs to be Floats, I don't need to update the definition. The compiler will enforce static typing. Just say no to dynamic typing.

#3, Helpful compiler warning/errors. Again, Rust is a fine example. It doesn't just point out the errors, it offers relevant fixes.

Now, the punchline. You can't beat Rust. I know, I'm the asshole. You're competing with the entire Rust ecosystem. You need SSL? There's a crate for that. You need PRNG? There's a crate for that. If you have some good crypto/blockchain ideas in mind, implement them in Rust and publish the crates.

I am working on Flogram, a programming language, designed to be perfect for writing blockchain projects. And I don't mean a language for smart contracts, though it probably could be used there too, I'm more talking about a language for say building a blockchain or miner or wallet or torrent downloader or other decentralized projects, etc.

After much studying of Rust and other programming languages, I've made some interested discoveries. I've spent 1 1/2 years of designing this language on top of a background high performance and security. I've found a way to automate parallelization, async, memory management and a few other smaller things. I intend to make it simple, secure and yet initial testing shows it to be extremely fast, faster than C kind of fast.

It's well designed and I'm working with a few others to build the compiler.  However, I would love to get feedback from programmers in the decentralized space.

Some specific questions for you:

• If I make trade-offs would you prefer performance or security? I'm thinking security by default allow using a keyword to opt out to allow improving performance via undefined behavior or
• What about building a stronger type system that allows 'dependent types' which essentially adds formal proofing to it to prevent bugs, would you use it? Adds significant complexity, significantly increases compile times, but also allows stronger security and bug prevention. Unit testing is currently a more popular alternative.
• What features do you most value in programming languages in general?

P.S. I'm always looking for C programmers! Or investors who would be willing to help fund development.