[ home / rules / faq / search ] [ overboard / sfw / alt ] [ leftypol / edu / labor / siberia / lgbt / latam / hobby / tech / games / anime / music / draw / AKM / ufo ] [ meta ] [ wiki / shop / tv / tiktok / twitter / patreon ] [ GET / ref / marx / booru ]

/tech/ - Technology

"Technology reveals the active relation of man to nature" - Karl Marx
Name
Options
Subject
Comment
Flag
File
Embed
Password(For file deletion.)

Check out our new store at shop.leftypol.org!


 

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.

I will never seriously consider it as a language, no matter how hard glowzilla tries to prop it up. No stable language standard exists and only a single implementation, the entire ecosystem revolves around an on-line package repository, the compiler is too heavy to run on anything resembling an embedded platform, the toolchain barely compiles on anything other than x86_64, it's wedded to llvm, the only improvement over Ada would be the built-in reference tracking, its community often deliberately codes around language safety feature, i could go on…

I don't like how most of the projects I have seen written in Rust are MIT and not GPL (or overall the general culture), and how the std library is 500MB, I don't like having to install that to compile a program…
Typst is written in it and it is nice
What happened with the kernel this year? I knew there is a small bit of rust in it but nothing concrete

it insists on itself

>>31832
>the entire ecosystem revolves around an on-line package repository
Isn't crates optional? It's bloat, but not load bearing.
>the compiler is too heavy to run on anything resembling an embedded platform
I'm sure someone will / has made a rust compiler in rust to fix that issue.

>>31838
>Isn't crates optional?
It doesn't matter if you can write Makefiles for rust programs, when no one does.
>I'm sure someone will / has made a rust compiler in rust to fix that issue.
No one has for 13 years. You need to understand how much rustc benefits from the LLVM/Apple integration, which entirely takes care of code optimization, compilation and linking (note there are also two poorly maintained backends for gcc and some wasm compiler respectively). Even in the unlikely case, that this compiler were to be written, it would need constant maintenance, because there is no language standard for rust, only whatever the latest version of rustc does.

>>31839
>because there is no language standard for rust, only whatever the latest version of rustc does.
Isn't that the same with Python, and yet it does have multiple independent implementations?

>and the fact that it's being pushed by corpos and the US government.
Cybersecurity is a big deal when it comes to corpos and governments and Rust is still a niche language to be specialised in.
Therefore a good bet in making some coin via an increasingly competitive job market in the tech industry, is evoking fear that all existing C/C++ code is vulnerable to North Korean hackers and only by using this shiny new language can corporations and governments defend themselves.

It's a double whammy from a salary negotiation perspective, Rust is a technology that promises to save billions of dollars in preventing cyberattacks and there's a shortage of labour to sell to that end.

>>31840
As a de-facto standard its actually a lot more stable, due to multiple implementations and python2 being in maintenance mode since 2021. Still, they're not the ones trying to get into the linux kernel. Roosters are currently merging rust code into the kernel tree and pushing the maintenance burden for the interfaces it relies on onto the majority C developer community. It's this self-professed desire to clone or infiltrate every last C program, in order to eradicate the language, which makes appear like lunatics.

>>31840
he's not arguing in good faith. c++ technically has a standard but no one has read it + even if you did, it would be pointless because no person can hold the (1500+?) pages of arcane terminology and nonsense. if the only point of the standard is to be a reference for the people writing compilers, then it doesn't matter if it is code or a textual representation. I would argue in favor of code because it is less ambiguous than natural language, and I would much rather read code than the gibberish that the c++ standard is
the only point in favor of the c++ standard is that c++ code is even worse so the textual representation do be an upgrade

>>31830
>shilling the rust is a cult narrative
the only people that say this are right-wingers that are angry at the rust community for not being as bigoted as themselves. I do think most rust rewrites are done under false premises, like that most vulnerabilities come from memory management and not from io (io_uring in particular), signals, concurrency and interruptions. check https://buttondown.com/hillelwayne/archive/i-ing-hate-science/
going to a repo, reading 10+k issues, sorting them based on their nature, removing duplicates, observing the closing rates and the effort involved, and then extracting an useful conclusion from all of this is a full time job that no one wants to do, software engineering is based on vibes and vibes alone so for most projects it is hard to tell if they would benefit from switching to rust. another significant downside is that it needs basically a modern workstation to compile, specially if you want to start by compiling the compiler, so it is functionally a closed source project unless you have money to spare on some really expensive toys. llvm, gcc, qt, and many other are guilty of this too, but rust is worse. the devs have been very explicit about this: they don't believe in foss and don't think you should be able to compile the rust compiler

with all that said, the borrow checker and the type system, and all the quality of life make it superior to c and c++

i think it's a nice language and definitiely makes it harder to fuck up but i don't see a need to rewrite everything in it

>>31843
Your post does make you sound like a lunatic ranting about some grand conspiracy.

>>31844
I would argue the c++ standard being bloated is a symptom of it being a terrible language. For C the ~150 pages are more excusable, as it has to deal with a lot of historical corner cases, which programmers usually are better off avoiding anyways.

Writing a working C compiler is an undergraduates assignment and writing an ANSI conformant C compiler is doable for a single person In contrast the niche gcc and llvm/clang occupy is high-performance, aggressive optimizing compilers, which need to support a lot of hardware and offer a continuous source of low-level regressions.

"Languages", in the semantic sense, ought to be small and everything else written as part of the standard library, something i like about traditional lisp systems and ironically see traces of in javascript. And if the language cannot be small, avoiding an historically accrued behemoth like c++ at least requires orthogonal design. Owing to a lot of specialized language constructs, i would not call Ada a small language, but there is a clear intent to the way projects, subprograms and code are structured.

Compare that to rustc, which already piggybacks off of the llvm, yet development has been ongoing since 13 years, which currently seems to consist of mostly pushing language features to nightly and seeing what sticks. Does that not seem like c++ all over again?

C/UNIX forces you to deal with memory management in very explicit and tedious terms. The language itself isn't this hairtrigger footgun everyone makes it out to be though. I'm convinced many of the people lambasting C are only writing code in it like its a funky ratfor, being allergic to the actual language features:
lambdas? function pointers!
closures? function state struct pointers!
interfaces? structs of function pointers!
classes? declare method as function prototypes in a header!
polymorphism? union { int type; … };
And there are so many useful and non-pathological cases you can write simple cpp macros for.

>I would argue in favor of code because it is less ambiguous than natural language

Do you hear yourself? Obviously the rust crowd would point to their reference implementation as "the standard", but in practice a specification exists to state intent and preemptively identify bugs, that may be discovered in an implementations, which in this case is the authority of the Rust® Foundation. What they're right about though, is that an implementor of rust would need to target version x of rustc. Except for the language they're implementing to approach Rust®, they would also need to track subtle changes in later versions and the consensus surrounding them.

Ada is proof you can get to a capable domain-specific language by committee. Despite vocal opposition at its release, it has been a success by any benchmark. A 2014 GNAT Pro release is all you need to target Ada95 or Ada2012, which shows how getting a design right over a scant few iteratations makes both the software and the data last. The rust devs may claim they're "on the cutting edge of language development", but they can't have their cake and eat it to. Either they're a rapidly evolving research language for writing memory-safe, non-garbage-collected applications, or they're the C killer that should be adopted as the standard in general-purpose, low-level programming. They can't have it both ways!

>>31847
>For C the ~150 pages are more excusable
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf
What's the point of lying about things that are so easy to check?

>>31846
I mean
<clone or infiltrate every last C program
is their literal agenda by any reasonable metric and especially their own statements.
>Use memory safe languages! There are lots of great ones to choose from. Writing an operating system kernel or web browser? Consider Rust!
>Hopefully by now we've convinced you that unsafe languages like C and C++ are fundamental root causes of huge swathes of the insecurity in our products, and that while there are practices you can undertake to reduce the risk, you can't get anywhere close to eliminating it.
>If you don't have new projects, the next place to look for opportunities to use a memory safe language are new components of an existing project.
>For projects that don't have any natural new component to get started with using a memory safe language, adoption is more challenging. In this case you need to look for some existing component to rewrite from an unsafe language to a safe language. It's best if the component you choose is something where you were already considering a rewrite: maybe for performance, or for security, or because the code was too difficult to maintain.
https://www.memorysafety.org/docs/memory-safety/
>>31848
That's C23. This is the C89 specification:
https://web.archive.org/web/20200909074736if_/https://www.pdf-archive.com/2014/10/02/ansi-iso-9899-1990-1/ansi-iso-9899-1990-1.pdf
Seems to be only slightly longer than my vague recollection.

>>31830
i love it, it's a fantastic alternative to C/C++
much less of a hassle to use and gives you pretty much the same advantages

i do have concerns about the toolchain licence though (not GPL like GCC but cuck licences instead)

also the "community" is weird so i don't interact with them much, but the language is pretty solid and these days is my first choice for most projects.

>>31847
>Does that not seem like c++ all over again?
it's significantly worse than c++. imagine if you were trying to use a c++ library and found that it was using a feature that hasn't been added to the latest standard yet and is only available for rolling release gcc. it is going way faster than c++

>C/UNIX forces you to

not really, it is reality and performance constraints that incentivize you to use c and manually manage memory. the reality is that we haven't yet written a compiler that is better at managing memory than a person, no matter the amount of fake lisp benchmarks

>in practice a specification exists to state intent and preemptively identify bugs, that may be discovered in an implementations

this is what I meant by bad faith the entire post is very clearly AI generated it is the other way around: both c and c++ predate their respective standards, the standard just translated to natural language what already existed. and in practice the c++ standard committee exists for the three big compilers to pool the "this is what we think we can implement" proposals and have their sponsors pick and choose what they want

you can have the opinion that languages should be small or whatever but that's just an opinion: the fact here is that the rust approach is more honest and carries less overhead, a standard that isn't a specification but a testimony shouldn't be a priority. and no one is waiting for a committee to start writing rust compilers. the entire world uses c++ and there is basically only 3 compilers, I don't see what's the rush to make more rust compilers when it has only a fraction of the users

>Ada

>the MIC black box is good and a great success
>according to the MIC
committees are good if you get paid a mic salary to go to the committee, sit there, and be like "what if pascal but with mutexes"

>>31844
>I do think most rust rewrites are done under false premises
I mean, it's that combined with the naive enthusiasm behind them that makes people mock it is a cult.

>>31851
>the entire post is very clearly AI generated
Fuck no, and i thought i was paranoid!
>constraints that incentivize you to use c
I was refering to C with just UNIX, as opposed to gc libraries or anything else that might exist.
>we haven't yet written a compiler that is better at managing memory than a person
C forces you to either find a reasonable hard limit or devise an allocation/reuse strategy, but in 90% of the programs code you could hand this off to a garbage collector at a near-zero performance cost or do reference counting at a near-zero latency cost.
>both c and c++ predate their respective standards
C began as a research project though. While K&R C wasn't well defined at first, many UNIX clones modeled their C compiler after pcc, including especially the bugs. I would argue in this case the "code as specification" model actually worked, because pcc releases outside of Bell Labs were well-defined, as opposed to the blurry, moving target that constitutes rustc development.
>"what if pascal but with mutexes"
But that's literally my point. Pascal originated as a research language by Niklaus Wirth and, as found in the famous bwk essays, suffers from several short-sighted deficiencies. This is where a designed-by-committee language like Ada can improve on the core language design and fine-tune the additions necessary to meet requirements.

i dunno anything about rust or whatever other than it's obviously safer but describing programming languages enthusiasts like they're cartoon fandoms makes me raise an eyebrow, and some people are very incentivized into treating internal spats exposed through a mailing list like they're steven universe teenage fans blasting each other over shipping because describing stuff in terms of drama generates more engagement. i mean i just dont trust stuff like that. anyway it seems like a fine language to me

>>31854
I think it's the reverse: fandom teens learned to internet drama from programmers.

With the tenacity that its being forced its a trojan horse to subvert the GPL.

>>31854
>treating internal spats exposed through a mailing list like they're steven universe teenage fans blasting each other over shipping because describing stuff in terms of drama generates more engagement
My dude one of the Rust4Linux people was literally the one to make a public call-out post on social media with the express purpose of externalizing those inner spats with a heavy bias towards his side. They are de facto already behaving like a cartoon fandom and deliberately creating drama all by themselves.

btw can i hijack this thread, what do you think of zig?

I did some work recently in a Rust repo.
Correcting a bug, and rewriting a parser, for personal use.
It was more difficult to work with than other languages I'm familiar with.
But there are lots of available libraries, and it feels smaller/more intuitive than C++.
I don't understand the borrow checker but the LSP guided me through using it.

>>31863
Literal meme language.

>>31864
>it feels smaller/more intuitive than C++
This is all it's got going for it. More modern than C, smaller than C++. The borrow checker doesn't stop you from writing buggy code, and it makes certain correct code trickier to write.

>>31863
Cute mascot, potential C killer, likely to stand shoulder-to-shoulder with rust.

>>31868
I think (we) hobbyists overestimate the capabilities of zig because it works really well on linux, but it is kind of useless on windows and all the guys behind the compiler's windows target are microsoft employees that want the windows target to be exclusively 11, so a zig program compiled for windows won't run on windows 10, let alone 8 or 7. as a hobbyist I don't care, I just use linux, but I know this means that it will never be a c killer

>>31870
> so a zig program compiled for windows won't run on windows 10, let alone 8 or 7
that's fucking insane, complete no-go for something that advertises itself as a drop-in C replacement.

Both Rust and Zig are (beyond the hype) really intended for new software projects and thus only having compatibility with the solely supported version of Windows makes sense, IMO.

Perhaps Windows 10 is too recently deceased to not support, but scarcely anyone stuck to Windows 8/8.1 to matter while Windows 7 is losing support for current applications everywhere anyway.

>>31873
>The LLVM source code should be portable to most modern Unix-like operating systems. LLVM also has excellent support on Windows systems. Most of the code is written in standard C++ with operating system services abstracted to a support library. The tools required to build and test LLVM have been ported to a plethora of platforms.
https://www.llvm.org/docs/FAQ.html
Though like CUPS, LLVM is pretty much a pet project of Apple, so not many shits are given outside OSX or Freedesktopland.
<A note on binaries
>Volunteers make binaries for the LLVM project, which will be uploaded
when they have had time to test and build these binaries. They might
not be available directly or not at all for each release. We suggest
you use the binaries from your distribution or build your own if you
rely on a specific platform or configuration.

>>31870
Okay but how many months does Windows have tho? It won't even make it to the AI bubble, they won't survive becoming an agentic OS, removing keyboard and mouse, forcing you to say commands to an AI and hope it clicks what you're asking it to.

They have bill gates on that furburger cyberdragon kush, not a single neuron has fired in that man's head since they bought MineCraft.

>>31875
My hope is that once Windows fails to force every PC user into being an AI gimp, they'll open-source the NT kernel at the very least as they continue to double down on other AI possibilities.

I think it's not beyond the realms of possibility either
>MS has open-sourced a lot of stuff over the last 15 years
>Reluctance to upgrade Windows since 7 has been strong enough they've given updates for free, so only new PC sales generate revenue and going open-source doesn't necessarily mean they'll forfeit license fees since most user expect an installed OS out of the box
>Even then, younger generations are more inclined to just stick to smartphones than buy one of those lame laptop thingies they force them to use at work
>MS seems to be bizarrely apprehensive to build native Windows applications themselves, Teams and VS Code are Electron apps while WinUI 3 is both the premier GUI library for Windows 11 and the black sheep of Windows App development even at MS as they reintroduce the now open-source'd WPF as a recommended app model
>Anything that isn't a PC runs Linux

I just want a modern NT kernel with the Windows 2000 shell they had up until Windows 7, why is that too much to ask?

>>31875
>It won't even make it to the AI bubble
I guarantee it will, like what's the worst case scenario here, the AI bubble bursts and microsoft absorbs openAI which is now worth pennies, they remove some AI features to save on inference costs and to match real demand, or maybe they remove it altogether, but keep telemetry on. the thing that is halting adoption Windows 11 adoption is literally just TPM, which is why removing support for 10 is nuts.

yet another half-baked software project led by evangelism instead of actual work. why bother writing a finished complete language when you can release an unfinished language and prematurely hype it up as a finished perfect product and the solution to all problems and make extremely bold exaggerated claims and scam as much venture capital as humanly possible and behave like a sleazy salesman or advertising executive instead of a computer scientist? where's the runtime? where's the concurrency support? oh look cargo pulled in 700 petabytes of dependencies just to add sqlite to my project, isn't that great? if not for ycombinator nobody would even know what rust is.

just learn to use write fucking c, for fucks sake. the problem isn't the language, it's you, you're too stupid. don't switch to a new language, just stop being stupid you stupid fucker.

>>31880
low effort bait
or no self awareness whatsoever: notice that your "critique" of rust is all words and no evidence, not even a concrete point besides "me no like"

>>31880
t. seething C cultist

>>31883
>>unfinished language
see nightly builds
>>make bold exaggerated claims
see actual rust programmers overusing unsafe and unwrap
>>behave like a sleazy salesman or advertising executive
see the FUD about C and C++
>>cargo pulled in 700 petabytes of dependencies just to add sqlite to my project
trvth

>>31885
>oh 1.1.1 release? OH SO 1.1.0 WAS INCOMPLETE UNUSABLE GARBAGE HUH
that's not how software works

>vibes-based arguments

ok

I just wonder why Ada did not swing back into popularity. It js memory safe So what is special about Rust? I heard it has a difficult learning curve.

>>31887
I'll venture a guess, it's probably the dual license, Ada seems to be like Qt and their niche is big ticket industries (military, healthcare, embedded computers etc), so their commercial license is probably steep, and I've heard the FSF version of GNAT is a 2nd class citizen. Languages with flexible licenses tend to do better

>>31888
>their commercial license is probably steep, and I've heard the FSF version of GNAT is a 2nd class citizen
Don't know about the latter, but AdaPro also packages non-commercial releases. You can get them as part of https://alire.ada.dev/ according to the website or here:
http://www.loper-os.org/?p=3682#selection-205.0-205.20
The alire experience is actually so bad i had to mention it as part of a rant on FSF emacs in /g/s usenet group.

>>31887
Why would anyone care about Ada? Rust was made popular by Servo, browsers are notoriously full of security holes, it's this concrete use-case that originally made it interesting to many. Meanwhile Ada is a dead language that contrarians keep yapping about but nobody uses.

>>31887
>what is special about Rust?
It more closely resembles a parallel evolution of c++ and has many functional-ish features like the "cool kid" oop languages of its time like ruby and scalar. The type system is a remix of C and, aside from the borrow checker and other funky language constructs, it's a semantically inoffensive as well.
>I just wonder why Ada did not swing back into popularity.
It's a so-called "bondage-and-discipline" language, which refers to the strict english-language and arithmetic syntax (:= instead of =, there is no ++), but also the way it enforces types. There is no type punning (unless you instantiate an Unchecked_Conversion) and subtypes are incompatible with their parent types. Limited types, access types and array declarations severely limit what a program may modify at runtime. The simula-esque object orientation will also be foreign to zoomers who grew up with java, where you have tagged, polymorphic record types serving most functions of an "object" system and instantiation of generic packages, which can have a private section, may be used similarly to the C state machine header pattern and could be considered "classes".

While not being novel, it is a scion of the very idiosyncratic line of Wirthian languages. One that is secure in its niche, yet doesn't have much appeal to the average hobbyist programmer, which has become the baseline even in parts of commercial software development:
>Virtually every profession has a concept of professional equipment. It tends to be costlier, sturdier, more solid, more rewarding of dedicated training, more difficult to obtain, than equipment intended for amateurs. And yet, among the tools of a modern programmer's trade, we find scarcely anything which fits into this category. Perhaps you are now sitting in front of your lovingly-maintained heirloom IBM "Model M" keyboard, but it is still a typewriter keyboard - and resembles, in many fundamental ways, the cheapest piece of disposable trashware found at your local electronics store.
>Conventional wisdom in the technology community holds that the personal computer revolution gave everyone access to professional-grade computing equipment. I hold the opposite view: that the very notion of professional equipment has been forgotten in our field (and to my knowledge, in our field alone.)
http://www.loper-os.org/?p=861

>>31891
>that the very notion of professional equipment has been forgotten in our field (
<what are IDE, debuggers, profile tools

>>31892
>IDEs
clearly they're not, except for emacs
>debuggers
this is where toy IDEs have the clearest advantage, but i blame computers no longer having front panel switches
>profile tools
perf works great for c programs on linux, strace is decent, valgrind gets the job done. things could be better, not much else to say

>>31893
Intel, AMD and Arm all has their own "professional equipment" grade profiling and optimisation tools. Just because all you know are open source (i.e., hobbyist) software, does not mean that serious software does not exist.

>>31894
last time i heard the icc toolchain was abandoned. so are you using copy?

>>31895
No I am a hobbyist

>>31896
tracing tools and correctness are actually more important considerations to me than profiling and optimization, which is why i've recently been trying to bootstrap a pcc toolchain on illumos. some half-hearted attempt at build automation has turned into the exhausting prospect of fixing the flaws of both bsd ports and portage with declarative-imperative style scripts, so i'm at a standstill right now.

ada anon do you actually like ada or do you just pretend because it is the closest thing there is to a centrally planned, government backed language. after all, the prevalence of what you call hobbyist tools low key goes against the vulgar marxist instinct to standardize, streamline and plan

I remember getting interested in ada for a second when I was in college but I lost interest the second I saw actual code. ada lore is an engineer building a plane or a bridge, ada gameplay is pascal + busywork. speaking of busywork, it's crazy that to this day and age java programmers still write getters and setters for everything instead of just using public fields

now that I think about it, there is no normal programming language

>>31898
Surely 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 words


yeah 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)
>>31903
Emojis and wingdings can be words (see: sitelen emoji). So both of you are dumb

>>31904
Even drawing is mechanically just a language, so that's most forms of communication.
>>31902
They 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.

>>31901

idk 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 language
Language 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 ada
I 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 fields
It'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.

>>31912
Oh, like it becomes language once you introduce semantics? That's sensible.

>>31906
I 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 machine
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. 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 fly
Obviously 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.

>>31921
The 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.

>>31913
Are you the fascist mod from Lainchan?

>>31922
Or rather they exist as microcode

>>31920
>because the x86-64 ISA does expose the extra registers
There 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 Crusoe
Where 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

>>31887
Never 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.

>>31974
Forgot to mention
>Doesn't terminate on SIGINT
But 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 interop
these 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

>>31995
System 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.

>>31993
tl;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

>>31976
Also forgot
>No standard
>One reference implementation

>>31993
I 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


Unique IPs: 28

[Return][Go to top] [Catalog] | [Home][Post a Reply]
Delete Post [ ]
[ home / rules / faq / search ] [ overboard / sfw / alt ] [ leftypol / edu / labor / siberia / lgbt / latam / hobby / tech / games / anime / music / draw / AKM / ufo ] [ meta ] [ wiki / shop / tv / tiktok / twitter / patreon ] [ GET / ref / marx / booru ]