What do you think about it? On its face it seems like a straightforward improvement over C/C++ and a good way to modernize development in their typical niches.
On the other hand there is this really weird cultish behavior around it that just makes me feel suspicious. "Let's rewrite everything in Rust", forcing it into existing software without a clear use case other than just "it's better", overstating the language's capabilities and robustness, very much a kind of "toxic positivity" around it as in the whole Linux Kernel shitshow earlier this year, and the fact that it's being pushed by corpos and the US government. It all feels very weird.
50 posts omitted.>>31898Surely Assembly would be the most ‘normal’ of all languages because it doesn’t contain much in the way of abstract concepts as a virtual machine.
>>31883
>notice that your "critique" of rust is all wordsyeah that's typically what sentences are made of, words. should i have written it in wingdings or something?
>>31902👉😂, 🖥️🖥️📲👨💻👨💻🤪🤪🤪🤪
>>31902 you are being deliberately obtuse about what he said (or maybe you are autistic)
>>31903Emojis and wingdings can be words (see: sitelen emoji). So both of you are dumb
>>31904Even drawing is mechanically just a language, so that's most forms of communication.
>>31902They wanted you to link to stuff to support your points so they can see where you're coming from, and to refrain from vibes based rhetoric. They were just being rude about it.
>>31901idk if assembly qualifies as an entire language because all it really is is just a bunch of mnemonics for cpu instructions, like MOV or ADD or whatever; there's no complex linguistic structure its just a lookup table.
>>31904>you are being deliberately obtuse about what he said (or maybe you are autistic)or maybe it's both, maybe i'm being obtustic
>>31905>Even drawing is mechanically just a languageLanguage is a system of differences governed by convention, not just any form of communication. Which is why we don't say that animals have language.
>>31898>do you actually like adaI like to get stuff done and ideally put in the work to have it continue working indefinitely. I mostly write C or Shell scripts, or Common Lisp when i'm not targeting UNIX specifically, but i already set aside some Ada projects i'd like to do sometime, like a rewrite of coreutils.
>write getters and setters for everything instead of just using public fieldsIt's to allow the pattern of validating inputs and not tie interface definitions to a readable value that constantly needs updating, though i agree it's overkill in 70% of cases. When i need to abstract some of this logic, in most cases i write only the setter and don't concern myself at exposing the current value at all. There is also the libc pattern of a setter returning the previous value.
>>31912Oh, like it becomes language once you introduce semantics? That's sensible.
>>31906I believe a lot of the mneomics are pseudo-instructions written in Microcode that essentially batch other more basic instructions/circuits together, so assembly does expose a virtual machine like a programming language does, but it's still "normal" in that it's describing programs as they broadly would be executed rather than as a completely theoretical machine that humans have thought up that tries to be as intuitive as possible to other humans while still being compliable into basic instructions.
IMO, it's the "intuitive as possible" is the part where languages become weird and we get the circumstance where some feel Rust's mechanisms for memory safety to be brilliant and revolutionary while others disparage them as overly restrictive to solve a skill problem. Functional languages aim to be as close to what we consider computation to be mathematically (therefore in theory, as we intuitively understand computation in general) and abstracts the underlying machine almost completely, they therefore should be incredibly popular languages and yet they're not.
>>31918>assembly does expose a virtual machine like a programming language does, but it's still "normal" in that it's describing programs as they broadly would be executed rather than as a completely theoretical machineModern x86 processors are just microcode on top of a proprietary "RISC" (in the sense of many registers, few addressing modes and heavy instruction pipelining) processor. On the other hand C in many respects still resembles a PDP-7 macro assemblers, down to int having the size of a machine word and *p++ being an actual instruction (getting even stronger when looking at B and A).
>>31919>Modern x86 processors are just microcode on top of a proprietary "RISC" (in the sense of many registers, few addressing modes and heavy instruction pipelining) processor.I have heard this, but I think it's slightly outdated because the x86-64 ISA does expose the extra registers (I believe R9 through R15) which is like twice the registers of 32-bit machines but still half that of ARM, Intel attempted taking pipelining to the extreme with NetBurst and backtracked to a slightly more narrow pipeline, while different available addressing modes may possibly all be translated to loads-then-reads rather than classic DMA.
I suspect when people refer to modern x86 CPUs as being RISC
internally, what they're describing is probably a very advanced microcode engine that somewhat matches the concept of RISC for a lot of modern instructions, rather than there being an entire bespoke RISC machine that Intel doesn't offer stand alone anywhere else with a translation layer converting all CISC instructions to RISC on the fly.
Granted, I can't be certain of that, but my guess is based on there having been CPUs that did have completely different architectures internally with an x86 translation layer (the couple that come to mind are the Transmeta Crusoe and the Elbrus series) and they worked, but were very slow, which is the opposite pitch given for why the modern x86 is actually a completely different RISC machine underneath.
>>31920>rather than there being an entire bespoke RISC machine that Intel doesn't offer stand alone anywhere else with a translation layer converting all CISC instructions to RISC on the flyObviously it's not how riscv cargo-cultists often make it out to be. Post-RISC chip design and the chip manufacturing incentives in force just don't play nice with many aspects of x86 or even an almost unrecognizable superset of the architecture, so the microcode can make use of a more advantageous hardware configuration by doing something in between a machine-code translation layer and a virtual machine, or at least this is what i took away from these comments.
>>31921The other thing I'd say as well is that the reason why x86 is still a thing is for the backwards compatibility, I wouldn't be surprised therefore if all instructions up to maybe the 486 or Pentium era are still honest-to-god CISC instructions etched onto the silicon. Because if on-the-fly translation is used even for those original instructions, then surely a choice needs to be made where either the translation/emulation is accurate and inevitably slow (I think the Pentium Pro was criticised on release for being slow with existing software, but I don't recall if that was the reason) or it's fast and inevitably just an approximation which would defeat the purpose of backwards compatibility.
But SIMD instructions and those wild ones that are named something like CMPXCHB16LOLWTF are no doubt exist within microcode which I would agree in concept is similar to RISC.
>>31913Are you the fascist mod from Lainchan?
>>31922Or rather they exist as microcode
>>31920>because the x86-64 ISA does expose the extra registersThere are more registers than that. I am pretty sure all out-of-order cores employ register renaming in some shape or form, but it's pretty hard to find anything concrete about it.
>>31920>Transmeta CrusoeWhere the fuck are the modern 5W TDP mobile chipsets? I just want a cheap af mobile SSH machine but it seems like only Apple cares about battery life.
Just started learning rust banged out a ~500LOC project in an afternoon. This shit sucks. Let me just list out the pain points so you Rustoids can't waste your time tirelessly downplaying them one by one.
>No random number generators in standard library>Massive dependency chains (hello supply chain attacks)>Painful and unergonomic C-ABI interop>The worst case of NIH ever seen >>31887Never touched Ada, but I have written a LOT of its bastard cousin VHDL. Easily the most painful language I've ever touched (hardware or software). Rust is pleasant by comparison.
>>31974Forgot to mention
>Doesn't terminate on SIGINTBut of course there's a package for that with an unjustifiably large dependency tree
>>31974>Massive dependency chains (hello supply chain attacks)>Painful and unergonomic C-ABI interopthese two don't compute. if you want c interop then you are most probably trying to link against system libraries, which implies an unknowable dependency tree. so you don't actually care about supply chain attacks
>>31995System libraries have far more eyes on them than random crates, and are more difficult to compromise because the packages go through review on any sane distro. Downloading and linking a random C library exposes you to a single point of failure that is somewhat mitigated by using a tagged older release. A real world supply chain attack on a NPM/cargo style package manager can propagate itself automatically by stealing dev's credentials looking to infect the most widely deployed packages it can. When every little thing pulls in the latest releases of a dozen convenience libraries the risks and frustrations start to add up.
>>31993tl;dr I trust system package maintainers more than random crate authors and you can't think for yourself trying to own me with linkspam written by evangelists less retarded than yourself
>>31976Also forgot
>No standard>One reference implementation >>31993I compiled typst and it pulled ~800 (!) dependencies, and they have implemented a lot of things from scratch
800 dep cli program vs 200 dep GUI program
I don't think it is comparable
This + NixOS is quite peak.
>>33136Peak glowie thielite bottom feeder.
>>31830> On the other hand there is this really weird cultish behavior around it that just makes me feel suspicious.99.999999% of this is chud projection because they saw a trans woman contribute to it once
>>33147The chvd meme about rusttranshumanists is stupid though. Every language community has a few visible trans women, except maybe old suit-and-tie languages like Fortran and Delphi. See Leah Neukirchen, Yukari Hafner, etc.
>>31832Anon, that includes most languages ever, including C/C++ at their beginning.
>>31833> and how the std library is 500MBLol where.
>>31919>>31920>>31921>>31922Last time I checked a paper on this, the instruction overhead imposed by CISC was mesured to be minimal, beween 1-2%
>>33152>rust devs using functional constructs for the most trivial taskslmao
#include <stdio.h>
#define LEN 5
int main(void) {
int data[LEN][2] = {{1, 2}, NULL, {3, 4}, {5, 6}, NULL};
int n, i;
for (n = i = 0; i != LEN; i++)
if (data[i])
n += data[i][0];
printf("The sum of the x-coordinates is %d.\n", n);
} >>33148Yes, when energy production falls less then 20% of what we have now due to climate destruction
>>33152no one would write the C++ code that way.
>>33173Whoever made this, desperately wanted to do things the "functional" way. IMO constructs like this and the corresponding additions to Java are inherently misguided, because post-hoc functional types, functions and operators never really manage to gel with an existing languages.
If you look closer at the Rust example, you will also notice, that for all of its terseness, it remains closer to Perl than any well-known "functional" language. Go Lisp or go home!
>>33173Well it is an exaggerated example but C++ has had this frankensteinish standardization process compared to C and still sucks cock to write. Strangely few people mention Ada (has SPARK the formal verification toolkit) and imo formal verification is a quite important aspect for me. C has Frama-C and stuff too for that
it's a strange coincidence that all the evangelism pushing people to use these "safer" and stricter and more high-level and structured programming languages is happening around the same time as the big push for using ai to write code instead of humans. ai is not as good at dealing with a very expressive and flexible language like c that allows the programmer to do all kinds of weird non-standard shit and get away with it, it's a lot harder to replace c programmers with llms than it is to replace rust or go or python programmers.
>>33247I hate the rust culture and the compiler but I think in this case it is a coincidence, rust evangelism has existed before 2023/2025
>>33247>it's a lot harder to replace c programmers with llms than it is to replace rust or go or python programmers.I agree with go and python, but despite the strictness, rust is basically on the level of perl when it comes to "expressiveness". Usually this comes at the cost of the programmers sanity, who will need to mind a mess of operator interactions, piece together the types assumed by the rust compiler and find semantic errors in syntactically valid code.
https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html >>33247The Rust evangelism started almost a decade before the LLM craze.
>>33247>it's a strange coincidence that all the evangelism pushing people to use these "safer" and stricter and more high-level and structured programming languagesi think these are just rust evangelists misrepresenting their language instead lmao
>>33250yeah but let's not forget that before the LLM craze was the IDE-dependent, auto-completion, auto-linting, IntelliSense, style guides, etc. craze. all of this stuff kind of has the common goal of taking all conscious human thought out of the coding process and making the human work for the machine instead of the machine work for the human. and now with AI a lot of professional "programmers" aren't even writing code at all anymore, they're just feeding prompts to chatbots to write their code for them, and essentially digging their own graves careerwise.
>>33251as theo de raadt said, it's basically standard practice in every software project now to "lead with propaganda", the whole software industry is no longer about actually building things, it's about selling things to investors, often things that haven't even been finished (or even started) being built yet.
Unique IPs: 24