We are going to make the repository open source next week and, for those who haven't listened to the podcast, I want to align everyone's expectations and say it is very early material. Expect bugs, breaking changes, etc.
On the other hand, it is also a great time for anyone who wants to jump in and help shape things, so feedback will be very welcome!
(I'm the guy who guessed correctly and got early access). Sorry I have been busy with my main job and haven't been able to contrib much in the past couple of months or so, but I just took a look at it and it looks really good so far. I think some of the architectural things are well-considered, and also, one thing that I forsee is "calling out to a remote gpu", where the nx library itself can be used by a node that doesn't have a gpu, instead of having the node with a gpu expose an rpc to the gpuless node. I guess a relevant analogy here would be the difference between graphQL and REST, but possibly also allowing the gpuless node to gracefully degrade to cpu, if the gpu resource isn't available. The Nx API will likely present an opportunity to also make data gravity abstractions cleaner.
I think the elixir/erlang way of thinking about "concurrency as a special case of distribution" will apply to Nx, except "gpu as a special case of distribution" which means there won't be a leaky abstraction for remote gpu. I tried to get the Julia folks to adopt this sort of an attitude towards the juliagpu, but I'm a bit of a nobody so it didn't take.
Very excited! And I'm whipping up a little bit of something interesting related to Nx myself that hopefully I can release around the time of your talk, but I don't want to make any promises yet.
Good point. The relevant analogy is that in GraphQL the client defines the query that gets run and in REST the server defines the query that gets run. So one way you could architect Nx is to have your elixir running on the gpu node expose a handful of prebaked functions and allow your client elixir node issue requests to those prebaked functions ("REST"). But I think a bit more exciting would be to have your gpu node running a relatively dumb Nx server, and have your gpu-less client running Nx, where its math instructions get serialized using a thin "network device" backend instead of a "gpu backend", over to the gpu node, then the gpu node does the math and comes back with the answer ("GraphQL"). For even longer-haul operations you would want to do things like figure out how to represent datasets with tokens that are cached remotely. I think this all is possible, and, relatively easy with the Nx architecture.
Very excited about this project, since I’ve been looking to wet my feet with Elixir and numerics are the perfect niche for me!
Here’s something I’m confused about. For fast numerical code, it’s vey important to be disciplined about memory allocation. So in addition to considering of immutability -vs- mutable pre-allocation, it would seem that the scheduling model ought to be substantially different. Instead of constantly switching between concurrent processes to ensure none of them monopolize the processor, would it make more sense to finish one computation while the contents are in memory/cache, before cleaning it up and swapping to another process? (Especially for really heavy computations). Will process scheduling have to be micromanaged? Is the BEAM compatible with this mode of usage, or is this maybe not a concern?
Memory allocation and scheduling are both important considerations but are separate problems.
BEAM concurrency only involves memory allocation when the processes are created. Switching between them doesn't involve allocation and is very quick (don't forget we are talking about BEAM processes here not OS ones - it's all in userspace and very efficient). As long as you pre-create your pool of worker processes concurrency doesn't incur much allocation hit.
You're right that immutability might do though. I am curious to see how this goes - the speed that Elixir normally runs at combined with some data sharing optimisations means that this issue doesn't exist normally. At the speed we care about when doing numerical work it's more of a concern. Or maybe we'll never get into the realms of full optimised C++ where things are sized for cache lines etc. (and that's ok).
If you're interested about the various modes of BEAM concurrency with nifs, I put together this video, but the code it is showcasing does (deliberately) elide over some of the finer details of beam reentrancy:
I do not know what Nx is doing, but BEAM has "dirty NIF"s: long-running native functions that are scheduled differently so that they do not impact regular BEAM processes. They're transparent from the user space.
Exciting to see that heavy numerical computation might be available to a language running on BEAM. It has always seemed to me like an area that people would point to where Elixir couldn't stand up to Python.
I've always dreamt that someday you might be able to reach for Elixir and get everything you needed for an entire stack of a company and it seems to be getting closer and closer. The building blocks for a web app have been around with Phoenix and Ecto for quite some time. LiveView was introduced to make more user friendly frontends. GenStage, Flow, and Broadway introduced ways to run data processing pipelines. And now we're seeing the initial steps to potentially have ML capabilities.
I am almost convinced to go all in with the elixir ecosystem. Having been a victim of a similar type of thinking, however, I am not sure this is the best thing to do so I am skeptical.
Remember, Java and the JVM essentially have this today: front end frameworks, back end frameworks, data pipelines, big data processing, entire databases, etc.
In your opinion, what will make the Elixir flavor of this situation different?
I like Erlang and Elixir quite a bit. However, I do think a bit of caution is warranted. With languages like Java, Ruby or Python, you can probably do an ok job at any particular task. Maybe not a great job, but good enough to get something up and running. I think BEAM has some sweet spots where it really is the best, but they're not huge spaces, and it's good to be wary of people jumping into BEAM without solid reasons why.
In terms of what it's good at, we very successfully employed Erlang as the command and control language for some semi-embedded system medical devices. The runtime is predictable in terms of performance and memory, and fast enough for a lot of things. Where it wasn't, it's easy enough to talk to C. All the fault-tolerant bits are nice for a system like that where you want it to take note of a failure and restart the subsystem that failed. Lots of good logging, introspection and diagnostic tools exist.
I've worked in Elixir every day for the past 5 years.
Things I like using it for:
- long running services
- doing anything w/ concurrency
- setting up cron-like processes that run every so often
- actor model anything
- stateful services
- web development using Phoenix & Ecto
- parsing
- encoding/decoding
Things I don't like are primarily related to it being a small enough community. That means libraries for third party services aren't always the best, and using it in the enterprise means that the smaller talent pool is less attractive when the company's priority is to use proven/boring tech for which you can hire tons of developers. I also don't think Elixir has a clear value proposition when you're writing small, single purpose functions for a serverless architecture (even though I really like writing it), or when you're company decides to go all in on Kafka for communication between micro services.
I hear the 3rd party library complaint a lot, but as someone who has been writing elixir professionally for about as long as you have I just haven't seen that. Speaking of kafka, the clients aren't as far along as the official clients, but the same can be said for almost all languages.
Being able to utilize erlang libraries means there are a ton of heavily production tested libraries you can easily drop into an elixir project.
My current job uses a mix of Java & Elixir. I definitely feel the pain of using the Elixir client when the Java client offers so much.
I also encountered some pain with the AWS client for Elixir when our company implemented SSO. There was a lack of support for a certain flavor of environment variable if I recall correctly. It's not horrible, just a pain.
> C#/.NET, Go, JavaScript/Node, Ruby, Python, C++, and PHP probably all do way better than Elixir in third party support.
hard disagree on all but c++, .net and maybe python
I think people forget erlang has been around a long long time and I've written ruby for years and can speak with great confidence that the equivalent ruby libraries in elixir are typically much higher quality
The single unix process that BEAM uses is more conducive to some kinds of systems than some of the hackier-feeling solutions for the Rails ecosystem to tie different pieces together.
There isn't an issue with Kafka and Elixir, it's the inherent complication around using Kafka when a lighter weight solution (Rabbit, PG) would work perfectly fine.
What logging tools are you using? We have a couple of Elixir stack and their logging functionality leaves much to be desired at the moment, compared to the Python standard logging library. I'd like to improve it but haven't found much guidance so far.
I agree with that, we had to replace the whole logging module that Phoenix gives you out of the box to provide for logging messages to one line, JSON format, logging both to stdout and file. This is an area that would be easy to improve. Also distributed tracing is not easy to get working or at least the libraries I've found.
In my experience the difficulty of using BEAM is directly related to how well your problem fits into the actor+deep copy model of the environment. For certain problems BEAM will be a terrible solution because you're going to spend a lot of time working around this. I also think this is what makes it easily the best choice for other problems that fit this model well.
In the middle you will probably have a large number of problems that it's ok-ish at. But not really sure on what the distribution is here.
Can you give an examples? Respectfully, you were asked for tasks and instead gave a description of the category.
I can only think of real-time, or real performance limited software (example: rocket guidance software, aviation, etc). With these every modicum of performance per millisecond matters; but these constraints only apply in a few (relatively) small fields of software development.
My particular problem was a back end for a medium-level multiplayer RPG (500ish people connected at once per world). The only real way I found to get it performant was to lean heavily into processes. But then you have a race condition problem and need to DIY your own method of synchronization because you're no longer using the process mailbox for that purpose.
In practice I haven't found the immutability of Elixir that useful for concurrency because data is deep copied when it goes across processes anyways. This is in comparison to Clojure where you can safely and perfomantly share immutable data across multiple threads.
From my testing, the performance characteristics of ets isn't that great - data still gets copied around when you access stuff in it. I tried using it in my exploratory tests and certain worst case, player-focused actions would take around 20ms, when using a regular GenServer with a synchronization system on top would take around 5us.
To be clear, for NPCs it worked fine. But players are hoarders and in an RPG that can result in a ridiculous amount of data being attached to them.
I'm an Erlang enthusiast, but find myself writing C for (small) things where I need to interface with struct heavy library calls, and nobody else has built up an BEAMy interface. I could build it, but it would take about the same work to just build my project in C.
Of course, maybe there's a generalized BEAM to C call library I'm not aware of? (I didn't think to search for one until now)
Also, honestly, it's a little easier to have a C daemon than an erlang daemon. Just call daemon() before the service loop vs setting up an app file. Of course, you have to build hotload yourself from dlopen and friends, and you lose out on a lot of features.
Elixir releases are built in and easy to use. You don't have to write an app file directly for instance.
I usually use ports for C interface (rather than NIFs). I have a little boilerplate C and Elixir that I recycle to do the ground work and then it's just your specific implementation detail.
Yeah, so those look like nicer ways to call C than writing a NIF, but they don't look like point to a C include and get the constants and a way to call the functions in the include (and use the types in the include. If I'm reading correctly.
I'm looking for the equivalent of Perl's h2xs, or something like that. (which incidentally, maybe I should be writing these things in perl ;)
> AFAIK, any modernish language is good enough to get something up and running regardless of the task.
A lot of languages that have more limited existing use have more gaps in their ecosystems. That means that to get something going quickly, you run into cases where you spend a lot more time building (or validating and tweaking existing but relatively rough) support infrastructure that you would just grab a well-tested, established library for in a language with a richer community and ecosystem. This is an area where the top tier ecosystems (Python, .NET, JVM) really shine over even second-tier popular ones like Ruby, and where both of those tower over things like BEAM, which has the additional problem that it has a fairly high impedance for incorporating C libraries, where many other platforms (some also with stronger ecosystems of their own) also more easily consume C libraries.
This extends both to broad application domains (e.g., scientific libraries) and to things like probability of having an idiomatic, language specific, well-supported client for a new service you want to tie in and incorporate.
There are things where the Ruby/Java version will be faster to use, more polished, or simply exist in the first place. I mean, yes, you can probably kinda sorta get something working with BEAM languages, but I'd occasionally hit something where Ruby had a gem, and Erlang didn't have much.
I've been porting code across platforms and most languages cannot embed themselves into arbitrary runtimes, for technical or political reasons. Had to go with rust rather than higher level languages.
My completely biased answer is I haven't written Java since I was a freshman in college (2009) and that was like a few months. I basically know nothing about the ecosystem.
I've written Rails professionally for almost 10 years and have been following / playing with Elixir since 2016. While Ruby / Rails are amazing and the ecosystem is well suited getting a project off the ground extremely quickly, I'm just a big Elixir fan and hope to work with it professionally one day. I'll parrot reasoning from some of the sister comments.
"having an entire environment of consistent actors, fault tolerance, hot reloading, etc is a tempting proposition." - Very tempting indeed!
"Code elegance and development joy, maybe?" - Coming from Ruby / Rails, I agree 100%
"Not being statically typed" - Again, I've worked mainly in dynamically typed languages. I've experienced typing in Javascript and wasn't the biggest fan. But don't get me wrong, Rails can be awful when trying to dig multiple objects deep to understand what the data structure of the return value is so its not completely off the hook.
I think it's important to note that as much really good work as TJ Holowaychuk did for the early NodeJS community, much of the speed of that work is that he was replicating the functionality of Ruby gems. All the lessons learned by the original authors come cheap, and you can do a good deal of head-down coding that way.
This also helps with recruiting, as the tools work similarly. I didn't spend a lot of time in Rails, and decided not to go that way again, but I did appreciate that I got to recycle some of that new thinking when I started writing Node.
Phoenix also seems to be designed to recruit Rails developers. You could do worse than porting missing tools and crates from Ruby, and as far as I'm aware nobody has nominated themselves as the TJ of Elixir.
(assuming you confused CJ with TJ) This just is not true Having coworkers who personally knew TJ, he was a brilliant mind in his own right, and even if you think that is true, reimplementing functionality in another language but sticking with that languages current design patterns, working within the confines of that languages quirks to provide a cohesive, fluent, and extensible API is no small task.
What the parent posted isn't a criticism, they never said it was a small task or that TJ Holowaychuck's work in the nascent Node ecosystem wasn't brilliant. Just that there is low-hanging fruit available when a new technology of the NodeJS type arrives. If someone has the drive and skill to build high-quality [re]implementations of a large number of key libraries, based on what is available in other (much more established) platform/s, then all being well, that person can do it quite rapidly as the problem space has already been mapped (which then in turn has a huge catalytic effect, particularly as all the APIs they create will follow common patterns).
If you need a library for something in Java, it probably exists. There's several languages on the JVM these days that give you full Java interop - Clojure being my personal choice.
I think Elixir's big selling point is getting the BEAM runtime wrapped in a more modern language with more modern tooling. Lots of the positives people list about Elixir are due to BEAM, which you can also get in Erlang.
> I haven't written Java since I was a freshman in college (2009) and that was like a few months. I basically know nothing about the ecosystem.
I was in love with Ruby and hated Java around 2009, but the latter has gotten so much better with IntelliJ IDEA, to the point where I have to admit that working with JavaFX from IntelliJ was likely my most serene programming job ever. To me, the whole ecosystem is only worthwhile because of JetBrains.
Robust IDE support for Elixir is probably a must-have requirement for many nowadays. I am really tempted by the design of Elixir and find Java/Go/C++ aesthetically repulsive, but I'll happily forget about that if I can keep my refactoring muscle memory.
Fair enough, all the OG IDEs from 2009 are still around. And on the lightweight end of the spectrum, VS Code has excellent tooling support for some languages like Dart/Flutter.
What's interesting is my company hired a bunch of ex-ruby/rails people who transitioned over to Python. A year later, we tried to explore elixir and all those ex-ruby devs were adamantly against adopting it - they figured async python would be better. Very odd, since I figure it would be easier to adopt if you come from Ruby... but perhaps the Ruby community isn't that into functional programming?
It was very interesting experience being a long-time Pythonista having to be like "Isn't this awesome language with a Ruby-like syntax great???" and being told nah, let's just use async python by people who had spent years writing Ruby code.
I guess it depends on the programmer. I've fallen in love with more functional style of coding. The idea of data in and data out makes me feel like it's so much easier to follow what is going on compared to having objects with side effects and mix ins and instance variables. I try to write as much of my Ruby / Rails avoiding the things I mentioned, but its pretty hard to avoid in a larger codebase.
I think Elixir has the potential of being like the JVM but for functional distributed programming. The JVM is fantastic and I do most of my work on it, but having an entire environment of consistent actors, fault tolerance, hot reloading, etc is a tempting proposition. Especially with the easy interop of languages & functional aspects. I don't think it will surpass the JVM, but I think it has a lot of potential in its own sphere of influence. Especially if the library support & technical contributions keep coming.
Not being statically typed could mean that there aren't long compile times for large projects.
More importantly, the functional style used with Elixir will likely mean shallow usage patterns that are more composable than the deep layers upon layers of 'architecture' that plagues long lived class-based OO designs.
Right I get that elixir as a language is more enjoyable than Java. The question I wonder if it is wise to go all in on a single platform for the sake of being uniform.
Why would it not be wise? Python did it, Java did it, Elixir can do it too. Uniformity is good for productivity, as long as the ecosystem stays healthy & maintained.
Well for example imagine your stack is in Go and enjoy the speed and maintainability and expertise, but you want to use spAcy and all the great data science and ML libs in python. Or imagine you are all in on Java and want to use PyTorch. Or you are struggling finding an api-gateway like solution and want to utilize Zuul. Or you want to use Edge Lambdas on AWS but have to write them in node.js. etc.
Pretty disappointing to see it using XLA. Anything Tensorflow is notoriously difficult to build on a local machine and generally considered a dependency nightmare. I would've thought libtorch bindings would be much easier.
Our compiler backends are pluggable. We went with XLA because that seemed the most accessible to us 3 months ago but you should be able to bring in libtorch or any other tensor compiler.
That's actually one of the things I am really looking forward to: see what other compilers people will integrate with. I am aware some of the neural network libs have pluggable compilers but it will be interesting to see it done at the tensor level. :)
What José Valim has done in building an entire community around elixir single-handedly is absolutely incredible. Numerical Elixir looks amazing as well.
He has been unbelievably but to say he did it alone is wrong. I think I would say those people who instead of being egotistical understood that Jose is usually right and changed their projects based on his suggestions are just as important. He’s managing to win important projects over to his way of thinking which is different than saying he did everything but arguably even more impressive.
José is an enormous asset to the community and has an influence on many of the marquee projects, but it definitely isn't single-handedly done. He cares about the ecosystem and is very generous with his time and attention.
Anecdotally speaking, he hasn't been hands on with Oban[1], yet he still offers advice and guidance around the project because it is in the Elixir community.
Just sharing the link to your repo is a shameless plug. It would have been better had you shared a snippet of guidance/conversation in either github issue or elixirforum.
But I agree Jose is always helpful and the strongest pillar in the community.
"single handedly"? Really? Jose did a humongous work, but this is so dismissive of all the other people who put time and effort into building the ecosystem and the community.
While there are certainly other evangelists, and Erlang aficionados tend to engage too, I don't think I've seen any discussion of Elixir in a public forum where Jose hasn't been involved, giving well thought out, humble commentary.
As the founder of the language, the lead evangelist, and the main mouthpiece, yes, 'single handedly' may be hyperbolic, but only slightly. It's not to dismiss others' inputs, but it is to highlight how -insanely- engaged he is. I can think of no other language founder who has put in nearly the same legwork.
> I can think of no other language founder who has put in nearly the same legwork.
I don't pay particularly close attention these days, but I'd think Rich Hickey's involvement in Clojure over time, at least to the point Elixir is today, would be comparable.
What a grand find for a logo/mascot: https://twitter.com/josevalim/status/1356880707474370560. An cute animal whose name sounds like "number" for a numerical computation project... and no other similar project has taken it already? I should be jealous but it just makes me happy.
That seems the start of something pretty amazing, I work on a fintech using Elixir and we usually have to delegate all numerical analysis and ML stuff to python microservices, even models with considerably simple execution, and being able to move that logic to Elixir would certainly be very nice (we can always batch train them elsewhere, just running the model is a great deal). Of course, it's definitely going to be a long road before getting to be production ready and somewhat competitive with the ever improving big players (as it is with all languages without supports from major corporations with large interest in the area, languages like Nim, Julia, Clojure and even Swift considering it doesn't have full support on Google, and those languages still have an advantage with their stronger interop with python/java/C).
But after listening to the talk, I went from thinking that Elixir was not a good fit to ML to actually excited with the future. Elixir's pipes are definitely a beautiful and concise way to define transformations, and we already have nice examples of them with Streams and Ecto.Multi that even make it surprisingly nice to debug the readable "tape", and being immutable itself allows it to nicely avoid the hardest parts in translating the language into an execution graph both for the creators of the library and for the user. Modifying the if macro to embed the conditional within the "tape" might be a little too much magic though.
Slightly tangential. I really would like to thank José for creating all of this! I have been using Elixir a lot and the language, the ecosystem and the community are amazingly cohesive, friendly and put a strong emphasis on good uncluttered design. If it was not there, something would be sorely missing. I was wondering if something like nx was coming. Together with Flow and Beam you can put the better part pf GCP in one binary with a few lines of pretty code.
Just from my point of view the actor model seems ideal for simulating three dimensional systems at various levels of fidelity. An actor could exist that does maths for one region (say air in a climate change simulation) and that cube could send messages about its state to various surrounding regions/actors (cubes at the top, bottom, left, right, front and back) and affect them. The more cubes in the system the higher quality the simulation.
Obviously this being on the beam you’d get the ability to run these actors across different computers fairly easily, hopefully scaling quite well.
You could also build FDTD systems like this and even acoustics simulations. I wonder if this is something the authors here are thinking about?
Modelling a problem like this with tons of Erlang processes tends not to go very well:
- It's slow, really slow, and memory heavy. All communication between processes involves copying and context switch.
- It's easy to introduce deadlocks (A calls B calls C calls A - now system is stuck) or unbounded message queue growth (if you use casts rather than calls)
- Everything is a single unit of fault tolerance (if one cell crashes, the entire simulation should be re-initialized from a known state) so all the processes need to be linked together in a massive web, which more or less defeats the point of process isolation.
I think it might make sense in the abstract actor model, it just doesn't map cleanly to Erlang processes.
I’m excited that some neat problems were solved at the level of the programming language. Example: by working with the AST, Nx can automatically differentiate functions. It’s delightful to see how much care has gone into designing Elixir. It’s like José smuggled a Lisp in Ruby’s clothing onto the BEAM.
This makes me happy, love the elixir scene have used Matrex to good effect and wrote a pipeline recently that processes over 10gb (disk IO on the third party service bottle necked us or it would have been a lot more) data a minute through Broadway. Elixir + BEAM are good technologies and looking forward to having more numerical computing capabilities directly available in the language.
I had spent a little time trying to contribute to Tensorflex which was a google summer of code project for TF in elixir but life got too busy to proceed and then I didn't see any movement there so just figured the idea of ML was on pause and outside of Matrex numerics were also on pause. Happy to see it was still going on behind the scenes.
honestly I think it would have been more profitable to modernize ErlPort to better interconnect with the python ecosystem and even other programming languages. I think it will be difficult to move some companies away of their current computation frameworks.
1. Work on modernizing erlport can still happen and be orthogonal to this
2. Moving data in and out of the GPU is expensive, sending the data to another process so it can copy it to the GPU would make us pay the penalty twice (and then again on the way back)
3. And even if you want to go ahead with 2, I would do it over the wire so I don't couple my nodes running Erlang/Elixir to the nodes running the Python stuff (because they may require different specs/scale)
4. We don't need people to move away from their computation frameworks, I will be happy if people start considering building new things on top of this one in the future :)
Its about preventing unnecessary friction while its still entirely avoidable. Yes, naming things is hard but renaming things after the fact is _way_ harder. Nothing exists for Numerical Elixer right now, so now is the perfect time to make the change.
I think the fact that a popular github repo (https://github.com/nrwl/nx), a domain (https://nx.dev/), and loads of blog posts and tutorials exist for the current NX is enough reason to pick something else. Just thinking off the top... how about NeX.
I think just slapping “elixir” at the beginning of the search query will help with the discoverability. Maybe if it gets consistently marketed as “Elixir Nx”, this won’t be a problem.
Elixir’s documentation is so good, however, I would expect most questions will be answered by the documentation directly.
I agree, adding elixir is the likely solution, but my point is "why?". There's no reason to start off on that foot on day 1. And right now is still day 0 so there is still time to rethink it.
What if they did think about it and decided they still wanted to stick with their preferred name?
It's like with trademarks: you can have more than one thing with the same name and not have a problem. If it was another build tool that helped you deal with your git repos that would be a real issue, but it's not... it's aimed at a totally different audience for a totally different reason.
This town is absolutely big enough for the both of them.
Or do you think other people have problems because when they search for, say, Kafka, or Jekyll, they keep finding references to literature instead of the tech they're using?
The project isn't even public yet, has been under development for only a few months, hasn't had the opportunity to get wider academic eyeballs on it yet, and you're already calling it DOA. Nice.
Yeah, this seems like a real disingenuous complaint around a pretty incredible (and still super young) accomplishment. I would also assert that Elixir is an excellent language syntactically to work on data science-y projects. I'm really excited.
Fair point, let me try and ellaborate. Of course, time will tell. But the data science community fixation is on algorithms, not on languages. So you would need to build Tensorflow or Pytorch upon Nx, and you would need to migrate people from the easy Python/Anaconda/Jupyter to the BEAM world. For that to happen the upside should be obviously evident, I guess in terms of performance.
Take, for example, the web world. I believe Phoenix is technically the best framework out there, or at least on par with Rails. And it has not taken the web world by storm (yet). Why would Nx be a success without the support of Google or someone that big?
We will see. Can you move local numpys computations on a cluster by just adding a few lines of code? Because this certainly will be possible with Elixir.
Most importantly it may allow Elixir developers to not switch to C or Rust for intensive computations (hopefully).
We are going to make the repository open source next week and, for those who haven't listened to the podcast, I want to align everyone's expectations and say it is very early material. Expect bugs, breaking changes, etc.
On the other hand, it is also a great time for anyone who wants to jump in and help shape things, so feedback will be very welcome!