Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 14:17
    cburgdorf labeled #102
  • 14:17
    cburgdorf labeled #102
  • 14:17
    cburgdorf opened #102
  • 09:07
    cburgdorf commented #38
  • 02:31
    codecov-io commented #97
  • 02:27
    g-r-a-n-t synchronize #97
  • 02:27
    g-r-a-n-t edited #97
  • 00:36
    daniniguez commented #38
  • 00:31
    daniniguez commented #38
  • 00:27
    codecov-io commented #58
  • 00:24
    daniniguez synchronize #58
  • 00:12
    g-r-a-n-t review_requested #97
  • 00:12
    g-r-a-n-t ready_for_review #97
  • 00:03
    g-r-a-n-t review_requested #100
  • 00:03
    g-r-a-n-t ready_for_review #100
  • 00:03
    g-r-a-n-t edited #100
  • 00:02
    g-r-a-n-t edited #100
  • 00:02
    g-r-a-n-t synchronize #100
  • Oct 26 23:56
    g-r-a-n-t edited #100
  • Oct 26 23:54
    g-r-a-n-t commented #100
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> semantic analysis for function calls would need to be added. we already have functions in the contract scope, so it would just be a matter of adding a method expr_call to the expression traversal that assigns the function's return type to self.foo()
David Sanders
@davesque
Hey guys! Just wanted to pop in here and say I'm psyched to see all the recent activity on this project! Cheers!
Also, I miss you guys!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> Thanks David 🙂
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> David! I've been waiting for you to notice our activity. Would love to see you coming back to work on Fe!
vasa
@vasa-develop

Hey Guys!

I have been following the Fe project for a while (I initially thought that the Vyper compiler is being re-worked on as the Fe project using Rust. Seems like it has evolved now).

I'm the maintainer of https://vyper.fun project (CryptoZombies, but for Vyper).

If you guys want to create a resource like CryptoZombies for Fe, just let me know. I can create one :smile:

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> Thanks for reaching out to us. We would absolutely love to. I believe this would be a very fruitful collaboration for both sides. The feedback we'd get from that would be very valuable in the early phase and obviously the onboarding of devs once its live. So, yeah, absolutely, we'd love to do that. It may be a tiny bit too early as we are still lacking many core language features but we are accelerating in pace we should have a working ERC20 demo by the end of the year imho. Also pinging @Grant Wuerker for visibility
vbuterin
@vbuterin
Hullo!
.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<vbuterin> Oh here we are 🙂
vasa
@vasa-develop
:wave:
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<vbuterin> Excellent work guys and I'm delighted to hear that vyper is still evolving whatever the name is 🙂
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<vbuterin> Can I ask what the main changes are vs vyper and what motivated them?
<vbuterin> (I can see what some of them are, but wonder if there's a complete listing)
<vbuterin> One initial comment I have is that there is a reason why Vyper was designed to really strictly "pretend to be" python syntax-wise; in addition to python having great aesthetics, basically it's to ensure that you can reuse existing python tooling for syntax highlighting, linting and the like as much as possible
<vbuterin> So it's about familiarity to the machine and not just familiarity to the dev
<vbuterin> Of course there may be good aesthetic reasons to deviate from that especially if you have a type system and other things python does not 😄
<vbuterin> but still important to keep things like that in mind
<vbuterin> Another thing is that I'm not personally dead-set on Yul as the intermediate; I saw fubuloubu on twitter saying that he liked LLL and it was simple
<vbuterin> Ideally we could all agree on one intermediate 😆
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Christoph Burgdorf (cburgdorf)> Hey @vbuterin happy to see you here!

Syntactically, the difference are numbered at this point. E.g. we where vyper uses decorators to declare public functions we currently use pub def something:, we choose angle brackets for generics e.g map<TKey, TVal> which is used more widespread for generics (Rust, C#, TypeScript etc). Vyper is limited by the AST that the Python parser produces wheres Fe has a rather flexible parser. Many syntax decisions aren't yet set in stone but I think Fe will arrive at a mix of Python and simplified Rust.

I personally don't have an opinion on LLL but considering that Solidity is currently the de-factor standard and that it is working towards using YUL by default (currently already used for inline assembly) we believe it will give us a shortcut in terms of adoption. If YUL will allow targeting eWASM, OVM etc, we will benefit from it immediately. Plus, if the last stage of our processing pipeline is going from YUL to bytecode then I believe this may also be an advantage for auditing if it means that the last stage of compilation is basically the same as in Soliditiy. That isn't true yet because Solidity doesn't yet use YUL by default but I think that we will eventually arrive at that place.

Using Rust also eliminates a whole category of errors that could can arise at runtime compared to one written in Python. It also gives us a much nice way of distributing binaries of the compiler.

<Christoph Burgdorf (cburgdorf)> @vasa-develop One thing that we basically would like to have as soon as possible is an online editor for Fe to give people something to play with. I just realized that Fe.fun would basically depend on something like that implicitly anyway so maybe we could start there? We already have an issue for that to drive the discussion if you are interested: ethereum/fe#70
vasa
@vasa-develop
Awesome! I'll look into it :smile:
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> Cool!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Piper Merriam> Is decidability still a feature of fe-lang? I remember that string types were problematic in vyper because they are unbounded and thus anything that operates on strings made decidability often not possible.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> there is a section of the readme which discusses this a bit
<Grant Wuerker (g-r-a-n-t)> > The following is a list of goals or aspects of the existing Vyper project that we do not necessarily wish to duplicate:
Lack of code re-use features such as:
    Modifiers (re-usable assertions)
    Method resolution and class inheritance (though we're on the fence about this)
    Module imports
Strict enforcement of limits on dynamic behavior -- Though we aim to provide Vyper's decidability by default, we believe it may also be useful to allow disabling of decidability features if the expressivity trade-off doesn't make sense for certain projects.
vasa
@vasa-develop
Yeah, it's ok if we don't have the modifiers...but losing inheritance kinda sucks
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> ah, these are things that exist in vyper that we may not want to duplicate. so the lack of code reuse features, like inheritance, is not something that we want to duplicate
<Grant Wuerker (g-r-a-n-t)> we are open to adding inheritance
vasa
@vasa-develop
:thumbsup:
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> hopefully this answers your question somewhat @Piper. I dont have a definite answer at the moment, but am thinking there will probably be features that compromise decidability. This should be kept at a minimum though.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Piper Merriam> Am I understanding correctly... Decidable by default. Explicit mechanism to bypass it?
<Grant Wuerker (g-r-a-n-t)> Yeah, I think that's what we want. That mechanism could resemble safe/unsafe rust https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> just a thought 🤔
<Grant Wuerker (g-r-a-n-t)> Yeah, I think that's what we want. That mechanism could resemble safe/unsafe rust https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
Ivan Schütz
@i-schuetz
was shortly very excited when I saw Rust in the Readme, but it's just for the compiler :P
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph Burgdorf (cburgdorf)> @i-schuetz Don't be too disappointed. We are big fans of Rust and it is likely to influence the language in certain ways
Ivan Schütz
@i-schuetz
sounds good
Is there a roadmap? when can we start writing production ready contracts with it?
vasa
@vasa-develop
next year
you would have something to work with
Ivan Schütz
@i-schuetz
okay, thanks!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> We plan on supporting the features used in erc20 by January. These features will not be audited though, so it shouldnt be used in production.
<Grant Wuerker (g-r-a-n-t)> We'll have a long-term roadmap posted maybe around the time we finish erc20 support.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Christoph Burgdorf (cburgdorf)> Interesting memory library for solidity

https://github.com/summa-tx/memview-sol

Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Christoph Burgdorf (cburgdorf)> https://axic.github.io/notes/summit/future_of_solidity/

Interesting slides on soliditys future. Nice to see some overlap in our plans (e.g std library)

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Grant Wuerker (g-r-a-n-t)> just flipped thru it. lots of relevant stuff