Is anyone else concerned that despite being an open-source project with permissive licensing, the formation of the Julia Computing group has made Julia's development a bit of a walled garden? I don't mean this in the sense that Apple or Matlab are "walled gardens", but the for-profit company, of which many core developers are founders/employees, develops a number of tools and services that are not open-source AFAIK.
I believe the group also implicitly controls what packages are allowed/disallowed from the packages list. At the same time, I also recognize the need to support the core developers and the business model makes a lot of sense. Thoughts?
"the formation of the Julia Computing group has made Julia's development a bit of a walled garden".
I'm not sure what you mean. As far as I can see, Julia Computing is not rich enough to take over development of the language, even if that is what they wanted to do. It's just a way for those guys to get paid for their full-time commitment to Julia, and a fairly standard one, as far as I can see. Language developers that aren't funded by a large existing company tend to do consultancy to pay the bills.
Not concerned at all. It's great. It's a modern, fresh, honest approach.
The only concern would be if an ad company like Google or Facebook would buy them. Hope this never happens and they stay independent (but very successful and rich and everything)
I am not sure what prompts the statement about Julia Computing implicitly controlling what packages are allowed/disallowed. Pretty much everything is allowed so long as it conforms to minimum published requirements.
The process is carried out completely in the open on github in the METADATA.jl repository. Such statements can be very damaging to the community, when made without solid proof.
Is our package management as good as it can be. No - and we are working on Pkg3. Is the process sometimes tedious - Yes, it sometimes is. But is it controlled by some group at Julia Computing - Definitely not.
There was a long thread about Julia / Julia Computing here: https://groups.google.com/forum/#!topic/julia-users/1zIlXQYb... . Viral said in the first post that "We will respond [to questions] back with a detailed blog post." They answered a subset of concerns on the list, but to my knowledge such a blog post does not exist.
Other than issues I mentioned in that thread, my main ongoing concern is that it is unclear where the boundary between Julia the community project (which includes their non-profit fiscal sponsorship via Numfocus) and Julia Computing, the company. Who owns the Julia trademark? Who owns the julialang.org domain? Who, ultimately, controls the direction of the project?
Ultimately, I want Julia to last for a long time, and for it to remain free software. I get the impression that all the founders want the same thing, which is encouraging. But even more encouraging would be to see the community's governance structured in a way that enforces this.
I really wish they had implemented Julia in C++11, instead of C. The source code seems to be very difficult to comprehend for anyone who is not one of the original developers. [1]
Julia is mostly (> 65 %) written in Julia. There's some C (20 %, bootstrap etc.), some C++ (8 % llvm interface), some scheme (4 %, parser). I think it's one of the main points, that Julia should be strong enough that such things _can_ be written in itself.
Go was initially written in C. I think many consider C++ to be unnecessarily complicated and avoid it at the lowest level.
Programming language runtimes tend to be somewhat complex (real world ones, at least). The implementation of the internals of a modern LLVM-based JIT language is bound to be somewhat "esoteric" regardless of what it's written in – using C++11 wouldn't change that. The developer docs are pretty comprehensive these days and a significant number of people have "picked it up" and become serious contributors to Julia's internals. In fact, of the people who hack on internals the most these days, none are original developers. (I'm thinking of Jameson, Yichao and Keno for those who are familiar with Julia's development.)
I don't understand why Gadfly is the top repo. I always found it to be very slow and having too many dependencies. Last I remember it installs more than 20 packages as dependencies. Its also not a supported backend in Plots.jl
I really like the user interface for this — very smooth and modern design. As someone who has a lot of Julia packages installed, this looks great for searching and finding new ones.
Cool site, thanks. As part of learning julia I created a similar resource for the browsing the built-in functions. e.g.: http://www.jlhub.com/julia/manual/en/function/rand It allows browsing the functions that exist by function group and I added examples for the functions that I was playing with. Lately I added the ability for users to submit their own examples, as this is something I found very useful from the php documentation. Submissions welcome!
I'm really anxious for Julia to start taking packaging more seriously. Pkg2 situation is pretty terrible imo, and the pkg3 whispers just sort of strike me as offputting, since there's basically no timeline of when they'll make it to a stable 0.x release and the 1.0 is just a "when it's ready" situation.
Julia is one the most pleasant programming experiences I've had otherwise. It's the Lua I've always wanted, with just the right mix of Scheme, but not too much that it tastes Haskell-y.
But yeah, current packaging situation is awful.
Oh, that reminds me though, Julia has a lot of really incredible packages already. It's mindblowing how quick Julia went from "new technical computing language" to "general purpose, performant language with a ton of useful packages readily available and they actually work"
Leveraging the technical computing open source community turns out to work really well!
the metaprogramming resources in Julia are very slick. I wrote a DSL that lets you write functions in that are then turned into synthesizable verilog modules. Implementing combinatorial logic (I haven't gotten to sequential yet) took about three days.
Yeah, meta is something I always struggled with in Lua, as you're completely constrained to the table structures, but just that little extra power of being able to metaprogram over whatever data I want, is absolutely incredible, and it's a bit easier to think about imo than Scheme macros just in the sense of trying to macroexpand in your head.
> Julia has a lot of really incredible packages already. It's mindblowing how quick Julia went from "new technical computing language" to "general purpose, performant language with a ton of useful packages readily available and they actually work". Leveraging the technical computing open source community turns out to work really well!
Yep, it turns out that a lot of scientists are great programmers :)
Regarding packaging, I completely agree that Pkg2 is a mess; there's a Julep (RFC) out for Pkg3 and it opens with a sobering list of the problems with Pkg2's design, and continues with a new design which is already in the works:
The Julep is a rough cut of what Pkg3 will look like (see issues on that repo for some modifications), but I'm actively working on an implementation. For example, yesterday, I was working on a script to translate the current METADATA repository to a Pkg3 registry file.
I'm not sure what "make it to a stable 0.x release" means – every 0.x release is stable and usable, we're just not 100% happy with the language design and APIs yet – at least not satisfied enough to commit to supporting them for the next decade. But that's coming soon... Julia 1.0 will be released this summer (2017), which I announced during the talk I gave at JuliaCon last summer:
The 0.6 release has slipped by 1.5 months, but it also includes more features, so it doesn't actually push the 1.0 release schedule back. During this release cycle, we realized that a number of changes we want in 1.0 need to be at least partly in place in 0.6 so there's a smooth upgrade path to 1.0 that doesn't break people's code without deprecation warnings. We decided that it was worth letting this release slip a bit in order to have a clear path forward to 1.0. Once 0.6 is out, I will post a 1.0 release timeline.
I believe the group also implicitly controls what packages are allowed/disallowed from the packages list. At the same time, I also recognize the need to support the core developers and the business model makes a lot of sense. Thoughts?