Directly, I believe this has more to do with people interested in the language seeing it being used in actual projects.
Indirectly (a lot indirectly), sure. Maybe the software should perform better or maybe have fewer bugs because programming language X or Y is understood to help with those things. Maybe it showcases a more flexible architectural design, which leads to more potential features in future versions, etc.
It also hints at the mindset and values of the creator. Communities around languages value things that may or may not line up with the qualities of the language they form around, but simply the fact they value those things is reflected by rhe things they produce. If people think a language is performant, then performance will be something their community values. If it is known for having a learning curve, their product might too.
Yes, because if it's a language I'm comfortable in, if there's a bug I can hop into the code and try fix it myself. I find this happens most often for me with Flutter projects to be fair.
Yeah, it's a tool targeting developers. The language matters to a certain subset of people who don't throw their arms up and move on when they encounter a bug.
Technically no, but quite often they are easier to install and tinker with than C/C++ projects (for instance usually you just need to clone the repo and run either 'cargo build' or 'zig build', and it mostly 'just works' no matter the platform).
Some C/C++ projects which have switched to cmake are equally easy to build (well not quite: "mkdir build && cd build && cmake .. && cmake --build ."), but it's definitely not the norm.
Yes, it's a useful indicator of how portable the software is. I can ignore systems software written in Rust because it only works in places that LLVM targets, and extending LLVM is a nightmarish process. I can ignore software written in Zig because until this year (or arguably last year) it's been a one-man hobby project, worth checking on again in about a decade. For now there are too many weird bugs that pop up if you use platforms different from the main developer. "Written in Go" means I at least have a chance of fixing deployment problems, becausae crosscompiling is easy and the language is fully self-hosted.
For an editor? Makes a lot of difference. The day intellij ide is rewriten in non gc/dynamic language, there will be a noticeable improvement in performance and number of times the ide has to be restarted because it ate all the memory.
Right, except for libraries or language-specific toolchain, the only legitimate reason to mention language in the title is to suggest doubt it was possible.
Hey ncmncm, I know this is off-topic, but I just wanted to say that I really enjoyed your informative comments on high performance low-latency architectures. I was wondering, could I ask you a question via email?
- Rust is a systems-level language and requires developers to be experienced in order to create big software components. This usually leads to better quality.
- Rust rewards putting effort upfront (e.g. error handling, Option<T>, ...) leading to less bugs than more forgiving languages.
- Rust uses zero-cost abstractions which enables efficient code. In other languages it's a lot easier to degrade your performance by accident.
- Rust can easily create binaries for the most relevant architectures, so your programs tend to be portable.
- The contribution story is great, your code tends to be correct and you don't need to watch out for many foot guns. I've done it myself for Helix and the experience was awesome [1].
But take everything with a grain of salt, you can create bad software in every programming language.
We don’t provide the ‘easy to program for’ console that (developers) want, because
‘easy to program for’ means that anybody will be able to take advantage of pretty
much what the hardware can do, so then the question is, what do you do for the
rest of the nine-and-a-half years?
