Re:Nimbus, An Ethereum 2.0 Sharding Client
by treeform on Wednesday August 01, 2018 @02:18PM
(#17665300)
Nim is great. To me it feels like typed python that is fast.
It also runs everywhere. I use its C mode on the server, its js mode on the website, and even its c++ mode to interface with c++ libraries such as steamworks which are hard to interface with.
Nim is also pretty cool by offering templates and macros. Which allow you to make some awesome DSLs that make your code short and sweet. Just don't go too crazy!
I used to really hate typing in C or Java because it felt so boring. I stayed away from typed languages for a long time, but nim has won me back. Types have saved me many times now!
Its also super fast, I mostly programmed in JS/Python and I never knew how fast computers can be.
Re:Nimbus, An Ethereum 2.0 Sharding Client
by erikpukinskis on Wednesday August 01, 2018 @03:04PM
(#17665845)
I have avoided typed languages too, mostly because I’ve been web focused and it’s just rare in that space.
But from what I’ve tracked probably 5-10% of my coding errors are type errors, and I do a fair amount of ad hoc type checking (if !arg.expectedAttribute throw new Error(“the second arg to blahFunc should have expectedAttribute”)).
There’s definitely a clear cost there, which feels like it outweighs the mundanity of typing.
However, I have come to believe transpiling is the devil, and many-languages syndrome is very counterproductive, so I stick to js, since it’s the only serious candidate for a “One Language” language.
Re:Nimbus, An Ethereum 2.0 Sharding Client
by arc776 on Wednesday August 01, 2018 @05:07PM
(#17667006)
Mundane typing? Typing is awesome! Haven't you ever wondered what a parameter actually is in say, Python, and have to track back through callers to work out what the parameter is expected to contain? Completely solved by specifying type.
Nim has really good type inference, so the 'mundane' aspect I guess you're referring to isn't there.
let
myStr = "Hello"
myInt = 12
myFloat = 1.2
var myHashTable = newTable[string, int]()
The need for checking types at runtime is of course completely eliminated in typed languages so you get that for free. Nim also offers an extension to this with distinct types.
type
Euros = distinct float # NB: Don't use float for currency
Dollars = distinct float
let
a = 10.Dollars
b = 10.Euros
c = a + b # Compile time error
d = a + 1 # Compile time error
proc dollars(e: Euros): Dollars =
let exchangeRate = 1.117
result = (e.float * exchangeRate).Dollars
proc euros(d: Dollars): Euros =
let exchangeRate = 0.858
result = (d.float * exchangeRate).Euros
let
e = a.euros
f = b.dollars
echo e.float # 8.58
echo f.float # 11.17
> I have come to believe transpiling is the devil and many-languages syndrome is very counterproductive
Why do you believe this? In Nim the language creates an AST and it's this that is output in various forms. The underlying representation is the same, but it allows many targets. Similar to LLVM (which is also a Nim target, if unofficially), it's one of the reasons why it can compile on almost every platform, and why it is a good choice for the low resource devices that projects like Nimbus target.
It also means you can write servers and clients in the same language but target C and JavaScript, respectively.
Re:Nimbus, An Ethereum 2.0 Sharding Client
by erikpukinskis on Friday August 03, 2018 @02:33PM
(#17682352)
> > I have come to believe transpiling is the devil and many-languages syndrome is very counterproductive
> Why do you believe this?
In isolation it’s fine.
But when I look at the complete toolchains required to maintain “modern” applications it’s not ok.
There are too many different languages in a single application, too many declarative configuration surfaces, too many chained pipes.
I grew up in a time where you wrote code, compiled and ran. We are overdue for a major collapse of how deep tooling is tolerable for a simple roundtrip source change.
If you’re a pro developer (and I assume you are) then you can ignore this. You can afford to spend 40 hours debugging your toolchain, teaching through 5 different languages and configuration environments to locate a problem.
But tolerable isn’t good enough for me. Frankly, I’m tired of spending my time slogging though DSL after DSL and runtime after runtime. I miss just code.
I believe we are overdue for a resurgence of native languages that can be written just as pure compiled or intetpreted code without a stockade of bizarre executables propping them up.
Re:Nimbus, An Ethereum 2.0 Sharding Client
by cslarson on Wednesday August 01, 2018 @12:39PM
(#17664165)
This is ecosystem. Status is a project that was funded as an Ethereum ICO. To support their existing work they're incentivised to help support core development of Ethereum itself. Love it.
Crypto has become an interesting play-ground to test out esoteric languages, which is a good thing esp. in a world where we are close to end of moore's law.
Re:Nimbus, An Ethereum 2.0 Sharding Client
by losvedir on Wednesday August 01, 2018 @04:30PM
(#17666684)
Can someone explain sharding here as it relates to ethereum? I've often thought the goals of ethereum about putting all the world's data in a blockchain weren't technically feasible, but maybe if there was a sharding mechanism it could be.
Also, what exactly are the capabilities of the client here. They mention running on mobile devices... surely that's not actually doing any mining is it?
Re:Nimbus, An Ethereum 2.0 Sharding Client
by thunderbird120 on Wednesday August 01, 2018 @05:02PM
(#17666961)
The idea behind sharding is to essentially parallelize the blockchain by splitting the one big chain into many smaller chains which can communicate with each other asynchronously. This is a really difficult problem for countless reasons but if they can get it working it offers a lot of very important benefits. It can process orders of magnitude more transactions than a conventional blockchain without the loss of decentralization seen in schemes using dPoS such as Steem, light clients get to be much lighter while still maintaining high security, and smart contracts which live on an individual shard and do not require cross shard communication are massively more efficient and can operate at a far lower cost than smart contracts currently can. The last issue is probably the most important for Ethereum specifically because currently most smart contracts simply cost too much to operate limiting their usefulness. Much lower operating costs greatly expands their realistic use cases. If you'd like a detailed writeup I'd recommend reading the Sharding FAQ https://github.com/ethereum/wiki/wiki/Sharding-FAQs
Re:Nimbus, An Ethereum 2.0 Sharding Client
by mratsim on Wednesday August 01, 2018 @01:15PM
(#17664544)
For now, we are still in research phase so we compile to C then machine code on our dev desktops.
In the future we will probably stay with C or use C++ (for zero cost exceptions).
We might not need Objective-C because the UI/UX part is taken care of by Status React[1] which is written in ClojureScript (and it's currently using Go as an Ethereum/Web3 backend).
The options to compile to Objective-C or JS are still there and that is very nice.
It also runs everywhere. I use its C mode on the server, its js mode on the website, and even its c++ mode to interface with c++ libraries such as steamworks which are hard to interface with.
Nim is also pretty cool by offering templates and macros. Which allow you to make some awesome DSLs that make your code short and sweet. Just don't go too crazy!
I used to really hate typing in C or Java because it felt so boring. I stayed away from typed languages for a long time, but nim has won me back. Types have saved me many times now!
Its also super fast, I mostly programmed in JS/Python and I never knew how fast computers can be.
But from what I’ve tracked probably 5-10% of my coding errors are type errors, and I do a fair amount of ad hoc type checking (if !arg.expectedAttribute throw new Error(“the second arg to blahFunc should have expectedAttribute”)).
There’s definitely a clear cost there, which feels like it outweighs the mundanity of typing.
However, I have come to believe transpiling is the devil, and many-languages syndrome is very counterproductive, so I stick to js, since it’s the only serious candidate for a “One Language” language.
Nim has really good type inference, so the 'mundane' aspect I guess you're referring to isn't there.
The need for checking types at runtime is of course completely eliminated in typed languages so you get that for free. Nim also offers an extension to this with distinct types. > I have come to believe transpiling is the devil and many-languages syndrome is very counterproductiveWhy do you believe this? In Nim the language creates an AST and it's this that is output in various forms. The underlying representation is the same, but it allows many targets. Similar to LLVM (which is also a Nim target, if unofficially), it's one of the reasons why it can compile on almost every platform, and why it is a good choice for the low resource devices that projects like Nimbus target.
It also means you can write servers and clients in the same language but target C and JavaScript, respectively.
> Why do you believe this?
In isolation it’s fine.
But when I look at the complete toolchains required to maintain “modern” applications it’s not ok.
There are too many different languages in a single application, too many declarative configuration surfaces, too many chained pipes.
I grew up in a time where you wrote code, compiled and ran. We are overdue for a major collapse of how deep tooling is tolerable for a simple roundtrip source change.
If you’re a pro developer (and I assume you are) then you can ignore this. You can afford to spend 40 hours debugging your toolchain, teaching through 5 different languages and configuration environments to locate a problem.
But tolerable isn’t good enough for me. Frankly, I’m tired of spending my time slogging though DSL after DSL and runtime after runtime. I miss just code.
I believe we are overdue for a resurgence of native languages that can be written just as pure compiled or intetpreted code without a stockade of bizarre executables propping them up.
Crypto has become an interesting play-ground to test out esoteric languages, which is a good thing esp. in a world where we are close to end of moore's law.
Also, what exactly are the capabilities of the client here. They mention running on mobile devices... surely that's not actually doing any mining is it?
Any challenges with getting Nim on mobile? Do you compile to objective-C for iOS devices?
In the future we will probably stay with C or use C++ (for zero cost exceptions).
We might not need Objective-C because the UI/UX part is taken care of by Status React[1] which is written in ClojureScript (and it's currently using Go as an Ethereum/Web3 backend).
The options to compile to Objective-C or JS are still there and that is very nice.
[1]: https://github.com/status-im/status-react