Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia Computing raises $24M Series A

hpcwire.com

Post reply on HN
Print view View original

131–140 of 246 posts

Re: Julia Computing raises $24M Series A

#131

Post by galangalalgol »

QuadmasterXLII wrote: post #38
notafraudster wrote: post #30

Earlier quoted context omitted.

What's the argument against using R and dropping into RCpp for very limited tasks? I (helped) write a very widely used R modelling package and while I wasn't doing anything on the numerical side, we seemed to get great performance from this approach -- and workflow-wise it wasn't too dissimilar to 25 years ago where I had to occasionally drop in X86 assembly to speed up C code! (Not a hater of Julia at all, very much…

I think that's just being clumped in with "Use C++," which he mentioned as an option

and the ffi adds a lot of overhead for granular data. Julia just works fast. My only friction has been offline development, which isn't well supported yet.

Re: Julia Computing raises $24M Series A

#132

Post by mbauman »

nojito wrote: post #125
mbauman wrote: post #97

Earlier quoted context omitted.

> The fastest data.frame library in ALL interpreted languages is consistently data.table, which is R. DataFrames.jl is very rapidly catching up and starting to surpass it. After hitting a stable v1.0 they've begun focusing on performance and those benchmarks have changed significantly over the past three months. Here's the live view: https://h2oai.github.io/db-benchmark/

40% slower in groupbys and 4x slower in joins isn’t convincing.

Oh I agree. What's convincing to me is the momentum. The DataFrames.jl team only started focusing on performance three months ago after hitting v1.0[1] and were able to rapidly become competitive with groupbys; the performance of join is next[2]. Compare the live view with the state when grandparent's blog post was written/updated (March of this year).

I expect it to continue to improve; note that it's starting to be the fastest implementation on some of the groupby benchmarks.

1. https://discourse.julialang.org/t/release-announcements-for-...

2. https://discourse.julialang.org/t/the-state-of-dataframes-jl...

Re: Julia Computing raises $24M Series A

#133

Post by freemint »

nojito wrote: post #125
mbauman wrote: post #97

Earlier quoted context omitted.

> The fastest data.frame library in ALL interpreted languages is consistently data.table, which is R. DataFrames.jl is very rapidly catching up and starting to surpass it. After hitting a stable v1.0 they've begun focusing on performance and those benchmarks have changed significantly over the past three months. Here's the live view: https://h2oai.github.io/db-benchmark/

40% slower in groupbys and 4x slower in joins isn’t convincing.

This seems quiet cherry picked as there are 3 different dataset sizes.

However yes, it does not beat all other packages tested in performance.

Re: Julia Computing raises $24M Series A

#134

Post by snicker7 »

systemvoltage wrote: post #68
awaythrowact wrote: post #39

Congrats to the Julia team. I am a python developer who has dabbled with Julia but it never stuck for me. I think Julia was built by academics for other academics running innovative high performance computing tasks. It excels at the intersection of 1) big data, so speed is important, and 2) innovative code, so you can't just use someone else's C package. Indeed, Julia's biggest successful applications outside academi…

Great summary. I've worked with scientists that love Julia and more power to them. As a software engineer, there are still rough edges in productionizing Julia (yes, I know there are a few examples of large scale production code). As soon as you take Julia out of notebooks and try to build moderately complex apps with it, you realize how much you miss Python. Having used Julia for last 4 years and having to maintain…

What warts did you encounter? What language features / tooling would make Julia easier to productionize?

Re: Julia Computing raises $24M Series A

#135

Post by freemint »

tylermw wrote: post #128
spywaregorilla wrote: post #121

Earlier quoted context omitted.

> You can write fast software with R, you just need to know how. When the trick to writing fast R code is to rely on C as much as possible, that feels less compelling.

While writing in C is one way to speed up R code, you can also get pretty close to compiled speed by writing fully vectorized R code and pre-allocating vectors. The R REPL is just a thin wrapper over a bunch of C functions, and a careful programmer can ensure that allocation and copy operations (the slow bits) are kept to a minimum.

This is good if your code can be expressed in vectorized operations and doesn't gain benefits from problem structure exploited by multiple dispatch. With R the best you can is the speed of someone else's (or your) C code while Julia can beat C.

Re: Julia Computing raises $24M Series A

#136

Post by systemvoltage »

amkkma wrote: post #86
systemvoltage wrote: post #68

Earlier quoted context omitted.

Great summary. I've worked with scientists that love Julia and more power to them. As a software engineer, there are still rough edges in productionizing Julia (yes, I know there are a few examples of large scale production code). As soon as you take Julia out of notebooks and try to build moderately complex apps with it, you realize how much you miss Python. Having used Julia for last 4 years and having to maintain…

> As soon as you take Julia out of notebooks and try to build moderately complex apps with it, you realize how much you miss Python Why's that? What features or lack thereof of Julia contribute to that experience?

There is too much to talk about and I’d want to give an objective impression with examples in a blog post, but one of the major grips I have is how little information Julia provides you with stack traces. Debugging production problems with absolutely zero clue of what/where the problem might be is one of the most frustrating aspects. I’ve spent so many hours debugging Julia using print statements. Debugger is janky, Juno/Atom support is not very good. Nothing feels polished and robust. Dependencies break all the time. We are stuck with Julia 1.2 and too much of an undertaking to go to latest version. Package management is an absolute disaster - this is the case with Python but Julia is worse. Julia Registry has many issues (compat errors). Testing and mocking is also underwhelming. I think startup times have improved but still not very developer-friendly. Sorry not an objective answer you’re looking for. There also things that Python has such as excellent web-dev ecosystem and system libs that are missing in Julia. Python has everything. Want to generate a QR code image? Easy in Python. Want to create PDF reports with custom ttf fonts? A breeze in Python.

Re: Julia Computing raises $24M Series A

#137

Post by UncleOxidant »

ampdepolymerase wrote: post #81
krastanov wrote: post #46

Earlier quoted context omitted.

There is another important niche I am particularly excited about: programming language research geeks and lisp geeks. The pervasive multiple-dispatch in Julia provides such a beautiful way to architecture a complicated piece of code.

Those two niches don't pay. They are effectively useless outside of the occasional evangelism on HN.

There's a Compiler and Runtime Engineer position listed at https://juliacomputing.com/jobs/ which presumably pays money.

Re: Julia Computing raises $24M Series A

#138

Post by freemint »

sneilan1 wrote: post #113

I'm confused as to why Julia, a programming language is worth so much money. If the makers of Julia have already given away their source code here, https://github.com/JuliaLang/julia what are they selling that's worth a 24 million series A round? Is the Julia business model similar to Redhat or Canonical where they sell consulting services?

Julia Computing is a company that employs (some of) the core contributors of Julia and develops enterprise solutions.

Such as:

- the first Julia IDE Juni now depreciated.

- On premise package server

- A wrapper over AWS called JuliaRun that has a nice web interface

- paid "we make a core developer stare at RR traces of your problems"

- FDA approved software for drug development and pharmacokinetics as https://juliacomputing.com/products/pumas/

It is not the programming language that is the product.

Re: Julia Computing raises $24M Series A

#139

Post by oscardssmith »

gnicholas wrote: post #103

Are A-rounds now well into the $20M range? I remember when they hit $10M and assumed they had continued to grow somewhat. But I didn't realized we'd blown well past $20M — when did that happen?

I think a lot of it is that this is a series A for a 6 year old company that is already making money. Most other startups would be on series B, so comparing this number to a 10 person startup for a company that doesn't have a product yet doesn't make a lot of sense.

Re: Julia Computing raises $24M Series A

#140

Post by oxinabox »

amkkma wrote: post #109
ziotom78 wrote: post #62

Earlier quoted context omitted.

I am using Julia extensively since 2013, and I can say that it's awesome! But don't try to use it if you're looking for a general-purpose scripting language: Python is far better suited for this. Similarly, if you want to produce standalone executables, C++, Rust, Go or Nim are better. However, Julia is perfect if you write mathematical/physical/engineering simulations and data analysis codes, which is my typical use…

>Python is far better suited for this. Similarly, if you want to produce standalone executables, C++, Rust, Go or Nim are better. That's the case now, because Julia made a design decision to focus on extreme composability, dynamism, generic codegen etc which involved compiler tradeoffs...but it's not inherent to the langauge. For scripting, interpreted Julia is coming. For executables, small binary compilation is as…

> For scripting, interpreted Julia is coming.

Citation for this? Julia has had a built-in interpretted since 1.0, in 2017 use `--compile=min`, or `--compile=none` to make use of it. And JuliaInterpretter.jl has been working since 2018. Both are very slow -- slower than adding in the compile time for most applications. As I understand it, this is because a number of things in how the language works are predicated on having a optimizing JIT compiler. As is how the standard library and basically all packages are written.

Julia is going to over time become nicer for scripting, just because of various improvements. In particular, I put more hope on caching native code than on any new interpreter.

Post reply on HN