6 ms·

Yes. But only computer scientists are interested only in the language itself. I am an engineer so I have to deal with practical aspects of it.

jackcviers3 6y ago
I'm an engineer. I primarily care about how good the language is at expressing and executing my intent. I've been around long enough to see several tooling fads come and go. I've also been around enough to know that the barrier for delivering quality software is becoming insurmountable, and the additional tooling and infrastructure isn't resulting in projects being more successful, nor being delivered more quickly, nor being less costly than when I started. Teams are enormous now. Software projects are enormous. Deployment requires deep knowledge of multiple hosting platforms and various cloud provider apis at the enterprise level. Available libraries, increasing reliance upon testing, type safety, and better development life cycle practices have had a far larger impact than the ide's I've seen come and go. In my experience, a particular tool has a popularity lifecycle of about ten years. Vscode and lsp will probably be the same. Give me types, good compiler error output, and access to a large universe of libraries with good documentation over relying upon ide api discovery any day of the week and twice on Sundays. The rest is an ever-changing tide of requirements fashion.
- kuzuman 6y ago
  "I am an engineer" Did you pass the Fundamentals of Engineering exam, are you a member in order of your local association of engineers?, do you have an engineer seal? If you answer no to the questions above please don't call yourself engineer
KenoFischer 6y ago
Give us some more time, there's just so many things to do and the reliance issues favor getting the fundamentals right first (much easier to switch the debugger UI than the names of functions that'll get put all over the place). We certainly understand the value of good tooling, so just stay tuned and maybe try it again every once in a while to see if it's good enough for you yet. Too much to do, too little time :)
bwanab 6y ago
I think this is an important point. What a practitioner can do with a language is influenced as much by the tooling as with the language itself. The implication is that languages should be constructed with as much thought given to the external tooling as to the compiler or interpreter. Julia in particular is built to be a practical language so, these points are valuable.
systemvoltage 6y ago
I agree with you 100%. Julia is a language that is half baked for engineering use. Any one who has ever built anything beyond examples and tutorials, something production worthy and used by hundreds of people - they will attest to how immature Julia is. That's not the fault of the programming language per se... just that it takes 10+ years to get up to speed in terms of tooling and engineering worthiness. In addition, there are a lot of problems with the language itself some of which are highlighted in the top comment of this thread.
- ChrisRackauckas 6y ago
  I've built production software being shipped to pharmaceutical companies and used in FDA submissions using Julia (pumas.ai) because it is quite mature in the field of modeling and simulation in comparison to other languages. The stability of the language along with the ability to easily get fast code is the main reason, and it's the reason why if you go to something like the American Conference on Pharmacology (ACoP) you'll hear lots of mentions of Julia.
  - systemvoltage 6y ago
    I've also built several production systems and it has nothing but nightmare. Stack traces are meaningless and there were so many issues with things like ISO Time Zones, HTTP requests (why isn't there a solid http request library? its a mess), Docker problems with compilation, start times were atrocious and still are I think, package management is insane, setting up an internal julia repository is a total nightmare - just go on SO and search for it. I've lived through this.
- nathandaly 6y ago
  We use Julia in production at RelationalAI. Our cloud hosted next generation knowledge graph management system is a highly performant database and query optimization engine, and it's written 100% in Julia. We love Julia for the same reasons others have stated here: It's easy and intuitive to write, making it productive to work with for both our engineers and our mathematicians. It's reflection abilities make performance tuning and optimization easier than any experience I've had before. The ability to fine tune the assembly emitted for your hotspots _matters_, and it's straightforward to do in Julia. And for the rest of the code, being easy to write, easy to read, and close to the math are all a big win.

jackcviers3 6y ago

I'm an engineer. I primarily care about how good the language is at expressing and executing my intent. I've been around long enough to see several tooling fads come and go. I've also been around enough to know that the barrier for delivering quality software is becoming insurmountable, and the additional tooling and infrastructure isn't resulting in projects being more successful, nor being delivered more quickly, nor being less costly than when I started. Teams are enormous now. Software projects are enormous. Deployment requires deep knowledge of multiple hosting platforms and various cloud provider apis at the enterprise level. Available libraries, increasing reliance upon testing, type safety, and better development life cycle practices have had a far larger impact than the ide's I've seen come and go. In my experience, a particular tool has a popularity lifecycle of about ten years. Vscode and lsp will probably be the same. Give me types, good compiler error output, and access to a large universe of libraries with good documentation over relying upon ide api discovery any day of the week and twice on Sundays. The rest is an ever-changing tide of requirements fashion.

kuzuman 6y ago
"I am an engineer" Did you pass the Fundamentals of Engineering exam, are you a member in order of your local association of engineers?, do you have an engineer seal? If you answer no to the questions above please don't call yourself engineer

KenoFischer 6y ago

Give us some more time, there's just so many things to do and the reliance issues favor getting the fundamentals right first (much easier to switch the debugger UI than the names of functions that'll get put all over the place). We certainly understand the value of good tooling, so just stay tuned and maybe try it again every once in a while to see if it's good enough for you yet. Too much to do, too little time :)

bwanab 6y ago

I think this is an important point. What a practitioner can do with a language is influenced as much by the tooling as with the language itself. The implication is that languages should be constructed with as much thought given to the external tooling as to the compiler or interpreter. Julia in particular is built to be a practical language so, these points are valuable.

systemvoltage 6y ago

I agree with you 100%. Julia is a language that is half baked for engineering use. Any one who has ever built anything beyond examples and tutorials, something production worthy and used by hundreds of people - they will attest to how immature Julia is. That's not the fault of the programming language per se... just that it takes 10+ years to get up to speed in terms of tooling and engineering worthiness. In addition, there are a lot of problems with the language itself some of which are highlighted in the top comment of this thread.

ChrisRackauckas 6y ago
I've built production software being shipped to pharmaceutical companies and used in FDA submissions using Julia (pumas.ai) because it is quite mature in the field of modeling and simulation in comparison to other languages. The stability of the language along with the ability to easily get fast code is the main reason, and it's the reason why if you go to something like the American Conference on Pharmacology (ACoP) you'll hear lots of mentions of Julia.
- systemvoltage 6y ago
  I've also built several production systems and it has nothing but nightmare. Stack traces are meaningless and there were so many issues with things like ISO Time Zones, HTTP requests (why isn't there a solid http request library? its a mess), Docker problems with compilation, start times were atrocious and still are I think, package management is insane, setting up an internal julia repository is a total nightmare - just go on SO and search for it. I've lived through this.
nathandaly 6y ago
We use Julia in production at RelationalAI. Our cloud hosted next generation knowledge graph management system is a highly performant database and query optimization engine, and it's written 100% in Julia. We love Julia for the same reasons others have stated here: It's easy and intuitive to write, making it productive to work with for both our engineers and our mathematicians. It's reflection abilities make performance tuning and optimization easier than any experience I've had before. The ability to fine tune the assembly emitted for your hotspots _matters_, and it's straightforward to do in Julia. And for the rest of the code, being easy to write, easy to read, and close to the math are all a big win.