Hacker News new | ask | show | jobs
by stdbrouw 1135 days ago
The flip side to this is that Julia is a great general purpose engineering calculator and simulator. For example, calculating friction in hvac ductwork, voltage drop in long electrical circuits, solar gains for windows or solar panels facing various directions, cost/benefit analyses of thicker or thinner roof insulation and so on... these are all 1 to 10 lines of code so there isn't a big porting cost in moving to Julia and in exchange you get a fast, ergonomic and sane language with universal support for physical units [1] and unicode variable names [2] so things are much less verbose than they would be in, say, Python.

In the past I used Calca [3] for these kinds of things, and there are many of these "fancy calculator apps" around, but it's just so much nicer to work in a real programming language.

[1] https://painterqubits.github.io/Unitful.jl/stable/

[2] https://docs.julialang.org/en/v1/manual/unicode-input/

[3] http://calca.io/

1 comments

Yea but the language itself, and it's ecosystem is broken on a regular basis. Again fine if you're an academic, not so great for industry.
How?
What do you mean how? Something in base changes, the author of a package didn't put strict enough compatibility on their package and now you can't use the package. It's especially great when this sort of thing happens after spending ten minutes waiting for precompilation an hour for your time to first gradient and three days for a run to complete and you trusted the tool to let you write the results to a CSV using the CSV package(one of the most widely used packages). Then you file a bug report and get gas lit, so you just patch your local Julia version and compile it yourself so you don't wait 4 months for an upstream fix. Good times.
Counter anecdote, I had to go back to a quite complex project that a was developed in 1.5, 3 years ago, hundreds of dependencies.

Upgrading to 1.9 RC2 required changing a single dep (Light raps to the drop-in Graphs) and a single line (a library changed the return from a String to a StringView)

You're incredibly lucky. Even minor version bumps have left me up shit creek in production with deadlines.
Julia core is backwards compatible all the way to 1.0, libs not so much.

Now, something as fundamental as numpy dropped support for Python<3.6 in a minor release: https://numpy.org/devdocs/release/1.19.0-notes.html

And I've been bitten by relevant python libs breaking stuff even in patch releases.

It happens and it's far from particular to Julia. I just make sure to test stuff property before going to production.

Why do you update a programming language version in production with deadlines in the first place?
Can you be more specific? As is, it's hard to follow what the issue was that you encountered.
At this point the only thing I can say is. Have you ever been a Julia user? Or are you actively developing Julia? If you are actively developing Julia, yea sure pull down the feature branch after someone's reported a bug, hot fix your toml to point too some specific version after reading ten diffs to be sure you have the right one, maybe stand up your own package server or pay 50k for one from julia computing, recompile Julia itself and everything is totally fine! If it's not no big deal just stomp over the type with your own code, yay. Maybe that's even part of your job. If you're a user expecting to do development and receive updates on packages or language, all I'll say is best of luck.
I run in production several Julia projects and I honestly can't say I know what you are referring to.

I do use some libraries through PyCall. This is a relatively frequent source of trouble, with libraries breaking because of 3rd party dependencies, behaviour changing, or even somehow installation suddenly stops working. This all happens in the python side, to the point that I am currently replacing all the libraries even if it means porting some of them or even a loss of functionality.

We run Julia code in production. These are compute-heavy services called by other parts of the app. Version upgrades are normally easy. Upgrade, run the unit tests, build the Docker images and deploy to K8s. Maybe we've been lucky, but since 1.3 we've never had big issues with version upgrades.