4 ms·

The question is what do we mean by "a fast language"? We could mean it to be how fast the fastest code that a performance expert in that language, with no resou

by pron 10mo ago

The question is what do we mean by "a fast language"? We could mean it to be how fast the fastest code that a performance expert in that language, with no resource constraints, could write. Or, we can restrict it to "idiomatic" code. Or we can say that a fast language is the one where an average programmer is most likely to produce fast code with a given budget (in which case probably none of the languages mentioned here are among the fastest).

justin66 10mo ago
These are the languages an "average programmer" would use. What language are you thinking of?
- pron 10mo ago
  I may be biased, but I think that if you have a budget that's reasonable in the industry for some project size and includes not only the initial development but also maintenance and evolution over the software's lifetime, especially when it's not small (say over 200KLOC), and you want to choose the language that would give you the fastest outcome, you will not get a faster program than if you chose Java. To get a faster program in any language, if possible, would require a significantly higher budget (especially for the maintenance and evolution).
  - cdelsolar 10mo ago
    Go?
    - pron 10mo ago
      I don't think so, but it may not be far behind. More importantly, though, I'm fairly confident it won't be Assembly, or C, or C++, or Rust, or Zig, but also not Python, or TS/JS. The candidates would most likely include Java, C#, and Go.
  - xnorswap 10mo ago
    Do you think C# / .NET doesn't stack up in terms of budget, or not stack up in terms of runtime speed?
    - pron 10mo ago
      It's probably in the same ballpark. To me, the contenders for "the fastest language" include Java, C#, and Go and not many more.
      - justin66 10mo ago
        Ah thanks. That clarifies things.
- swiftcoder 10mo ago
  Purely by the numbers, an "average programmer" is much more likely to use Javascript, Python, or Java. The native languages have been a bit of a niche field since the late 90's (i.e. heavily slanted towards OS, embedded, and gamedev folks)
DoctorOW 10mo ago
> we can say that a fast language is the one where an average programmer is most likely to produce fast code with a given budget I'd say most people use this definition, with the caveat that there's no official "average programmer", and everyone has different standards.
- pron 10mo ago
  Right, but if we assume that programmers' compensation is statistically correlated with their skill, then we can drop "average" and just talk about budget.
  - Avicebron 10mo ago
    That seems like a wild assumption to make.
    - gf000 10mo ago
      Statistically? I don't think it's that wild. If you prefer it, salaries correlate with years of experience, and the latter surely correlates with skills, right? (No, this doesn't mean that every 10 years XP dev is better than a 3 years XP one, but it's definitely a strong correlation)
jillesvangurp 10mo ago
It's compilers and compiler optimizations that make code run fast. The real question is if the Rust language and the richer memory semantics it has help the Rust compiler to provide a bit more context for optimizing that the C compiler wouldn't have do unless you hand optimize your code. If you do hand optimize your code, all bets are off. With both languages. But I think the notion that the Rust compiler has more context for optimizing than the C compiler is maybe not as controversial as the notion that language X is better/faster than language Y. Ultimately, producing fast/optimal code in C kind of is the whole point of C. And there aren't really any hacks you can do in C that you can't do in Rust, or vice versa. So, it would be hard to make the case that Rust is slower than C or the other way around. However, there have been a few rewrites of popular unix tools in Rust that benchmark a bit faster than their C equivalents. Could those be optimized in C. Probably; but they just haven't. But there is a case there of arguing that maybe Rust code is a bit easier to make fast than C code.
- gf000 10mo ago
  > It's compilers and compiler optimizations that make code run fast Well, then in many cases we are talking about LLVM vs LLVM. > Ultimately, producing fast/optimal code in C kind of is the whole point of C Mostly a nitpick, but I'm not convinced that's true. The performance queen has been traditionally C++. In C projects it's not rare to see very suboptimal design choices mandated by the language's very low expressivity (e.g. no multi-threading, sticking to an easier data structure, etc).
  - jillesvangurp 10mo ago
    The compiler backend yes. But there probably is a lot of work happening elsewhere in the compiler tools.
  - adgjlsfhk1 10mo ago
    Compilers are only as good as the semantics you give them. C and C++ both have some pretty bad semantics in many places that heavily encourage inefficient coding patterns.
- 10mo ago
torginus 10mo ago
I think when designing a language, and a set of libraries for it, the designer has an idea of how code for said language should be written, what 'idiomatic' code looks like. In that context, the designer can reason about how should code written that way should perform. So I think this is a meaningful question for a langauge designer, which makes it a meaningful question for the users as well, when phrased like this: 'How does idiomatic code (as imagined by the language creators) perform in language X vs Y?'
deleted 10mo ago
[deleted]
deleted 10mo ago
[deleted]

by pron 10mo ago

justin66 10mo ago

These are the languages an "average programmer" would use. What language are you thinking of?

pron 10mo ago
I may be biased, but I think that if you have a budget that's reasonable in the industry for some project size and includes not only the initial development but also maintenance and evolution over the software's lifetime, especially when it's not small (say over 200KLOC), and you want to choose the language that would give you the fastest outcome, you will not get a faster program than if you chose Java. To get a faster program in any language, if possible, would require a significantly higher budget (especially for the maintenance and evolution).
- cdelsolar 10mo ago
  Go?
  - pron 10mo ago
    I don't think so, but it may not be far behind. More importantly, though, I'm fairly confident it won't be Assembly, or C, or C++, or Rust, or Zig, but also not Python, or TS/JS. The candidates would most likely include Java, C#, and Go.
- xnorswap 10mo ago
  Do you think C# / .NET doesn't stack up in terms of budget, or not stack up in terms of runtime speed?
  - pron 10mo ago
    It's probably in the same ballpark. To me, the contenders for "the fastest language" include Java, C#, and Go and not many more.
    - justin66 10mo ago
      Ah thanks. That clarifies things.
swiftcoder 10mo ago
Purely by the numbers, an "average programmer" is much more likely to use Javascript, Python, or Java. The native languages have been a bit of a niche field since the late 90's (i.e. heavily slanted towards OS, embedded, and gamedev folks)

DoctorOW 10mo ago

> we can say that a fast language is the one where an average programmer is most likely to produce fast code with a given budget I'd say most people use this definition, with the caveat that there's no official "average programmer", and everyone has different standards.

pron 10mo ago
Right, but if we assume that programmers' compensation is statistically correlated with their skill, then we can drop "average" and just talk about budget.
- Avicebron 10mo ago
  That seems like a wild assumption to make.
  - gf000 10mo ago
    Statistically? I don't think it's that wild. If you prefer it, salaries correlate with years of experience, and the latter surely correlates with skills, right? (No, this doesn't mean that every 10 years XP dev is better than a 3 years XP one, but it's definitely a strong correlation)

jillesvangurp 10mo ago

It's compilers and compiler optimizations that make code run fast. The real question is if the Rust language and the richer memory semantics it has help the Rust compiler to provide a bit more context for optimizing that the C compiler wouldn't have do unless you hand optimize your code. If you do hand optimize your code, all bets are off. With both languages. But I think the notion that the Rust compiler has more context for optimizing than the C compiler is maybe not as controversial as the notion that language X is better/faster than language Y. Ultimately, producing fast/optimal code in C kind of is the whole point of C. And there aren't really any hacks you can do in C that you can't do in Rust, or vice versa. So, it would be hard to make the case that Rust is slower than C or the other way around. However, there have been a few rewrites of popular unix tools in Rust that benchmark a bit faster than their C equivalents. Could those be optimized in C. Probably; but they just haven't. But there is a case there of arguing that maybe Rust code is a bit easier to make fast than C code.

gf000 10mo ago
> It's compilers and compiler optimizations that make code run fast Well, then in many cases we are talking about LLVM vs LLVM. > Ultimately, producing fast/optimal code in C kind of is the whole point of C Mostly a nitpick, but I'm not convinced that's true. The performance queen has been traditionally C++. In C projects it's not rare to see very suboptimal design choices mandated by the language's very low expressivity (e.g. no multi-threading, sticking to an easier data structure, etc).
- jillesvangurp 10mo ago
  The compiler backend yes. But there probably is a lot of work happening elsewhere in the compiler tools.
- adgjlsfhk1 10mo ago
  Compilers are only as good as the semantics you give them. C and C++ both have some pretty bad semantics in many places that heavily encourage inefficient coding patterns.
10mo ago

torginus 10mo ago

I think when designing a language, and a set of libraries for it, the designer has an idea of how code for said language should be written, what 'idiomatic' code looks like. In that context, the designer can reason about how should code written that way should perform. So I think this is a meaningful question for a langauge designer, which makes it a meaningful question for the users as well, when phrased like this: 'How does idiomatic code (as imagined by the language creators) perform in language X vs Y?'

deleted 10mo ago

[deleted]

deleted 10mo ago

[deleted]