Over the last three years I have been doing a focussed investigation of a lot of different programming languages and styles (about 38 last count). I was reflecting over the weekend which one I really liked best. Not really for features or functionality or toolset just which one felt 'right'. Julia came out on top as the one language I wanted to play with more and I wish could give a reasoned well justified argument for it but it's really just a feeling. The right mix of intelligent design, power, absence of evangelical idiocy, and a pleasing interface. So nice to get that feeling validated from the random workings of the world and see this release message this morning. Thanks Julia team.

• niccl

  today at 1:26 AM

  > Over the last three years I have been doing a focussed investigation of a lot of different programming languages and styles

  I don't know what your invesitgation covers, but a long time ago (2009) someone [0] did an interesting visual comparison of languages. sadly now it seems it's only available at archive.org [1], but I've often gone back to it, partly because it's such an elegant way of looking at some aspects of different languages.

  0: http://blog.gmarceau.qc.ca 1: https://web.archive.org/web/20100412073334/http://blog.gmarc...

• eggy

  today at 12:19 AM

  I liked Julia the first time I tried it years ago. I had some Matlab experience, so it seemed a similar, yet great improvement (no cost! more modern, but lacking some key libs or toolkits). I started programming Commodore BASIC in 1977 on my PET 2001. Then 6502 Assembler/machine language, C, Turbo Pascal, and many more. I have recently gone back to assembler because of AI. I don't miss hand coding assembler or creating macros that don't exist in FASM, but AI allows me to prompt for a terse program, using tried and true asm methods, which I can then audit. Julia has great math and scientific libraries, so my asm stuff isn't in competition with my asm efforts, but I am really enjoying the asm/AI thing for now. Granted this is for my own small projects. Coding is not my main job. I use coding in my other jobs to help me with certain tasks like scheduling, simulations, engineering, and project management. I was playing with the Julia version of cadCAD that was on Python, however, Julia has a lot of other libs that are way better to do dynamic or complexity studies than cadCAD.

• mulderc

  yesterday at 11:16 PM

  Same, Julia really does just feel right to me. Which makes sense since I mostly program in R.

• shevy-java

  yesterday at 11:24 PM

  To me it seems as if scripting languages have it hard right now, aside from Python.

  AI seems to have changed how people find and use new languages. The influx of new people kind of ... died down for many older languages here.

  • throwaway894345

    yesterday at 11:44 PM

    Even before AI the trend was moving toward increasingly static languages (JS->TS and even a lot more typed Python). Once you accept the static typing benefits, you start to wonder if you could leverage the constraints to drive performance improvements.

Due to how the release cycle turned out, most new major features got pushed to v1.14, and this one is a rather iterative release focused on making various things faster, quashing bugs, and general polish.

Still though, faster GC, lower startup latency, better interrupt handling, new REPL features, and faster package mangement are all great things. I'm especially happy that the `[sources]` section of a package is now applied recursively when you `add` a non-registered package.

• pjmlp

  yesterday at 8:40 PM

  In Java, C# and C++ land, there are equally features that take several years to finally land.

  I think it is perfectly fine that Julia folks take their time as well.

I really like Julia, but I wind up not using it as much as I might otherwise because the startup time kills it for many use cases (though of course it's easily amortized in others).

• postflopclarity

  yesterday at 9:59 PM

  I think there's a very bright future in this regard :)

  1.13 is, to-date, the release with the fastest startup times. and AOT compilation continues to be a serious priority for upcoming releases

> Faster GC by skipping image objects during marking

This one in particular I feel like we are inching towards in Python land. I had some really interesting convos from people who really want forking to "just work" and get actual memory savings, because a lot of code is really going to be in memory forever and if we can opt out of refcount work that'd be great

Current discussion, https://news.ycombinator.com/item?id=49651384