3 ms·

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 reflect

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.

mulderc 18d ago
Same, Julia really does just feel right to me. Which makes sense since I mostly program in R.
shevy-java 18d ago
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 18d ago
  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.
  - jgalt212 18d ago
    RL works better / easier to implement with static typed languages.
    - eigenspace 18d ago
      That's way too broad of a statement. Static typing makes it easier to do RL targeting the sorts of things that static types encode, but it doesn't help at all with things that aren't really type constrained, like for instance writing accurate numerical programs.
    - deleted 18d ago
      [deleted]
- huijzer 18d ago
  Agreed. AI doesn’t level the playing field but turns it more in a winner takes all situation. AI is currently best in Python programming from what I hear and this is because it has seen the most Python code.
  - ModernMech 18d ago
    No matter how much code it has “seen” during training, it still makes mistakes during inference. Therefore AI is most well-suited to write in languages with feedback loops that catch mistakes earlier. Moreover, no matter how good it is at writing Python, Python is not a language you want to use everywhere. “The right tool for the job” still applies in the age of ai.
    - huijzer 17d ago
      Good point. I had great success with Rust indeed, which can catch errors early.
eggy 18d ago
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.
niccl 18d ago
> 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 http://blog.gmarceau.qc.ca 1: https://web.archive.org/web/20100412073334/http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html https://web.archive.org/web/20100412073334/http://blog.gmarc...
- vasvir 18d ago
  Cool. Thanks for sharing this.
- Tarrosion 18d ago
  Similar visualization from the Chapel Lang team here, which shows Julia (and Chapel) in the ideal small-but-fast corner: https://chapel-lang.org//img/clbg/clbg_summary-zoomed-out.jpg https://chapel-lang.org//img/clbg/clbg_summary-zoomed-out.jp...
  - ModernMech 18d ago
    Found a presentation related to that chart, contains more context: https://chapel-lang.org/chapelcon/2024/chamberlain-clbg.pdf https://chapel-lang.org/chapelcon/2024/chamberlain-clbg.pdf
- jaen 18d ago
  Previous discussion of this on HN (2009): https://news.ycombinator.com/item?id=634692 https://news.ycombinator.com/item?id=634692
jhoechtl 18d ago
As you mentioned 38 languages, chances are high that these languages are not all coming from a scientific background, where 1 index based adressing of items is the norm. What is your take in respect to Julia, which is also one offset based?
- adrian_b 18d ago
  One-index based addressing of items was the norm in most of the mathematics or physics books written before WWII, but even then there were exceptions, e.g. for the components of a quadri-vector or a quadri-tensor, i.e. for spatio-temporal vectors and tensors, it was already common to use the indices 0, 1, 2 and 3 for the temporal component and for the 3 spatial components, instead of the indices 1, 2, 3 and 4. However, this tradition is worth nothing, because before automatic computers the use of decimal numbers instead of binary numbers was also the norm, like also the use of big-endian numbers instead of little-endian numbers. Having to actually implement the computational operations in hardware has revealed that many such traditions were sub-optimal. Despite the fact that among my programming interests the scientific-technical computational problems have always been on the top and I have started programming with the Fortran language, I have always recognized that using 1-index based array addressing is inferior and any programming language that uses this convention makes a mistake, because this increases the chances of programmer off-by-one errors, by requiring more complex index expressions in many cases. If anything, my opinion is that programming languages should not support any of such obsolete "norms", but they should go further in replacing them. For instance, I believe that for integer constants and printed numbers it is still OK to use decimal numbers, because this simplifies mental computations for most humans, who have memorized the multiplication table of decimal numbers and because the conversions between decimal and binary integer numbers are exact, so it does not matter which base is used to display them to humans. On the other hand, I believe that for floating-point constants and printed numbers it is a mistake to use decimal numbers, instead of using hexadecimal numbers for the significand and decimal numbers only for the exponent (like when printed by printf with the %A or %a conversion specifiers). The reason is that the conversion between floating-point decimal and binary numbers is slow and inexact, introducing rounding errors, without providing any advantage for a human who reads the program text or a table with results. Comparing hexadecimal floating-point numbers is actually faster and easier for a human reader, than when working with decimal numbers, because the numbers are shorter. Except for comparison, a human will not do any other exact mental computations when reading a set of floating-point values. (At most, when looking at a column of numbers displayed as fixed-point values, a human might add one or a few of the digits, to check that their sum matches the corresponding digits in a displayed total value, but unlike multiplication, addition is almost as simple for hexadecimal numbers as it is for decimal numbers.) Approximate mental computations are also easier to do with binary floating-point numbers than with decimal floating-point numbers, if you understand how to do them (which is by using logarithms in any mental computations; this is true for both binary and decimal floating-point numbers, because approximate conversions between numbers and their logarithms are very easy to do mentally, as any engineer working with decibels knows). Doing just the simple operations with exponents provides already a better accuracy than for decimal numbers, because an octave is smaller than a decade. For additional accuracy, it is usually enough in mental computations to approximate the floating-point values to 3 points per octave, in which case the approximation error is about the same as when doing approximate mental computations using decibels. In decades of programming, I have never encountered any case when I would have wanted for my program to contain decimal floating-point constants, or for any result to be printed as a decimal floating-point value, but I have encountered the opposite case, when a programming language annoyed me because it forced the use of decimal floating-point constants, which introduced undesirable rounding errors, so I had to use equivalent integer constants and use something like memcpy to convert them into the desired floating-point numbers.

mulderc 18d ago

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

shevy-java 18d ago

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 18d ago
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.
- jgalt212 18d ago
  RL works better / easier to implement with static typed languages.
  - eigenspace 18d ago
    That's way too broad of a statement. Static typing makes it easier to do RL targeting the sorts of things that static types encode, but it doesn't help at all with things that aren't really type constrained, like for instance writing accurate numerical programs.
  - deleted 18d ago
    [deleted]
huijzer 18d ago
Agreed. AI doesn’t level the playing field but turns it more in a winner takes all situation. AI is currently best in Python programming from what I hear and this is because it has seen the most Python code.
- ModernMech 18d ago
  No matter how much code it has “seen” during training, it still makes mistakes during inference. Therefore AI is most well-suited to write in languages with feedback loops that catch mistakes earlier. Moreover, no matter how good it is at writing Python, Python is not a language you want to use everywhere. “The right tool for the job” still applies in the age of ai.
  - huijzer 17d ago
    Good point. I had great success with Rust indeed, which can catch errors early.

eggy 18d ago

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.

niccl 18d ago

> 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 http://blog.gmarceau.qc.ca 1: https://web.archive.org/web/20100412073334/http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html https://web.archive.org/web/20100412073334/http://blog.gmarc...

vasvir 18d ago
Cool. Thanks for sharing this.
Tarrosion 18d ago
Similar visualization from the Chapel Lang team here, which shows Julia (and Chapel) in the ideal small-but-fast corner: https://chapel-lang.org//img/clbg/clbg_summary-zoomed-out.jpg https://chapel-lang.org//img/clbg/clbg_summary-zoomed-out.jp...
- ModernMech 18d ago
  Found a presentation related to that chart, contains more context: https://chapel-lang.org/chapelcon/2024/chamberlain-clbg.pdf https://chapel-lang.org/chapelcon/2024/chamberlain-clbg.pdf
jaen 18d ago
Previous discussion of this on HN (2009): https://news.ycombinator.com/item?id=634692 https://news.ycombinator.com/item?id=634692

jhoechtl 18d ago

As you mentioned 38 languages, chances are high that these languages are not all coming from a scientific background, where 1 index based adressing of items is the norm. What is your take in respect to Julia, which is also one offset based?

adrian_b 18d ago
One-index based addressing of items was the norm in most of the mathematics or physics books written before WWII, but even then there were exceptions, e.g. for the components of a quadri-vector or a quadri-tensor, i.e. for spatio-temporal vectors and tensors, it was already common to use the indices 0, 1, 2 and 3 for the temporal component and for the 3 spatial components, instead of the indices 1, 2, 3 and 4. However, this tradition is worth nothing, because before automatic computers the use of decimal numbers instead of binary numbers was also the norm, like also the use of big-endian numbers instead of little-endian numbers. Having to actually implement the computational operations in hardware has revealed that many such traditions were sub-optimal. Despite the fact that among my programming interests the scientific-technical computational problems have always been on the top and I have started programming with the Fortran language, I have always recognized that using 1-index based array addressing is inferior and any programming language that uses this convention makes a mistake, because this increases the chances of programmer off-by-one errors, by requiring more complex index expressions in many cases. If anything, my opinion is that programming languages should not support any of such obsolete "norms", but they should go further in replacing them. For instance, I believe that for integer constants and printed numbers it is still OK to use decimal numbers, because this simplifies mental computations for most humans, who have memorized the multiplication table of decimal numbers and because the conversions between decimal and binary integer numbers are exact, so it does not matter which base is used to display them to humans. On the other hand, I believe that for floating-point constants and printed numbers it is a mistake to use decimal numbers, instead of using hexadecimal numbers for the significand and decimal numbers only for the exponent (like when printed by printf with the %A or %a conversion specifiers). The reason is that the conversion between floating-point decimal and binary numbers is slow and inexact, introducing rounding errors, without providing any advantage for a human who reads the program text or a table with results. Comparing hexadecimal floating-point numbers is actually faster and easier for a human reader, than when working with decimal numbers, because the numbers are shorter. Except for comparison, a human will not do any other exact mental computations when reading a set of floating-point values. (At most, when looking at a column of numbers displayed as fixed-point values, a human might add one or a few of the digits, to check that their sum matches the corresponding digits in a displayed total value, but unlike multiplication, addition is almost as simple for hexadecimal numbers as it is for decimal numbers.) Approximate mental computations are also easier to do with binary floating-point numbers than with decimal floating-point numbers, if you understand how to do them (which is by using logarithms in any mental computations; this is true for both binary and decimal floating-point numbers, because approximate conversions between numbers and their logarithms are very easy to do mentally, as any engineer working with decibels knows). Doing just the simple operations with exponents provides already a better accuracy than for decimal numbers, because an octave is smaller than a decade. For additional accuracy, it is usually enough in mental computations to approximate the floating-point values to 3 points per octave, in which case the approximation error is about the same as when doing approximate mental computations using decibels. In decades of programming, I have never encountered any case when I would have wanted for my program to contain decimal floating-point constants, or for any result to be printed as a decimal floating-point value, but I have encountered the opposite case, when a programming language annoyed me because it forced the use of decimal floating-point constants, which introduced undesirable rounding errors, so I had to use equivalent integer constants and use something like memcpy to convert them into the desired floating-point numbers.