[HN Gopher] Jose Valim Reveals "Project Nx" (Numerical Elixir) [...
___________________________________________________________________
Jose Valim Reveals "Project Nx" (Numerical Elixir) [audio]
Author : thibaut_barrere
Score : 297 points
Date : 2021-02-09 12:26 UTC (10 hours ago)
(HTM) web link (thinkingelixir.com)
(TXT) w3m dump (thinkingelixir.com)
| josevalim wrote:
| Hi everyone, thanks for the enthusiasm so far!
|
| 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!
| ssivark wrote:
| 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, before swapping
| to another process? (Especially for really heavy computation).
| Is the BEAM compatible with this mode of usage, or is this not
| a concern? Will process scheduling have to be micromanaged?
| dnautics wrote:
| (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.
| tomphoolery wrote:
| When does the actual news start? Clicking around this podcast is
| annoying.
| graydsl wrote:
| It starts like 8 minutes in. The whole podcast is about Nx
| basically.
| auraham wrote:
| Numerical Elixir? Exciting news! I wish it would be something
| like Numpy. It would be awesome.
| heeton wrote:
| That's what it is :)
| juhatl wrote:
| I'm really excited about this project. Seeing Elixir inch this
| much closer to being a viable option for machine learning and
| related fields is great.
|
| In case someone here wants to read rather than listen to all the
| details, I wrote down some notes over at:
| https://elixirforum.com/t/anyone-who-wants-to-speculate-abou...
| flyingfences wrote:
| Thanks, that actually explains it pretty well:
|
| > Nx = Project for a collection of libraries. Nx is the core
| library, the other libraries depend on this core library
|
| > If you come from Python, it can be though of as kind of like
| Numpy. Long way to go but working on that.
|
| > "Slowness in Elixir" due to immutability and copying etc.
| Performance comes from module that is part of Nx called
| Numerical Definitions
|
| > In the definition you write with a subset of Elixir. Elixir
| kernel is replaced with Numerical kernel.
|
| > Based on Google XLA (accelerated linear algebra)
|
| > You can give it a computation graph and exla compiles it to
| run efficiently on CPU or GPU
| dynamite-ready wrote:
| So, two questions. Is this a standard library module, and
| does this run on the GPU?
| BadInformatics wrote:
| 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.
| josevalim wrote:
| 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. :)
| BadInformatics wrote:
| That's great to hear. I'd love to see the Bazel
| monstrosity that is Tensorflow XLA get easier to build
| because of Nx. Not holding my breath though!
| josevalim wrote:
| Yeah, I would love if we could depend only on XLA. I
| think other communities like Julia could benefit from it
| too.
| JamesSwift wrote:
| Sigh... nx is already a (well known) thing in the dev space.
|
| https://nx.dev/
| ashton314 wrote:
| 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.
| JamesSwift wrote:
| 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.
| ljm wrote:
| 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?
| benatkin wrote:
| There are multiple namespaces within the dev space, and I see
| no conflict here.
|
| I use nx.dev and hope they see it the same way.
| sjtgraham wrote:
| Yea, I totally agree. We should just stop naming things at this
| point and just assign everything a UUID v4 label instead.
|
| /s
| JamesSwift wrote:
| 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.
| [deleted]
| bcardarella wrote:
| Sigh... another Sigh... complaint on HN about naming... sigh...
| <head desk> Thank you for sigh... pointing out sigh... the
| obvious sigh...
| Kototama wrote:
| I'm looking forward to use Nx with Nix!
| andy_ppp wrote:
| 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?
| Grimm1 wrote:
| 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.
| jeremy_k wrote:
| 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.
| dimitrios1 wrote:
| 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?
| jeremy_k wrote:
| 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.
| spamizbad wrote:
| 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.
| jeremy_k wrote:
| 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.
| bcrosby95 wrote:
| 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.
| hinkley wrote:
| 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.
| dimitrios1 wrote:
| (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.
| RobertKerans wrote:
| 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).
| gurkendoktor wrote:
| > 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.
| pjmlp wrote:
| Thankfully JetBrains isn't the only option.
| davidw wrote:
| 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.
| devoutsalsa wrote:
| 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.
|
| Just my two cents.
| davidw wrote:
| I think those are all pretty good fits.
|
| 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.
| toolz wrote:
| 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.
| devoutsalsa wrote:
| 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.
| toolz wrote:
| sure, but which languages would be capable of dodging the
| "not enough libraries" complaint if java is the baseline?
| Maybe 2 or 3?
| zumu wrote:
| > or when you're company decides to go all in on Kafka
| for communication between micro services.
|
| What's the issue with Kafka and Elixir?
| pselbert wrote:
| 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.
| [deleted]
| dudul wrote:
| For what tasks is the BEAM not "good enough to get
| something up and running"?
|
| AFAIK, any modernish language is good enough to get
| something up and running regardless of the task.
| davidw wrote:
| 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.
| dragonwriter wrote:
| > 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.
| monadic3 wrote:
| 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.
|
| If you're running a server--sure, BEAM me up.
| bcrosby95 wrote:
| 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.
| acoard wrote:
| >For certain problems
|
| 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.
| bcrosby95 wrote:
| 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.
| dnautics wrote:
| I would have suggested ets tables + entity system.
| bcrosby95 wrote:
| 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.
| toast0 wrote:
| 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.
| dnautics wrote:
| Probably the best you're going to get for a generalized c
| call library is rustler or zigler (I maintain zigler)
| toast0 wrote:
| 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 ;)
| dnautics wrote:
| challenge accepted:
| https://github.com/ityonemo/zigler/issues/240
| strokirk wrote:
| 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.
| hwatkins wrote:
| 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.
| mgreenleaf wrote:
| 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.
| dragosmocrii wrote:
| Code elegance and development joy, maybe? I know Java has a
| mature ecosystem, but I wouldn't touch it with a stick
| dimitrios1 wrote:
| 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.
| dragosmocrii wrote:
| 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.
| dimitrios1 wrote:
| 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.
| [deleted]
| karmakaze wrote:
| 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.
| appleflaxen wrote:
| Jose Valim is so prolific; I love seeing what he comes up with.
| ddragon wrote:
| 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.
| ashton314 wrote:
| 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 Jose
| smuggled a Lisp in Ruby's clothing onto the BEAM.
| nudpiedo wrote:
| 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.
| josevalim wrote:
| A couple notes:
|
| 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 :)
| [deleted]
| halotrope wrote:
| Slightly tangential. I really would like to thank Jose 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.
| andrewflnr wrote:
| 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.
| ibraheemdev wrote:
| What Jose Valim has done in building an entire community around
| elixir single-handedly is absolutely incredible. Numerical Elixir
| looks amazing as well.
| dragosmocrii wrote:
| Good for him, and good for us. I really like elixir
| pselbert wrote:
| Jose 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.
|
| 1: https://github.com/sorentwo/oban
| andy_ppp wrote:
| 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.
| dudul wrote:
| "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.
| lostcolony wrote:
| 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.
| macintux wrote:
| > 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.
| pantulis wrote:
| For this to gain traction needs to be adopted by the data-science
| community. It does not feel like that.
| bcardarella wrote:
| 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.
| m8s wrote:
| 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.
| Kototama wrote:
| 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).
| sfusato wrote:
| How did you measured that already? The "baby" is yet to be
| born. We found it's "name" just a few hours ago.
| pantulis wrote:
| 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?
| detaro wrote:
| Why must "take the X world by storm" be the goal?
| dnautics wrote:
| I'll tell you why I'm cautiously bullish on Nx.
|
| 1) python really does not have broad cultural discipline around
| testing. Especially not in the ml field.
|
| 2) deploying python is not the best.
|
| 3) unlike TF, torch is actually not hard to understand and the
| code should be easily movable and portable out of it.
|
| Small time ML users will care about 1&2. 3 makes it relatively
| painless.
___________________________________________________________________
(page generated 2021-02-09 23:00 UTC)