[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


Janitor applications are now being accepted. Click here to apply.


[Advertise on 4chan]


File: Rust-vs-C-.png (42 KB, 1000x526)
42 KB
42 KB PNG
Let's settle this once and for all.
>>
Rust
>>
>>106652593
The one on the right can be used to write an operating system.
The one on the left identifies as a language that can be used to write an operating system.
>>
>>106652593
No one cares. Stop making these threads, it's tired
>>
>>106652627
cniles hate the exposure
rustroons hate the reality
which are you? boomer or suicidooder
>>
>>106652593
there is no vs. it's and/or.
settled.
>>
>>106652593
>https://www.phoronix.com/news/Git-Weighs-Mandatory-Rust
:3
>>
>>106652593
why isn't C on the left? even alphabetically C is before R
>>
>>106652620
https://www.redox-os.org/
>>
it should be Rust vs C++
>>
>>106652926
>uses less than 512mb of ram
kinda neat
inb4 someone posts a stripped down linux with some shitty tiling wm using 300ish
>>
>>106652593
Israel
>>
>>106652933
c++ failed in replacing c
its a very functional language but at the end of the day it isnt used for anything giga-critical and never managed to fix the issues it percieved in C
>uh it was never meant to--
c++ was originally called "c with classes"
>>
>>106652926
>toy unix clone that runs on a vm only
yep
>>
File: many-laptops-opt.jpg (323 KB, 2016x845)
323 KB
323 KB JPG
>>106652974
cope
>>
>>106652978
how do we know it's real?
>>
>>106652760
Because the left is nigger garbage.
>>
File: redoxos.png (1.12 MB, 2618x688)
1.12 MB
1.12 MB PNG
>>106652926
>small attack of surface saar!!
>>
File: 17637129873137189.png (653 KB, 1066x1068)
653 KB
653 KB PNG
>>106652593
Rust has borrow checking, actual type system and compiler-enforced error handling, a working stdlib, generics, static and runtime dispatch support, AST-based macros, stackless coroutines, async and await. It repels jeets and attracts autistic compsci trannies that write gpu drivers.

C has null pointers. It attracts jeets and freshmen college students.
>>
File: 1758446479904.png (168 KB, 1896x873)
168 KB
168 KB PNG
>>106652593
behold
>>
>>106653308
why don't jeets like rust?
>>
>>106653472
aren't you the guy who cried about linkedin stealing your pic?
>>
>>106653308
sex with GPT5
>>
File: 1758447766481.png (236 KB, 1308x1194)
236 KB
236 KB PNG
>>106653532
i took my meds and realized i don't care
>>
File: 1758448179169.jpg (341 KB, 1080x1842)
341 KB
341 KB JPG
>>106653532
7 months later and people still reposting it without my programming language in the picture
>>
>>106653472
You forgot conveniently to compile without the `--release` flag you hypocrite piece of shit cnile scum.
>>
>>106653640
you forgot to dillate today tranny
>>
>>106653592
holy rude
>>
File: 1715683763550574.png (448 KB, 1648x1010)
448 KB
448 KB PNG
>>106653644
>>
File: rustkek.png (317 KB, 960x640)
317 KB
317 KB PNG
>>106653652
>>
>>106652944
uh oh
>>
>>106653648
welcome to linkedin. people who post on linkedin are grifters. I really hate how they took facebook's playbook instead of just being the professional connections website like they used to be.
>>
>>106653751
dude fuck your wisnia lang i'd crop it off too
>>
>>106653753
I'm not him. I'm just sour that my professional network website is a bunch of shitskins spewing incomprehensible garbage and I can't even turn it off.
>>
>>106653652
whats the point of having both byte and char?
>>
I've liked and used both, but the cultists are the worst.
>>
>lets settle this once and for all
>over 9000 other flamewar threads about Rust and C pop up after this one
and that's not even the right logo for C, I think you meant C++.
>>
>>106653481
They hate functional programming
>>
I have a question for you /g/. I am writing a specialized compiler targeting embedded devices primarily. Should I write it in C89, C99, or Rust?
Thanks.
>>
>>106653799
char is not guaranteed to be unsigned. one usually expects byte to be unsigned though. in this specific case though.. I think it makes no difference?
>>
ANSI C
>>
>>106652593
I would pick C because it allows me to have greater control over the code I write. Also Rust only allows a subset of safe programs to be expressed before you have to start using escape valves which either come with a performance hit (smart pointers) or come with just as many gotchas as writing C++ (unsafe). I also dislike how poor Rust is for exploratory work. It feels like everything has to be production quality from the get go which is annoying as hell when I just want to write something shitty to see if it produces something like the desired result (which could be unsafe and leak a bunch of memory) before making it better. Rust is just not my cup of tea.
>>
>>106653843
Rust is a shitty functional language so jeets would be just fine with it. You can be as imperative as you like with Rust.
>>
>>106652593
Trannies vs. Chads.
>>
>>106654121
By design, Rust isn't really good as a toylang. It's too strict and focused on code correctness.
>>
File: 1646943173803.gif (898 KB, 487x560)
898 KB
898 KB GIF
>>106654074
This is retard code >>106653652.

It should all be done in #define, since sizeof() is all known at compile-time.
Even if they would not have known about the preprocessor:
Those should be done with switch and case.
And 'byte' is not a standard C unit type.
And signed or unsigned makes no diference regarding sizeof() anyhow.
>>
I genuinely do not understand the point of these posts. Why are you fuckers just lazing around and incite arguments about nothing? Post software you've developed, what is the point of arguing whether a hammer or knife is better?
>>
>>106653882
Rust and it isn't even a debate. Pattern matching and native ASTs will make it bearable. As someone who wrote compilers for both, C is actual dogshit for anything that isn't using it as assembly syntactic sugar.
>>
>>106654372
>t. never been a 20yo 3rd worlder with no future
>>
File: rust.png (114 KB, 627x722)
114 KB
114 KB PNG
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
https://bpb-us-e1.wpmucdn.com/sites.gatech.edu/dist/a/2878/files/2022/10/OSSI-Final-Report-3.pdf
https://archive.ph/uLiWX
https://archive.ph/rESxe
https://lkml.org/lkml/2025/2/6/1292
https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12464988
https://lwn.net/Articles/1030517/
https://github.com/lcnr/solver-woes/issues
>>
>>106654409
>As someone who wrote compilers for both
doubt
>>
>>106653882
Why not use something like Scala? Pattern matching, tagged unions, garbage collection.
>>
>>106654522
>garbage collection
scala can garbage collect itself
>>
>>106654528
What kind of performance do you need in that specific compiler?
tsc, the Typescript compiler, is being ported to Go and not Rust, and Go uses garbage collection.
>>
>>106653843
Whats stopping them from just learning functional programming, is it too much effort right now for non-existent rust jobs?
>>
>>106653308
>>106653481
>>106653843
>>106654131
>>106654665
This doesn't make sense, Indians are contributing to Google's Fuchsia in-development operating system:
https://fuchsia.googlesource.com/fuchsia/+/c051e1616c18b568bffeef1cbffec0a9e44d4cf9
>>
>>106654623
>the Typescript compiler, is being ported to Go and not Rust
They chose Go because it has a similar programming style to their existing Javascript codebase
>>
>>106654409
>>106654522
Thanks for the suggestions.
>>106654623
That wasn't me.
I'll give some information to clarify. I have some domain specific optimizations that I want to realize as a compiler. Essentially I am synthesizing particular logic circuits. The compiler will be developed in three stage. 1. Emitting C89 or C99, 2. Emitting Verilog/VHDL, 3. Emitting bytecode for certain targets.
Performance is a requirement as I will be possibly working with billions of nodes and optimizing over them. It would also be extremely handy to have easy access to CPU specific information. For example does this particular ARM Cortex M chip have SIMD capabilities?
>>
>>106654709
And garbage collection was obviously fine for them.
For another compiler project, Zig was preferred over Rust, and their compiler in Rust is being rewritten in Zig if I interpret their writings correctly.
https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a3992532f#why-zig-over-rust

You can also consider the lack of success of Bevy, outside of Tiny Glade, that used a part of Bevy.
>>
>>106654757
>Performance is a requirement as I will be possibly working with billions of nodes and optimizing over them.
Are the algorithms set in stone, or are they still being designed? How well versed are you in algorithms, data structures and time complexity, at a university education level? Is it purely about implementation of tried and tested algorithms?
Do you know the complexities of the relevant algorithms?
>>
>>106654757
Like, do you have a lot of experience and university education in these topics?

https://en.wikipedia.org/wiki/Asymptotic_computational_complexity

https://en.wikipedia.org/wiki/NP-completeness
>>
>>106654853
let the man cook
>>
>>106654883
Just trying to ensure that he isn't accidentally falling into a pit. It's probably fine, I am just double-checking. Since if he ends up trying to apply an algorithm that takes Theta(2^n) asymptotic average time on an input of size n = 1e9, well, uh.
>>
>>106654828
>>106654853
>>106654883
More or less, I will soon have a PhD in mathematics :^). The optimizations I have in mind are all easy O(n). In a sense the data structures are already optimized to run on hardware.
I have optimization on three levels. The interface (structure of the logic circuits) is optimized to run on a diverse set of hardware, be it ASIC, FPGA, CPU, GPU, etc. Then some simple logic optimization such as pruning, normalization, these are the O(n) ones. Finally I have some optimizations on the instruction level for certain targets.
>>
>>106654757
>It would also be extremely handy to have easy access to CPU specific information. For example does this particular ARM Cortex M chip have SIMD capabilities?
I am not sure that I understand this part. Are you running the compiler on the targets that the compiled programs will also run on? Otherwise, while I could be wrong and naive about it, I would guess that such information probably would be independent of programming language, except for libraries, popularity and ecosystems.
>>
>>106654702
oh look, another /g/eet living vicariously through some american boy(s).
hell, even the jeet etymology of the word "suraj" is made up. it's actually of arabic origin, and it should have been "seraj" because it's:
سِراج
not
سُراج
but whatever arabic text the first jeet read probably didn't have the distinguishing diacritics.
and no, "suraj" is not derived from "surya" lmao.
i'm not sure how i ended up explaining how jeets make up shit, even about words in their own language, but here we are.
>>
>>106654977
Isn't it against the rules to announce sage?
>>
>>106654965
Good observation. This has to be a cross-compiler because I am targeting embedded devices. I am ignorant about this part, surely there must be a somewhat standard way to deal with this issue? In this respect I am gravitating towards C, because the embedded ecosystem is centered around it(?)
>>
>>106654977
Do you live in the United Arab Emirates or something?
>>
>>106655015
no. i happen to not be living in a british construct, be it the UAE, or jeetland, or the other two constructs in that subcontinent for that matter.
>>
>>106654757
>2. Emitting Verilog/VHDL,
I know too little about Verilog/VHDL, but aren't these languages to describe hardware? Or, is that transpiling target/output meant for FPGAs or something like it?
>>
>>106655094
>Or, is that transpiling target/output meant for FPGAs or something like it?
Yes, exactly. Honestly this seems like the easy part. I am NOT goint to compete with hardware manufacturers synthesis tools. This is just icing on the cake.
I think the really hard part about will be emitting good bytecode for embedded CPUs.
>>
>>106654757
I am not sure that I understand. Will some of the output code, like the C code and the bytecode, be relatively very small, and the output code for the FPGAs be large, for the sake of exploiting parallelism on FPGAs? Or something?

What is the nature of your programs? Why do they need to run on diverse hardware? Is there going to be lots and lots of compilation? Is the nature of the problem such that it cannot run on GPUs?

I mean, couldn't you just run the compiler Scala on a PC with 64GB RAM and call it a day? Is the compiler going to be run by software developers, or in a more programmatic mode, a bit like a JIT?
>>
>>106655230
>compiler Scala
compiler written in Scala
>>
>>106654757
I really don't understand why you would be worried about performance of a specialized compiler when the time complexity is O(n) and the compiler is cross-compiling.
>>
>>106655067
Are you truly so stupid and incompetent that you only just now noticed that you had "sage" in the Name field?
>>
>>106655067
The USA was a British construct that later gained independence in revolutionary war. India is an independent state, so is the UAE. Nationalism is how self-determination was won from international domination, it is the same solution to international zionism. Which is also a British construct.
>>
>>106655230
>>106655263
> I am not sure that I understand. Will some of the output code, like the C code and the bytecode, be relatively very small, and the output code for the FPGAs be large, for the sake of exploiting parallelism on FPGAs? Or something?
Yes exactly.
> What is the nature of your programs? Why do they need to run on diverse hardware? Is there going to be lots and lots of compilation? Is the nature of the problem such that it cannot run on GPUs?
To enable use in constrained environments, energy efficiency, and low latency. But yes for some applications GPU will be perfectly good.
> I mean, couldn't you just run the compiler Scala on a PC with 64GB RAM and call it a day? Is the compiler going to be run by software developers, or in a more programmatic mode, a bit like a JIT?
I agree! It will be run by software developers. I have no bone to pick against Scala, in fact I would be interested to hear more why you recommend it. I just want the project to be future proof. So I am thinking the language of choice needs to be decently fast, select for good programmers (if the project grows). It also seems reasonable to program the compiler in a language that embedded developers are familiar with.
>>
>>106654783
>literally who project
>>
>>106654783
If I was doing this as a hobby project I would use Zig, but I need industrial standards.
>>
>>106654853
This is like second year topics on any good CS bechlor's degree.
>>
>>106652593
look, i dislike rust and the trannies that promote it as much as anyone here, but C is a toy language not suitable for serious projects, and nobody below the age of 50 would use it.
>>
>>106655422
Yes, but not everyone has a university degree. Those specific topics can make a huge difference, and people without a degree rarely know them well, since these specific subjects are arguably much more easily learned well in depth in a university setting than a programmer-on-the-job setting. Thus, I tried to figure out what background he had, since without the right prerequisites, well, he might have ended up with stuff like this, or worse
https://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html

As far as I know, this is a fundamental problem in Swift that has been there for years, and still makes the most recent version of the Swift compiler fail:

let a: Double = -(1 + 2) + -(3 + 4) + -(5)


Not that everyone need to know all these subjects, but at least have some people around that do know that stuff when designing a programming language.
>>
>>106654757
>Performance is a requirement as I will be possibly working with billions of nodes and optimizing over them.
>>106655337

I don't understand why performance would be a requirement in the (cross-)compiler. It seems as if the performance of the final output is what matters, not really the compilation time of the compiler itself. If the algorithms are O(n), an input size of a billion for a compiler doesn't seem all that bad.

It sounds as if you anticipate that embedded developers might be involved in maintaining the compiler. You would have to guess, estimate and prioritize how important this goal is. Though, if one can fulfill that goal or requirement for cheap or free, sure.

Is this potentially commercial? Since you need industrial standards?

How complex are the algorithms and the compiler overall? How complex would the compiler be? How large would the codebase be? Might it grow a lot over months and years?

Generating C code, and generating Verilog/VHDL, I am guessing would be relatively maintainable and scalable. But bytecode? What kind of bytecode? Would there be multiple types, or many? Would it need to scale?

You mentioned SIMD. That can only be for the compiled output, not the compiler itself. There are different approaches to that. Are you familiar with https://github.com/google/wuffs ? I do not have a lot of experience with what you are more specifically working with, but I would ask around on different forums, Discord servers, etc., both for programming languages and embedded.

Are you familiar with LLVM? Have you considered generating IR for LLVM, and let it handle some of the output targets and optimization? Or is that not applicable here?

You are not giving me all the information, which might be fine, there could be many legitimate reasons for that, especially on 4chan.
>>
>>106652926
Isn't this toyos basically abandonware? I'm pretty sure those guys are spending most of their time developing PopOS and Cosmic DE.
>>
>>106655416
Define 'industrial standards'.
>>
>>106655671
> I don't understand why performance would be a requirement in the (cross-)compiler. It seems as if the performance of the final output is what matters, not really the compilation time of the compiler itself. If the algorithms are O(n), an input size of a billion for a compiler doesn't seem all that bad.
Fair enough, I am probably overestimating the workload.
> It sounds as if you anticipate that embedded developers might be involved in maintaining the compiler. You would have to guess, estimate and prioritize how important this goal is. Though, if one can fulfill that goal or requirement for cheap or free, sure.
> Is this potentially commercial? Since you need industrial standards?
Yes the goal is to make this into a business. I obviously can't go into to details but I am applying for patents. I am thinking about licensing it as source available for this reason. But perhaps this is stupid.
> Generating C code, and generating Verilog/VHDL, I am guessing would be relatively maintainable and scalable. But bytecode? What kind of bytecode? Would there be multiple types, or many? Would it need to scale?
Scalability is a big concern for sure. But even generating highly efficient C code would require the use of SIMD intrinsics. For now I am mostly looking at ARM Cortex M chips as a target.
> You mentioned SIMD. That can only be for the compiled output, not the compiler itself. There are different approaches to that. Are you familiar with https://github.com/google/wuffs ? I do not have a lot of experience with what you are more specifically working with, but I would ask around on different forums, Discord servers, etc., both for programming languages and embedded.
I am not familiar, but I am decently proficient with SIMD in general. For me the portability is the main question mark.

(1/2)
>>
File: 1727981618985199.webm (2.91 MB, 662x500)
2.91 MB
2.91 MB WEBM
>>106652593
>>
>>106655671
> Are you familiar with LLVM? Have you considered generating IR for LLVM, and let it handle some of the output targets and optimization? Or is that not applicable here?
This is certaintly interesting, but I am not compiling a general purpose programming language.
> You are not giving me all the information, which might be fine, there could be many legitimate reasons for that, especially on 4chan.
Yeah, I wish I could go further into details. I highly appreciate the feedback/discussion though.

>>106655717
Robust enough to be depended on in 10+ years.
>>
>>106654757
>>106655671

As for languages, C can be annoying in terms of data structures. C++ and Rust might be options if you really insist on making it more accessible for embedded developers.

The more complex the compiler, and the less development resources and the less specialized compiler developers there are to develop and maintain the project, the better it would be to get good support in the programming language for handling the complexity in the compiler. C and C++ would not be good in such a situation, as mentioned before C is annoying at something as basic as data structures, and C++ does not have pattern matching, tagged unions or garbage collection. Rust has pattern matching and tagged unions, but has lifetimes and borrow checker, which is annoying, can limit compiler design and architecture options, and might be superfluous for a compiler. Rust unsafe is bad, but I don't believe it would really be needed in a compiler, at least if performance is not required, so that ought not to be an issue. My gut instinct would be to select a maintainable programming language with decent speed, and if performance in the compiler is really needed, then rewrite it later. A garbage collected language, with pattern matching and tagged unions, and preferably not difficult to pick up, would be best here. Scala is too complex and not used by enough people. I don't think I can recommend it, in this scenario, at least if this has to be a longlived, industrial project. On some Scala forums, they are worried about size of the ecosystem, and there was the whole Scala 2 to Scala 3 thing. C# and Java are dipping their toes with pattern matching and tagged unions AFAIK, but otherwise might be decent, they are not complex programming languages compared to Rust, Scala or C++.

If the compiler would be simple, you could also go for Go. Though Go doesn't interop all that easily with other languages AFAIK.
>>
>>106655741
>Yes the goal is to make this into a business. I obviously can't go into to details but I am applying for patents. I am thinking about licensing it as source available for this reason. But perhaps this is stupid.
I would prefer to be cautious with giving you business advice on this topic, in case my advice turns out to be very bad and causes problems for you later. I do not have sufficient experience with that topic, and it is also a topic where the debate tend to be warped and somewhat removed from reality, different actors, different interests, all that jazz. But I am guessing that you are already well aware of all that.
>>
>>106655287
>jeet cope
lmao
>>
>>106652978
Most VM software can also go fullscreen btw!
>>
>>106654977
You gotta admit, with the way Semitic languages are constructed and employed, it's very, very easy for phonetic drift to occur. As a non-Native speaker who barely even knows the language I can come up with a ridiculous number of ways to read سراج
>>
>>106655741
Looking at Wuffs might be one source of inspiration, they do have something with SIMD in their generated C code. I know far too little about that subject. If you are willing to consider other output languages than C, maybe C++ or Rust, or some less mainstream language, could be considered. C++26 has something like a SIMD library, though some are critical of it. Rust has some automatic SIMD, but it might not be reliable, like some have reported their Rust programs, unchanged, no longer getting SIMD optimizations after upgrading rustc version to compile with, probably after rustc changed heuristics for what to optimize (like if rustc takes long to compile, not doing automatic SIMD suitability analysis stuff in some cases can make it compile faster). And I don't know if Rust is even suitable for transpiling. But then again, C is probably by far the most portable, avoiding C++ and Rust might be best regarding as an output target.

Have you investigated what competitors or companies with similar products are doing?
>>
>>106655287
>>106655839
Monologue?
>>
The only thing C is for is for its unspecified ABI. Otherwise it doesn't even have generics so it's useless for real world code.
>>
>>106652593
JavaScript > Rust > C
>>
>>106652593
Rust is like if you took C++ and decided you wanted something slightly different but just as gay and retarded.
>>
>>106655781
Thanks for the lengthy comment, you gave me a lot of food for thought. Honestly, the compiler itself will be very simple. The complexity mainly stems from handling different compilation targets. Personally I would choose C, but eventually I need to get more people on board.

>>106655820
Well I have been living in academia wonderland for many years. I am just now getting into the messy reality that is business. But on the bright side now I have the possibility of making a product that can improve the world.

>>106655900
For portability reasons I must choose C as a target, I am even cautious about emitting C99 as opposed to C89. IF my "approach" (sorry for the vagueness) becomes popular enough, then it will probably make sense to compile to LLVM IR.
>>
>>106655946
It's relatively easy to make a partial compiler for C, so C is popular in some types of embedded development, if there are no backends in more complex multi-language compiler toolchains for the given architectures.

C is also more limited, so developing a formally verified OS in it (or as a compiler target) might be easier than some other languages.
>>
>>106655919
jeet @ >>106655287 probably wrote that seriously. hard to imagine, isn't it?
>>106655866
yeah. i was just making extra fun of jeets. i would imagine sometimes drift can simply be introduced via indirect hearing via a non-native speaker, or full on etymological evolutions.
i'm sure there are all kinds of drift with e.g. words going from:
arabic -> persian [-> $some_other_language]



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.