ide VS RCall.jl

docs (https://enso.org/docs/syntax). We've added many new libraries, so you can do many more things with it now. Oh, and we changed the name to Enso and got accepted to YC! :)

The problem we address is that data analysts still waste up to half of their time on repetitive manual work that can be automated [6]. To give one example, a company we're working with hires business users who use Excel to define data quality rules. These get manually translated to SQL, then manually translated to Python. This is not only error prone, it’s so slow that it takes them 90 days to introduce a single new rule. There’s 60 days’ worth of overhead in this process—it’s insane!

Years ago I (Wojciech) led the in-house development of visual effects (VFX) tools at a motion picture studio. We made tools like cloud renderers and smoke simulation engines. The artists using these tools did not have any programming background, yet they were designing complex algorithms for forces between particles, light subsurface scattering, things like that. Earlier generations of these tools had hundreds of config options, buttons, etc., for masses of different use cases, but this approach got way too complex and people eventually realized that it falls short when you need to do anything that the vendor did not think of. Nowadays they use node-based software (like the Houdini FX) which lets users draw algorithms as a sequence of data processing steps (these steps are often referred to as “nodes”). Later, when I was working in other industries and encountered the same rats’ nests of complex GUIs for solving data processing problems, I realized that the data analytics/science space was in need of the same breakthrough that we had already gone through in the VFX space.

Most visual programming languages / workflow-builders do not scale well because they don't let users express abstractions. Try to build a complex pipeline and you'll end with an unreadable spaghetti of connections—it's like coding a web app in the assembler. Enso is different because we allow you to build abstractions to manage the complexity. As a result, you never have more than 10-20 nodes on the stage in Enso (nodes are hierarchical). You can create custom data types, custom components (functions), catch errors, etc. All this works because under the hood, Enso is a real programming language. However, naive implementations of such systems are super slow. Each component may be built of hundreds, sometimes thousands of lower-level ones. The real trick is making these hierarchical components run fast. For that you need a dedicated compiler and a runtime system, and this is a hard technical space. Our system involves a dedicated JIT compiler based on GraalVM. For details, see https://enso.org/language#compiler. In case this is interesting for you, here is our podcast about how the compiler works under the hood: https://www.youtube.com/watch?v=BibjcUjdkO4.

Enso is interactive, meaning that we recompute the relevant parts of graphs as parameters change, which shortens feedback loops dramatically. Like a lot of people on HN, we were inspired by Bret Victor's classic talk on instant feedback: https://www.youtube.com/watch?v=8QiPFmIMxFc. We’ve also put a lot of effort into extensibility. You can add Java, JavaScript, R, and Python (soon also Ruby, Scala, Kotlin, Rust, and C) directly into Enso nodes without the need to write any wrappers and with a close-to-zero performance overhead.

Enso is open source. Our compiler code is at https://github.com/enso-org/enso and our GUI code at https://github.com/enso-org/ide. Our business model is based on selling domain specific libraries, on-premise installations with enhanced user permission management, and coming soon, a hosted solution called Enso Cloud, which will be our only non-open-source codebase. Since this is Hacker News, I should add that all our alpha releases collect anonymous usage statistics which we use to improve Enso and prepare it for a stable release. Full details about that are always in our release notes (https://github.com/enso-org/ide/releases/latest).

Dear HN Family, we are super excited to show Enso to you. Please, share with us your thoughts, experiences, ideas and feedback. It is insanely important to us, as our dream is to make Enso the most useful data processing platform in your toolbox! Also, in case you’d like to build your projects on top of Enso, we would love to help you do it – describe what you have in mind here, and we will reach out to you: https://airtable.com/shrsnx2mJuRn0MxIS :)

=== Links ===

[1] Luna: Visual and textual functional programming language* - https://news.ycombinator.com/item?id=11144828 - Feb 2016 (100 comments)

Enso the language is mostly scala, Enso the IDE, which is very much an integral part of the project, is like 90% Rust.

The whole IDE (cloud + desktop one) is written in Rust. It lives in this repo: https://github.com/enso-org/ide :)

These issues with random zoom in/out or with selection problems are not known. We haven't seen them before. Would you be so nice to create a screencast and post it as an issue / issues on our issue tracker? This would allow us to track it and fix it for the next release: https://github.com/enso-org/ide/issues .

Hi, Wojciech, one of Enso founders here! We are just preparing for Enso 2.0 release. If you want to play with it, you can download the current build from our GitHub releases page (https://github.com/enso-org/ide/releases) and see intro tutorials here: https://www.youtube.com/channel/UC4oMK7cL1ElfNR_OhS-YQAw

:)

I don't use it personally, but RCall.jl[1] is the main R interop package in Julia. You could call libraries that have no equivalent in Julia using that and write your own analyses in Julia instead.

[1] https://github.com/JuliaInterop/RCall.jl

You can have your cake and eat it with the likes of

* PythonCall.jl - https://github.com/cjdoris/PythonCall.jl

* NodeCall.jl - https://github.com/sunoru/NodeCall.j

* RCall.jl - https://github.com/JuliaInterop/RCall.jl

I tend to use Julia for most things and then just dip into another language’s ecosystem if I can’t find something to do the job and it’s too complex to build myself

To inter-operate Julia with the R language, the RCall package is used. Run the following commands on the Julia REPL

https://github.com/JuliaInterop/RCall.jl may help

If you need to bindings to your existing R packages then Julia is the way. Check out RCall.jl

I have no experience with R, but maybe this will be of use: https://github.com/JuliaInterop/RCall.jl

You can use RCall to use R from Julia: https://github.com/JuliaInterop/RCall.jl

I worked with R and Python during the last 3 years but learning and dabbling with Julia since 0.6. Since the availability of [PyCall.jl] and [RCall.jl], the transition to Julia can already be easier for Python/R users.

I agree that most of the time data wrangling is super confortable in R due to the syntax flexibility exploited by the big packages (tidyverse/data.table/etc). At the same time, Julia and R share a bigger heritage from Lisp influence that with Python, because R is also a Lisp-ish language (see [Advanced R, Metaprogramming]). My main grip from the R ecosystem is not that most of the perfomance sensitive packages are written in C/C++/Fortran but are written so deeply interconnect with the R environment that porting them to Julia that provide also an easy and good interface to C/C++/Fortran (and more see [Julia Interop] repo) seems impossible for some of them.

I also think that Julia reach to broader scientific programming public than R, where it overlaps with Python sometimes but provides the Matlab/Octave public with an better alternative. I don't expected to see all the habits from those communities merge into Julia ecosystem. On the other side, I think that Julia bigger reach will avoid to fall into the "base" vs "tidyverse" vs "something else in-between" that R is now.

[PyCall.jl]: https://github.com/JuliaPy/PyCall.jl

[RCall.jl]: https://github.com/JuliaInterop/RCall.jl

[Julia Interop]: https://github.com/JuliaInterop

[Advanced R, Metaprogramming] by Hadley Wickham: https://adv-r.hadley.nz/metaprogramming.html