4 ms·

To be fair, most of these are ide complaints, not language complaints. Much like all development work, language designers are now required to know much more th

To be fair, most of these are ide complaints, not language complaints. Much like all development work, language designers are now required to know much more than how to write an effective static compiler, an effective language syntax, and an effective standard library. A working IDE that integrates easily with all mainstream editors, extensions for all mainstream editors, cross-platform compilation for all major environments, a secure and effective dependency manager, a secure and effective build tool, and incremental compilation are all requirements for a language to get off the ground. Honestly, that seems like a big hurdle for one person or even a dedicated team to manage effectively without major funding outside of what is normally present in research grants. Hosting and curation alone for the dependency package system is a costly problem. Are we as developers painting ourselves into a corner of stagnating pl technology with our expectations that all these things exist in order for us to call a language "good?"

tasubotadas 6y ago
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.
enraged_camel 6y ago
>>To be fair, most of these are ide complaints, not language complaints. The language itself doesn't matter without its ecosystem. This includes tooling, libraries, quality of documentation, the community, and more.
- systemvoltage 6y ago
  This is why I think its mostly non-engineers commenting about how great Julia is. No one has tried to deploy it prod. Sure there might be exceptions, but if you interview 100 engineers who've tried deploying Julia, a vanishingly small % would recommend it if at all.
  - jackcviers3 6y ago
    I'm not commenting on Julia per se. I'm commenting on the state of discussions surrounding programming languages in general. > if you interview 100 engineers who've tried deploying Julia, a vanishingly small % would recommend it if at all. Popularity of a choice does not correlate with a choice being correct. It is a fallacy to evaluate a particular tool's usefulness for a particular job by how popular that tool is. And doubly so when most of a random sampling of engineers includes virtually no one experienced in using said tool. In discussions of virtually any non-popular programming language today, the vast majority of commenters on the language have absolutely 0 experience using it day in and day out for its intended use case. All you have in that discussion are hammer users. To them everything is a nail. And they universally hate any new tool that doesn't look like a hammer, because they can't take the time to learn the new tool. Why would they? Everything is a nail anyway. This is disappointing, especially here, because Hacker News is the place where the concept of using a non-familiar language was expressed as a super-hack for startups. My original reply expresses the conjecture that eventually, all pls will look the same and nobody will be able to develop a language that will truly provide an increase in quality, decrease development or maintenance costs, or improve the reliability and safety of systems the world runs on, because people who evaluate languages actually evaluate them for the tooling that largely gets bolted on after the fact by nonexperts (the lsp server / vscode crowd). There are three lsp servers for python. Only one of them works with pipenv on Windows. Does that make python bad? If python were introduced today, as it was when it first came out, would it gain popularity with all the expectations we place upon a language? No. And that would be a shame. The same is true of Javascript and Java. C and c++ would go nowhere. About the only language that would have made it is Csharp and Visual Basic and Kotlin, because they were written to SELL IDEs and tools.
imtringued 6y ago
Ceylon had good IDE support when it was 4 years old and nobody used it. That's just an excuse.
- coldtea 6y ago
  That doesn't prove that "it's just an excuse". It just shows that while IDE support is a factor, it's not the single determining factor. Ceylon had horrible marketing and advocacy, for starters. And the IDE was Eclipse, at a time that it was getting increasingly unpopular...
skybrian 6y ago
Another way of thinking about it is that when switch to a new language, we have to start over building nice tools for it, which seems inefficient. It's like doing a big rewrite. That's less true than it used to be. Julia wouldn't be where it is without LLVM, and things like VS Code's language server protocol do help. But there is still a lot of redoing things for people who write language tools.
j-krieger 6y ago
Most of his complaints can be solved via a Julia LSP. LSP‘s aren‘t that hard to write.
- smabie 6y ago
  There already exists a Julia LSP. It's sufficient, could be better though.

tasubotadas 6y ago

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.

enraged_camel 6y ago

>>To be fair, most of these are ide complaints, not language complaints. The language itself doesn't matter without its ecosystem. This includes tooling, libraries, quality of documentation, the community, and more.

systemvoltage 6y ago
This is why I think its mostly non-engineers commenting about how great Julia is. No one has tried to deploy it prod. Sure there might be exceptions, but if you interview 100 engineers who've tried deploying Julia, a vanishingly small % would recommend it if at all.
- jackcviers3 6y ago
  I'm not commenting on Julia per se. I'm commenting on the state of discussions surrounding programming languages in general. > if you interview 100 engineers who've tried deploying Julia, a vanishingly small % would recommend it if at all. Popularity of a choice does not correlate with a choice being correct. It is a fallacy to evaluate a particular tool's usefulness for a particular job by how popular that tool is. And doubly so when most of a random sampling of engineers includes virtually no one experienced in using said tool. In discussions of virtually any non-popular programming language today, the vast majority of commenters on the language have absolutely 0 experience using it day in and day out for its intended use case. All you have in that discussion are hammer users. To them everything is a nail. And they universally hate any new tool that doesn't look like a hammer, because they can't take the time to learn the new tool. Why would they? Everything is a nail anyway. This is disappointing, especially here, because Hacker News is the place where the concept of using a non-familiar language was expressed as a super-hack for startups. My original reply expresses the conjecture that eventually, all pls will look the same and nobody will be able to develop a language that will truly provide an increase in quality, decrease development or maintenance costs, or improve the reliability and safety of systems the world runs on, because people who evaluate languages actually evaluate them for the tooling that largely gets bolted on after the fact by nonexperts (the lsp server / vscode crowd). There are three lsp servers for python. Only one of them works with pipenv on Windows. Does that make python bad? If python were introduced today, as it was when it first came out, would it gain popularity with all the expectations we place upon a language? No. And that would be a shame. The same is true of Javascript and Java. C and c++ would go nowhere. About the only language that would have made it is Csharp and Visual Basic and Kotlin, because they were written to SELL IDEs and tools.

imtringued 6y ago

Ceylon had good IDE support when it was 4 years old and nobody used it. That's just an excuse.

coldtea 6y ago
That doesn't prove that "it's just an excuse". It just shows that while IDE support is a factor, it's not the single determining factor. Ceylon had horrible marketing and advocacy, for starters. And the IDE was Eclipse, at a time that it was getting increasingly unpopular...

skybrian 6y ago

Another way of thinking about it is that when switch to a new language, we have to start over building nice tools for it, which seems inefficient. It's like doing a big rewrite. That's less true than it used to be. Julia wouldn't be where it is without LLVM, and things like VS Code's language server protocol do help. But there is still a lot of redoing things for people who write language tools.

j-krieger 6y ago

Most of his complaints can be solved via a Julia LSP. LSP‘s aren‘t that hard to write.

smabie 6y ago
There already exists a Julia LSP. It's sufficient, could be better though.