What does it mean for a language to be multi-paradigm?

When you label your language as a "multi-paradigm" language in an effort to appeal for a mass majority. you end up with a jack of all trades master of none type of situation. how can a language be object oriented AND functional AND procedural? make it make sense!!! you're not getting actual objects, or if you are, then you're not getting proper functional since OO does not mesh with it. so which one is it? it has to be one or the other, it can't be all three. that's just a messy soup you made. in reality you end with a language that is neither functional nor OO. just a mess... multi-paradigm languages are a red flag.

Language paradigms seem to be nonsense to me. It's marketing terminology. People get the marketing terminology confused with actual features & organizational strategies.

language "paradigms" are but pidgeonholing. There are no paradigms but the ones we project onto the language we are using. Limiting oneself to think in terms of "paradigms" limits our thinking about what is possible with computers, even with the languages themselves. They serve as an abstraction, but the real "paradigm" is the runtime model of the language itself and not just a convenient shorthand to express some capabilities of the language. The best languages are such that they trascend "paradigms" and allow one to write their code using techniques from any of these and more. My own programming can hardly be said to belong to any one paradigm, there is often an actor model and a "language-oriented" (as in Racket) flavour to it. I am starting to work on a project that has an object model and a logic-oriented behaviour on top of that. Thinking in terms of paradigms makes mental midgets.

Object orientation defines a "real object" in a very general, simple way, just like how functional programming really just means writing programs utilizing expression/function reduction instead of structured statements. Objects are simply an abstraction form that utilizes encapsulation and message passing, and functions are expression abstractions that rely on free and bound variables tied to units of work. A paradigm is just a defined best practice that the programming language wants you to do. As such, a multi-paradigm language just means the language designers condone multiple programming approaches for use in their language. As an example: In Scheme, you can define an object by creating a function with internal state that you then can pass messages to in order to get work done. Inheritance is then implemented by an object having a fallback object (or objects) that it passes messages to if it doesn't handle what it received. That satisfies all requirements for objects in object oriented design right there. If you are curious where classes or interfaces are, they are superfluous to object; they only exist as an attempt to declare object contracts have them fit better into static type systems. They are not core to the definition of objects themselves. Vice versa, you can implement a functional system in an object oriented paradigm in so many different ways. The main root of functional programming is lambda calculus, and any language can represent such a thing so long as functions are referable (ideally first-class). That said, without tail-call optimization theres little work you can do much without overflowing your call stack. But that reinforces the point of language designers declaring a paradigm: It just means that the language designers do not condone using their language outside of certain approaches. So multi-paradigm languages are just languages where it is designed to facilitate many different programming styles, sometimes primarily, sometimes secondarily. So I would not say that paradigms are useless, marketing, or that they conflict. They declare to users of the language the approaches to programming the designers condone for use in their programming language. For another example, Common Lisp is primarily functional, but CLOS (Common Lisp Object System) is a fully defined and effective object system that allows a ton of features that other OOP languages like Java or C# do not support. Meanwhile Java has class-based object orientation, but created a limited functional system through their Stream interface and FunctionalInterface annotation that declares a class as being representable as an inline function declaration. Also just to define it, even though its pretty unimportant, procedural just generally means "structured programming where functions/procedures are the base executable unit of work". Most OOP languages are procedural in some way, although in pure OOP (like Smalltalk) objects are the base unit of work. Additionally if you recall, functional is expression oriented instead of structural, which differentiates it from procedural as well.

>>42847 not op but the distinction seem all minor to me. A class in oop is just a container for data+function pointers. And performance considerations lead to things like using visitor pattern bringing you back to functional design even if you use classes. The whole "multi-paradigm" thing is imo just admitting the academics neatly defined software design ideas aren't practical so we are breaking them.

>>42861 The neat definitions provided by many academics are very simple to explicitly allow the mixing of them as the need suits the problem. The only people who believe in the purity of a programming style are people who care less about programming and more about a game of ideological righteousness. Just see the average Rust argument about morality, or a C programmers aghast behavior when someone rightfully criticizes C's messy syntax or ambiguous keywords. So I wouldn't say the prevalent usage of multi-paradigm languages "admits" anything, it is just proof of what most people already know: Different abstract programmatic concepts are more ergonomic for different tasks, and so a language that supports more than one style is more useful than one that only supports one. Also, I wouldn't say that objects are "just" data+function pointer containers. There's in fact no need for either of those as an object can be represented as a singular function, as I mentioned previously. The point being: The way one computer or one runtime implements the concept of objects is irrelevant to the discussion of object oriented programming, and serves nothing but to be reductive or dismissive for the sake of avoiding abstract thought. One should not tie their entire concept of programming to the singular computational environment they use, regardless of how similar it may be to other computational environments in the modern day.

>>42862 my understanding is objects are instances of the same thing holding different data. So function+data is a necessity to classify it as a object as without different data you just have one single static function.

>>42863 In terms of objects generally: There isn't really a requirement that they be "instances of the same thing", that is a claim that is made in class-based object orientation. In the general, abstract sense of OO, two objects could be entirely disjoint or isomorphic and yet respond to the same messages. Additionally two objects could start with the same basic state, but diverge to the point that they don't even handle the same message anymore. In terms of data: You're correct in the sense that data has to be encapsulated by the object, but not in that data must be stored near or alongside the message handler in memory, which is how I interpreted the last statement since function pointers were specified. The following example assumes that by "function+data", like "data+function pointers", you are making a claim that the data and function share a certain level of memory locality. If you're not making that claim and instead just specifying that object data must be encapsulated somehow, then bear with me. Objects follow two rules: They encapsulate data, and they process messages that are passed to them. There is no requirement that the object actually holds the data alongside the message handler(s), or even that the object can only ever handle certain kinds of messages. So as an example, you can implement a very simple object system by relying on lexical binding for data access, and functions for message processing. Remaining true to using only a single function to represent the object: scheme (define (make-accumulator starting-value) (letrec ((accumulator 0) (self (lambda (message . arguments) (case message ((collect) accumulator) ((add) (set! accumulator (+ accumulator(car arguments)))) ((increment) (set! accumulator (1+ accumulator))) (else (error "Message not implemented: " message)))))) self)) (define accumulator (make-accumulator 0)) A more extensible, but still basic, approach to objects following this model: scheme (define (make-object slots message-handler) (letrec ((self (lambda (message . arguments) (message-handler self slots message arguments)))) self)) (define accumulator (make-object '((accumulator . 0)) (lambda (self slots message arguments) (case message ((collect) (cdr (assq 'accumulator slots))) ((add) (let* ((a-pair (assq 'accumulator slots)) (a (cdr a-pair))) (set-cdr! a-pair (+ a (car arguments))) a)) ((increment) (let* ((a-pair (assq 'accumulator slots)) (a (cdr a-pair))) (set-cdr! a-pair (1+ a)) a)) (else (error "Message not implemented: " message)))))) Here we define an object, "accumulator", that stores a simple integer value and responds to messages to collect, add to, or increment that integer. The returning value of "add" and "increment" is the last value of the accumulator, while "collect" simply returns the accumulator in the current state. The newly created object can then be used as follows: scheme 1 ]=> (accumulator 'collect) ;Value: 0 1 ]=> (accumulator 'increment) ;Value: 0 1 ]=> (accumulator 'collect) ;Value: 1 1 ]=> (accumulator 'add 2) ;Value: 1 1 ]=> (accumulator 'collect) ;Value: 3 1 ]=> (accumulator 'force-set! 4) ;Message not implemented: force-set! ;To continue, call RESTART with an option number: ; (RESTART 1) => Return to read-eval-print level 1. A couple clarifications on this example: Firstly, the data in this case is not stored, in memory, alongside the object function. It is accessible purely through lexical binding. Secondly, the use of lexical binding to encapsulate data is only one of multiple ways to do this. One could store it alongside message handlers (or the object function) in memory in a simple C structure as you've mentioned. Additionally, someone could have a global table of object data state that is referenced via each created object, given their own ID. All of these accomplish the same goal of encapsulation, but through different means. One may be able to infer from this example that if you wanted to inherit from an object, you can simple encapsulate it as part of a sub-objects slots. This, in fact, is much more flexible than class-based OO: It allows multiple-inheritance, dynamic overriding, and many other features implicitly. It has downsides of course, most notably the idea that "inheritance bad" if you largely rely on class-based OO systems, but it is extremely expressive all the same. In fact, with the knowledge that there is no requirement for memory locality, only data encapsulation, a singular object could easily span multiple computers in a distributed system. In this conceptual example the object itself would have to query for it's data across a boundary before working on it, and sending it back, and finally responding to the message it was passed. Probably not the best use of time, or the best way to implement objects, but it does satisfy the idea of object orientation.

>>42864 just to clarify a function pointer is just another data field storing the address to a function not the function itself. And if you have complex objects then the data fields can be pointers too. So the object instance becomes merely a collection of pointers that sums up to "use this data with that function" with nothing held in the object instance itself. Btw the most free way to code would be to modify execution code at runtime treating it as data but that got removed for security. Malware still uses that approach to hide what it does by building itself as snippets from existing safe programs but as a normal programmer you cant express stuff like "i want a copy of this function but replace line X with this new code" so you are forced to introduce control variables and conditions as a consequence of the limitation of being unable to threat code as data you can modify on the fly.

>dis and dat lang is jack of all trades cus it supports more than 1 thing garbage ass cumskin boomoid take. litryl y programmin is sht full of complete retarded fagg0ts liek op

>>42867 Runtime meta-programming, either via direct machine code rewriting, or more general approaches such as reflection or homoiconicity are both plenty common. How do you think runtime code generators like JITs work? So I don't really follow what you mean by "removed for security", even the most unsafe form (direct adjustment of code at the machine level) is possible by just marking a memory region as executable and r/w, which plenty of runtimes allow to accommodate things like JIT compilers. If you think that is the free-est form of programming than I sincerely implore you to do it, and enjoy it. If people call you "immoral" or "dangerous" than take it as a compliment. As a side note, the concepts of control variables and conditions are just extensions of both formal logic and the way computers were designed. A condition exists at the machine code level after all, usually as a branch conditional upon a registers value relative to zero. A better target to blame for more modern restrictive approaches to programming is structured programming, and the belief that through strict control statements and avoidance of flexible control flows programs can be made provable (Dijkstra). In my personal view, the free-est form of programming is that rooted outside of the modern computer entirely. The lambda calculus as a computational model outshines the Turing machine inspired machines we have created in the modern day, and allows computation to be easily represented in a way that can be both computed by machine, and by man. Relying on a computing machine in order to, well, compute, is severely limiting in my view. One should be able to truly read and process programs in such a way that their mind can interpret it alongside any machine.

>>42869 my malware example already was a mention to admit its possible, my point was you dont get easy access to it. JIT does runtime code modification but writing java you don't have access to modify java code like its data. You dont get to write your code as "use func X with Y modification". Instead you have to manually introduce control structures / refactor into fragments if you want to have multiple versions of a function with some parts working different. >what you mean by "removed for security" Ive heard from lecturers that separation between code and data was introduced for security and they explicitly wanted to design languages so you can't modify the code, only data was supposed to be changing for safety. And that naturally lead to the present design of instead of modifying the function you insert function parameters to flip between multiple versions of the same function with a control structure.

>>42871 Ah, yeah I see what you mean now in terms of "removed for security", meaning in language semantics. While true, there's still plenty of languages that open up the possibility for direct control, although they usually try to ensure you maintain their calling conventions at a minimum (C comes to mind, but there's others as well). Generally the push to separate code and data came almost entirely out of the structured programming camp, as I mentioned previously, and it was both for security but also provability. People like Dijkstra detested the use of "goto" for example, and other flexible control flows, because it allowed the creation of programs that were impossible to formally prove. He still didn't win, people just invented new ways to develop unprovable programs in structured languages, but that digression can be for another day. However I would like to add that, in high-level languages like Java (and Lisp, for that matter), direct machine code manipulation is argued against because it actively unhinges core tenants of the languages themselves. That's why they tend to add their own meta-programming utilities, with differing degrees of success. Java's Reflection library is among the best in statically typed programming languages, and of course any Lisp is not complete without full homoiconicity and "data is code". Both of these allow some pretty wild opportunities for dynamic control flow changes and, in a way, code rewriting. They just tend to be somewhat safer than raw machine code manipulation, and more importantly: They cannot break the fundamental language runtime. A Scheme runtime for example has beautiful, full blown support for control flow as an object that can be bound to a name and used as desired, called Continuations. Everything in a Lisp is data and code both; it's your programs job to separate what goes where, and your imagination to see how it can be done. But I stand by the most important tenant of programming: Have fun. If you want to rewrite machine code at runtime in order to accomplish a goal, use a language that supports the use-case. Hell, if you want to tie yourself to the computer so strictly, look into designing your own language that acts as a simple frontend for LLVM IR, or QBE IR. There are a ton of options that open up the ability to play with the guts of the machine you're running on.

>>42841 >how can a language be object oriented AND functional AND procedural? make it make sense!!! very simple: two of those terms (OOP, functional) don't mean anything, objectively speaking. any language that supports procedures, structured data, closures and polymorphism readily accommodates "OOP" as well as "functional programming" >multi-paradigm languages are a red flag. a paradigm-oriented programmer is a red flag. competent people don't think in terms of paradigms, they think in terms of higher level concepts: what sorts of polymorphism does this language support? what sorts of dispatch methods? are functions first-class values? are messages first-class values? etc.

>>42869 >The lambda calculus as a computational model outshines the Turing machine inspired machines we have created in the modern day, and allows computation to be easily represented in a way that can be both computed by machine, and by man. Relying on a computing machine in order to, well, compute, is severely limiting in my view. One should be able to truly read and process programs in such a way that their mind can interpret it alongside any machine. i'm gonna find you and i'm gonna force you, at gunpoint, to "interpret alongside the machine" a pure lambda calculus program doing whatever trivial thing, while i interpret an equivalent C program in my brain. if you get the output wrong and i get the output right, i pull the trigger until it goes *click*

>>42877 If you truly think C is a fundamental computational model, get off this board. Otherwise, learn how to read. A better argument would be that you would have to read modern amd64 machine code, not even assembler, in which I wish you luck as you juggle literal thousands of instructions in your head. Even working with your false pretenses, I would take lambda calculus anyday, as I actually do work through LC programs, by hand, on paper, as an exercise and for learning. As for working through your C program on paper, I wish you luck as you didn't specify: The compiler, specification version, operating environment, or CPU architecture. As a result, you cannot even guarantee the length of an "int", or how the program starts, let alone what happens when encountering implementation defined behavior, which is common. Working under that many assumptions when evaluating purely mentally sounds absolutely dreadful.

>>42880 >If you truly think C is a fundamental computational model, get off this board. >fundamental why this arbitrary goalpost? what makes a computational model "fundamental"? hard mode: without subjective handwaving > you didn't specify: The compiler, specification version, operating environment, or CPU architecture. As a result, you cannot even guarantee the length of an "int", or how the program starts, let alone what happens when encountering implementation defined behavior, which is common and nonetheless i can predict the output of a C program by doing it in my head much better than you can predict the output of lambda calculus. funny that. build a machine that actually implements the underlying model and i could follow along with it while you struggle. you really did not think this through

>>42880 Lambda Calculus & Turing Machines ("Algol or C" like) are fundamentally the same thing. Lambda Calculus just emphasizes variables & data having names&symbols, while Turing Machines emphasizes variables & data existing at a memory address & offsets to memory addresses.

>>42892 >Lambda Calculus just emphasizes variables & data having names&symbols sure, if by "data" you mean unbound symbols and lambdas. what LC actually emphasizes is having no useful primitives like... you know, numbers? that CS undergrad is likely confusing LC as in "stripped-down Haskell" with LC as the actual "fundamental" model of computation and i would love to see him alpha-convert and beta-reduce this modest program into a result. maybe i'd even allow him use his notebook: https://pastebin.com/raw/cQAcpE2w

Lambda Calculus is great as a linguistic abstraction, and in fact, it got adopted in logic, theoretical linguistics and programming language theory. They use it for variables/substitutions in natural languages or in logic expressions, or as abstraction to reason about expressions in programming languages and their type systems, type inference, etc. As a model of computation lambda calculus itself is less immediate than Turing Machines. You need to build evaluator like SECD machine to get it down to earth. Turing Machine on the other hand is more immediate because it's already evaluator itself, slightly abstract but still. But Turing Machine is completely useless in linguistics/logic/plt/etc.

>>42895 I couldn't agree more with this assessment. They both have distinct strengths: Turing machines are the perfect candidate for the practical, engineering of computing machines; Lambda Calculus being very useful throughout the abstract side of computing and it's intersections into linguistics and logic. Overall it's a pretty beautiful foundation for computer science. A part of me does wish things like the SECD machine weren't needed to "ground" things like LC, but I understand it's pretty well necessary. Computers have shrunk the timescales for formal sciences so heavily that something like Lambda Calculus isn't really considered serviceable in the modern day without it, same way mathematicians aren't pondering over evaluating and tweaking formulas for long stretches of time anymore.

>>42895 whats your fav functional language? are you into upper level semantic languages ?

>>42907 > whats your fav functional language? In terms of just language alone, I like anything Haskell+, stuff like Agda, with more extensible syntax, etc. They're all quite impractical or aren't even intended for software dev, many of those are more of constructive theorem proving systems. I dislike programming by hand altogether though, I very much prefer backsitting Copilot. And in this context, my favorite is Rust - because it's native, efficient, its trait system makes its libraries and APIs very flexible/powerful but also safe, and even though ownership/borrowing is pain do deal with when coding by hand, it's not an issue at all when Copilot does it for me.

>>42908 >copilot way to ruin a thread.

>>42908 >I dislike programming > I very much prefer backsitting Copilot >my favorite is Rust a picture is emerging

>>42915 Would you prefer me to do desktop apps with Electron? I mean, imagine if you needed to use that app too eventually. Anything else, I wouldn't bother.

>>42916 I don't mean to gatekeep but you're very unlikely to find like-minded people in lainchan of all places.

>>42916 i have no preference regarding your tool use. but if i had to use Rust, i bet i would start to dislike programming as well. maybe the converse is also true. i guess all i'm saying is that your post triggers all of my confirmation biases (isn't that what the kids call pattern recognition these days?)

>>42917 All imageboards are psyops to groom schizos. I'm proud to ruin the groomer's meta. All that trad CS soykaf used for this purpose historically is obsolete and belongs to the museum.

>>42919 just learn a real programming language and actually learn to program. the only people using Rust are actual glowies and woke corpos

>>42920 > woke Retard. FP community (especially Haskell) were using Rust before the memeterm "woke" was invented. > actual glowies Which, if it was true, if you think about it for 1 second, would be a good reason to consider that maybe there's something worthy about it.

>>42921 i said: 1. learn a real programming 2. learn to program instead of generating artificial indian slop

>>42922 1. you are retard 2. you are retard

>>42923 name some good Rust software. you simply can't. zero worthwhile software has been originally written in Rust despite it being stable for a decade

>>42924 i really dislike rust, but ruffle

>>42925 ok. so what are you seething about?

>>42924 >>42925 Also ripgrep, alacritty.

>>42924 > name some good Rust software https://graphite.rs/

>>42932 >generic clone that no one asked for #481821 let's face it: it's impossible to innovate with Rust

>>42933 This is the first 2d graphic program centered around node-based procedural workflow. There are texture synthesis systems like Substance Designer or Material Maker, those mostly work with transformations of noises and masks, here you actually draw on raster/vector layers and apply procedural transformations to those high level image/geometry objects. It's a bit like Blender's geonodes or Houdini but for 2d art. Nothing similar exists.

>>42934 >its like blender >nothing similar exists mkay >2d graphic program centered around node-based procedural workflow modern game engines all have node system and support 2d rendering. Godot is even free.

>>42934 ok, so it's doing a bunch of stuff that has been done before, but in a slightly new context. i guess i stand corrected on all counts. there's one piece of software that's (maybe?) not soykaf and it's doing something (slightly?) new. making good and innovative software with Rust is potentially possible, albeit exceedingly rare

>>42935 All different systems used for different purposes: > node-based editors for shaders like Blender's shader nodes, Unity's NodeGraph and the one in Godot > node-based texture synthesis systems like Substance Designer and Material Maker > node-based procedural 3d geometry systems like Blender's geonodes and similar in Houdini > node-based procedural 2d geometry systems like this one in Graphite - it's actually the first one of its kind, before that the closest to it were the ones described in previous category, but those are for 3d

>>42937 And they also have very different scope and capabilities, for example, you can generate some basic Perlin or Voronoi noise in any of those, but you never have usable edge detect and floodfills in shader node systems, you only have that in full-featured texture synthesis systems like SD and MM.

>>42937 >"invents" doing what 3D modeling software has been doing for years but limited to 2D >one of its heckin' kind i'm gonna clone Graphite in COBOL but with another dimension removed and make a truly one-of-its-kind 1D pixel strip editing software >>42938 >you can generate some basic Perlin or Voronoi noise in any of those, but you never have usable edge detect and floodfills in shader node https://docs.blender.org/manual/en/latest/compositing/types/filter/filter.html

>>42937 2d is just a subset of 3d. Add a rectangle and you doing 2d in blender but i don't see the value in restricting yourself either. Its often way more efficient to do 3d with forced perspective than to manually do the same in 2d. >>42938 >never usable edge detect Whats that supposed to mean? Edge detection is trivial for meshes, you can even do fancier soykaf like edge sharpness which is just the angle between the faces There is even proximity detection between different meshes to do stuff like boat affecting water / buildings affecting snow mesh

>>42939 > https://docs.blender.org/manual/en/latest/compositing/types/filter/filter.html Have you ever run Blender in your life? This is compositor nodes (separate postprocessing node-based system). And this exactly what I'm talking about: there are good reasons why all those nodes available in compositor are not available in shader nodes. Anyway, compositor nodes are yet another special kind to add to that list, being basically a node-based GIMP/Photoshop effects, it's all postprocessing only. >>42940 > Whats that supposed to mean? You don't have edge detect, flood fills, pattern scatters, directional warps/blurs/etc as a primitives usable for texture synthesis in node-based shader systems. Stuff like this and all the next nodes after it: https://rodzill4.github.io/material-maker/doc/node_filter_fill.html An example from SD: https://www.youtube.com/shorts/WVYVb_dsLGw

>>42941 >all those nodes available in compositor ok, concession accepted. so what magical nodes does 3D modeling software lack, that can only be implemented in a crippled 2D system? what's your next cope?

>>42941 your example is trivial in blender you just add an array modifier to a rectangle to create a tiled mesh and then apply noise by array id in shader

>>arguing about programming languages kek, go outside

>>42943 That's a nice workaround, but it doesn't work in general case. If you want for example to create a texture of stone fence consisting of multiple types of stones (each with different texture), you might want to start with Voronoi for stones, and then floodfill them to apply different textures per stone type. How would you do that to Voronoi? (This picture is just demonstration, in practice ofc there would be directional warps, it would also be fill to random color mask instead of gradient, etc) The general principle here is that shaders are only allowed to know about the pixel they colorize, and all this stuff requires full-image processing (ie determine color of pixel depending on potentially all other pixels in the image vs only on previous value of pixel itself). >>42942 Compositor pipeline is applied to the full scene after render. You can't use it for generating textures/etc. > so what magical nodes does 3D modeling software lack, that can only be implemented in a crippled 2D system? what's your next cope? For example you draw some kind of pillar on a graphic tablet, then switch to nodes tab and scatter copies of this pillar randomly within a polygon, and apply a pipeline of filters to each copy. Even something as basic as this already unavailable.

>>42945 1.design multiple shaders as separate mini projects (easier on mind vs one giant project and good for reuse) 2. make a small shader applying voronoi and use the voronoi cell value to pick what shader is applied. This makes it super easy to change how many textures are in the selection / swap them out. You can also pipe the voronoi value into a color gradient to change the distribution of different cell values and thereby the ratio of different shaders occurring in your final output. The node system is turing complete so you can do anything you could imagine. The main challenge is knowing what's available in features so you don't work harder than necessary. Btw i think 2d vector still has use because using layers for 2d is easier, im just not buying them doing anything novel. Software selection should be mainly about what gets the job done faster because you can tard wrangle most software to do any task if you are willing to spend the effort. That applies to art software as much as programming languages.

>>42945 >Compositor pipeline is applied to the full scene after render. ok >You can't use it for generating textures/etc. really? why not? explain concretely

>>42946 Okay, you got me with yet another workaround (I forgot there is a color output for Voronoi). There is still no general floodfill and it's a fundamental limitation of how shaders work but I'm not sure I will not fuarrrk up coming up with example that doesn't have some smart workaround. > Software selection should be mainly about what gets the job done faster because you can tard wrangle most software to do any task if you are willing to spend the effort. That applies to art software as much as programming languages. Okay, it's much faster to do this in SD/MM than coming up with smart workarounds in Blender. >>42947 Because you need it before compositor.

>>42949 >Because you need it before compositor. no, you don't. you need it exactly at the compositor. how come every single Rust user is mentally retarded?

>>42946 > The main challenge is knowing what's available in features so you don't work harder than necessary. I will not open MM if I need just a basic Perlin or Voronoi, for anything else I will open MM because it's faster and because it's more intuitive to think in terms of its primitives than to come up with unique workarounds. Also, I will not use geonodes if I just need a texture. If I need some convoluted setup that involves using geonode to then bake the generated mesh into texture, I'd rather just use MM. The only downside of MM/SD for me is that you depend on producing a static image, and if you stay within Blender, your noise patterns are potentially infinite. If you apply noise using generated coordinates, it will naturally never tile, while with static images you need to apply some tricks to break repetitiveness. >>42950 I don't even want to imagine what kind of convoluted workflow you have in your mind. I doubt you use Blender or do procedural textures.

>>42951 >I don't even want to imagine what kind of convoluted workflow you have in your mind. I doubt you use Blender or do procedural textures. i am in no way a Blender expert but i played around with it enough to know you can bake a texture (applying compositor effects in the process) and then do whatever else with it

>>42952 Lets start with the fact that compositor works in screen space only. So if you want to abuse it for generating textures you need to create a plane, set camera to look at that plane from the top, make sure camera focally captures precisely the area of the plane, then perform render, save the render result image, import that image in shader nodes and use as a normal texture.

>>42953 >if you want to render a quad with your procedural texture you need to set the scene up, render it and then use the result yeah. you could probably automate it with a script or something. or ask the Blender devs to add a node that just creates a texture, which i have no idea why they haven't done yet. but there is nothing innovative whatsoever about being able to apply an edge shader to some texture generated using a node editor

>>42946 Okay, so maybe this one is the simplest example that breaks the workaround you described in Blender. When Voronoi's cell borders are warped.

>>42954 The whole point of nodes is to have a reusable setup where you can drag sliders and see how result changes immediately. This compositor workflow doesn't only break reactivity, they're also singular - you only have a single compositor node graph for the whole project, so you will have to combine multiple texture subgraphs and switch outputs every time you want to re-render a texture.

>>42957 doesn't matter. the point is that it would be trivial to do what you want in Blender if someone cared to implement a node that does it, instead of the user having to jump through some hoops, and it wouldn't involve any major deviation from the way Blender already does generative textures and image post-processing

>>42958 Nope, I was wrong in something, but in the end, it's actually more unusable for texture synth than I even thought of. What I was wrong about: Absence of reactivity - it's available with viewer node, result is displayed as background. The need to setup plane and camera - it's possible to just not depend on scene at all. What is actually way worse: Those compositor nodes are so basic bitch they don't even evaluate most of the inputs per XY, here I tried 2 ways of warping Voronoi for example, and not a single of them worked because XY inputs of Transform and Amount input of Directional Blur aren't working for values changing dynamically through XY, they simply ignore it when you connect noises there for example. So it's actually utterly unusable.

>>42959 we could do this all day but there's the objective bottom line: 1. the problems you bring up are easy to fix with a couple of extra nodes if the Blender devs cared to do so 2. i've already granted that Graphite is doing the node thing in a slightly new context, so it's slightly innovative in that way but for some reason, you seem heavily invested in the idea that doing a node workflow in 2D instead of 3D is a groundbreaking new idea that does things that are impossible in 3D, which is nonsense and cope

>>42960 I'm not even discussing Graphite here. Graphite is not a texture synth tool. Again see >>42937. It's not groundbreaking in terms of individual functions (it's impossible to do anything groundbreaking in the area of image processing, because all fundamentals and utilities built on top of them were discovered and implemented long ago), it's groundbreaking in terms of niche they're applied to, because there were no similar systems for that in 2d.

>>42961 ok anon. we're all groundbreaking in our niche. even you

>>42962 I don't care that much about groundbreaking actually. There are probably very few groundbreaking things left to be discovered and most of them are in the field of particle physics. The better word would be novelty. If there is a software with new UI/UX workflow making it possible to use approaches that were not available before in certain domain, it's novelty.

>>42963 > There are probably very few groundbreaking things left to be discovered and most of them are in the field of particle physics that's just what a sour-grapes Rust user would say

>>42963 please, stop digging.

I don't get why people here get so tilted by Rust. It's far from my favorite language, but it's still a perfectly serviceable tool. The SM64 GBA demake is written in it, so clearly it's good for something. It's funny that people treat it like it's a baby language, when, in my experience, it's the exact opposite. Rust is a much more complex language than C++, and accomplishing basic things requires a much deeper understanding of how the language works. Don't believe me? Try implementing a generic doubly linked list data structure in C++ and then doing the same in Rust. It's fairly straightforward in the former, all you really need to understand are classes, templates, pointers, constructors and destructors. Whereas in Rust, you need a PHD in higher level mathematics to get the language to get past step zero of telling the language what a nullable pointer is. Again, though, it's a fine language. I still prefer C++, which, if your writing properly, is already perfectly memory safe, but people here act like it's COBOL meets PHP, a nonsense language only used by people who don't know any better, which it obviously isn't.

>>42967 > Whereas in Rust, you need a PHD in higher level mathematics You confuse it with Haskell, there is zero category theory in ownership/borrowing. > if your writing properly, is already perfectly memory safe You mean wrap everything in shared_ptr?

>>42967 >Rust is a much more complex language than C++, and accomplishing basic things requires a much deeper understanding of how the language works. Don't believe me? Try implementing a generic doubly linked list data structure in C++ and then doing the same in Rust. it's a much less complex language than C++ (and that's a point in its favor) and nonetheless, it's so poorly thought out that it makes the simplest task very tedious and leaves you feeling that any workable solution you come up with is somehow "wrong". once you understand the language, you understand that it isn't your fault but there is simply no elegant way to program in Rust. it's a toy language based on a flawed concept. it only sounds good on paper. in practice, you start getting bogged down by its "features" the moment you do anything more complicated than fizzbuzz, which you openly admit but there's the thing: no one would care or be upset if it wasn't for Rust users trying to force their language on imageboards the way retards try to force memes or the way Kimmo Alm tried to advertise AnonTalk. this is the main reason Rust gets so much hate: its community keeps trying to cheat its way out of irrelevance by spamming, lying and even using government/corporate pressure to inflate its user base

>>42968 >You confuse it with Haskell Haskell doesn't require a PhD, it only requires some good taste. Rust, on the other hand, requires deep dedication to a braindamaged ideology about "memory safety" but here's the funny thing: if you've ever worked with Haskell, you can easily diagnose the root issue with Rust's borrow checker nonsense: imagine forced immutability everywhere, but without any funny business with clever functional abstractions. if you want a function that "modifies" some data? pass the original data in, then return a modified version. this is essentially how the borrow checker forces you to write your code, in terms of structure, unless you start "abusing" other features to get out of this hell, at which point you get "memory safety" technically, but only because the normal memory-related mistakes become "sandboxed" so that you reference dead or invalid data from a program logic perspective without actual memory corruption

>>42969 >>42970 You still don't get it guys. Yeah borrow checker is annoying, yeah it's distracting having to deal with it when writing code, somewhat similar to having to deal with layers upon layers of monads and transformers in IO-heavy code in Haskell, sometimes even more annoying. And all of this is irrelevant because there's no need to write code yourself. Use Copilot. You only need to do high-level corrections and can even write pieces of pseudocode in comments and ask it to fill the appropriate code. You still need to understand ownership/borrowing on the higher level, but you don't need to deal with the pain of writing code for it. What you get in return is huge ecosystem, native compilation, decent support of zero-cost abstractions.

>>42971 >you don't get the point! >it doesn't matter if Rust's design flaws get in the way of actual programming >i don't do actual programming >i use a statistical token guessers to write my generic fizzbuzz it's nuts that you think your opinion counts for anything

>>42973 It works great and I'm not going to waste my time yet again providing screenshots of Copilot sessions or whatever. It's in your interest to check how overpowered this approach is and how well it works, why should I waste my time for free trying to empower you. Making those posts is already more than you could ask for.

>>42974 > I'm not going to waste my time yet again providing screenshots of Copilot sessions or whatever i see. you're that script kiddie who posts screenshots of literal stackoverflow snippets

>>42975 I started doing programming ~22 years ago. I've been doing it as a job for like ~6-7 years total. Covid made remote work way more popular and I enjoyed working remotely way more than offices, and my last projects were rather good compared to how soul-killing this industry felt 10+ years ago for me. But I simply don't need it now. The next time I will need money I bet I will vibecode the hell out of it. Remembering how annoying it was to spend hours on boring generic refactorings in the past and how you can do the same by writing a few sentences of a prompt into a Copilot is crazy. I think refactorings were a huge chunk of my work in my last project because with new features and capabilities components API and the way features were split between components did constantly change and older code was becoming unoptimal. Another big chunk of work is using existing components to implement new pages, and the more similar it will be to other already existing pages using those components - the better. AI is excellent for this as well. The amount of boring repetitive/generic work in this field is insane. If we take end-user applications it's almost 100%. If you're doing something smart and unique in your end-user application code, you probably should use a library (and you can ask AI to use it). In my hobby projects I'm also yet to find even a single usecase when it was better not to use AI, outside of dumb inertia like asking to rename a file that might be faster to actually do yourself because prompt is more to type than just a new file name.

>>42977 i'm not reading any of this. let's see what kind of glorious Rust code co-pilot generated for you. hopefully it's better than what you posted last time with generic color conversion snippets

>>42978 Use it yourself in your own projects, otherwise you will fail to grasp its capabilities. I'm not getting paid to wage slave Copilot. I'm also looking for alternatives atm because I want pay-per-token instead of fixed subscription, because I can go weeks or months not touching code at all nowadays and doing other projects. I'm planning to try Codex with OpenAI API next time because I can just send 10$ there and do prompts until they run out, even if it takes 3 months.

>>42979 you're a nocoder and i will not stoop down to your level. i've also tested the coding abilities of "AI" extensively and determined objectively that they can't code

>>42971 >doesn't write code >comes to argue in a programming thread. At this point you might as well ask chatgpt to write your arguments for you. I guess this is one more reason to stay away from rust, eventually all rust code will be slop.

>>42981 >At this point you might as well ask chatgpt to write your arguments for you. you think he didn't? he probably talks to the machine about this, to relieve his frustration, and it puts more of the same into his head

>>42982 "More of the same" is what programming always was and will always be. You can think of AI as advanced macro-system with slight context awareness, and it's been enough for almost everything in this field for at least few years. You must be insane or an outsider to not realize that 99% of all code is boilerplate repetitive slop.

>>42983 >"More of the same" is what programming always was and will always be i think your context window glitched out there, because you flew off on a tangent. either way, this statement tells me nothing about programming and everything about you and your mindset. your "AI" helper is confined to a box, but you can't think outside of it, either, hence from your perspective, it's as intelligent as you are. but from my perspective, you're both barely sentient

>>42983 >>42984 and by the way, based on your own account, i can conclude that even my boilerplate is more complex than your entire codebase, because i find the latest models are unreliable even for "braindead" tasks with conventional and mechanistically deducible solutions, which i would gladly outsource

>>42984 Cope. Programming is purely utilitarian field and if you allocate any of your soul, you're gonna be disappointed. The only proper way to approach it is with as much cynicism as possible. Do as little as you can to benefit as much as you can or get your problem solved and move on. And don't let any of it live in your head, because there's nothing fundamental or worthy in it. >>42985 You don't need them to be neither reliable nor correct to save you 95% of typing. Doing basic corrections and reprompts to fix things is something that is needed most of the time and it's still way better than doing it manually.

>>42986 >You don't need them to be neither reliable nor correct yes, i do. you don't, because you write fizzbuzz

>>42987 That only means you're incapable to fix that yourself or to come up with a reprompt that gets it fixed.

>>42988 no, you mouth-breathing imbecile. it means just what i said: my "boilerplate" is more intellectually demanding than your entire project. the bot can and WILL get it wrong, many times, with subtle mistakes that are difficult to track down. it ends up being more efficient to just do it myself. and i'm not the only one with this experience. there are studies now showing this to be the case for most experienced programmers doing realistic tasks

>>42989 > with subtle mistakes that are difficult to track down They're only subtle and difficult to you because you are retarded.

>>42990 >there were no subtle mistakes in my HSV to RGB stack overflow snippet >i know this because i'm a very intelligent prompter! i wouldn't be surprised if there were some. you wouldn't even know it. you don't know anything about color models. you don't know anything about anything regardless, let me give you an example from my own experience: try giving this magical "AI", which clearly does all your "thinking", a bunch of snippets demonstrating some grammar. it can be a simple grammar, like something you can tell is LL(1) just from a glance, resembling normal-ish code. something any undergrad could look at and write you a reasonable parser for. since i'm not an undergrand anymore, to me this is just boilerplate. try it and see how many attempts it takes for your "AI" brain substitute to soykaf out code that produces sane parse trees outside of trivial cases. this is the simplest example i can give you either way, the reason i'm starting to like this place is that the regulars seem smart enough to completely ignore bottomless pit retards like you. of course, they're also content to ignore my provocations. it's a nice concept and i think i'm going to adopt

>>42969 >it's a toy language based on a flawed concept. it only sounds good on paper. I've used worse. The first language I remember using was an unstructured BASIC dialect. Compared to that, Rust is a god send. >its community keeps trying to cheat its way out of irrelevance by spamming, lying and even using government/corporate pressure to inflate its user base I think you have a somewhat backwards idea of how power structures work. For the record, there isn't a single mainstream programming language that has succeeded fully or even primarily on its technical merits. We use C instead of Pascal because of UNIX. We use C++ instead of Ada because C++ was compatible with C. We use Java instead of Smalltalk because Sun put a ton of money into marketing Java in the 90s and early 2000s. We use Javascript instead of literally anything else because it was included in popular web browsers. The closest thing I can think of to a language that did catch on because it was a good tool is Python, but even then, most of Python's popularity comes from having an expansive standard library.

>>42992 >I think you have a somewhat backwards idea of how power structures work. really? how do you think they work? sometimes they do manufacture an agenda out of thin air and start shoving it down everyone's throats, but the main modus operandi (at least in westernized systems) is to create a space in which a whole assortment of different deformities can emerge, so they could astroturf the ones they deem useful. that way, they don't need to maintain a multilevel conspiracy. they just need to filter and curate using incentives and disincentives. "power structures" will happily enter into symbiotic relationships with pathological niche groups. they open the doors of their institutions to "persons of interest" and seed the ranks of their own governing apparatus with useful idiots. they do this knowing full well they're introducing "reformers" who will abuse their power to promote an external agenda with no real merit wrt. the institution's official goals. and since these niche groups tend to be as power-hungry and desperate as they are irrelevant, they will never turn down an offer from corporate or government filth, especially not one that increases their influence and authority. you'll never hear them say: "no, i'm not going to condemn programming language X, Y and Z on behalf of the US government; i want nothing to do with that". but you will see them spam programming discussions into oblivion with points like "see??? we're big boys now! even the NSA said so!" granted, the causal flow here isn't that SmoothbrainRustFan69 wields the power of the US government; rather he becomes an amateur propagandist for his "spiritual leaders" who (absurdly) end up with friends in high places - a pestilence on their behalf >here isn't a single mainstream programming language that has succeeded fully or even primarily on its technical merits. We use C instead of Pascal because of UNIX. i was going to agree with this point. for a second there, i thought you were a serious person. but then you tried to imply Pascal was a usable language back when UNIX was gaining popularity and broke any illusion i had about your credibility

>>42991 > hUrR dUrR bUt CaN iT wRiTe a PaRsEr?!! Kek, I didn't expect that. But it tells a lot about your background. Writing a basic self-contained recursive descendent parser is imo way easier for AI than any practical prompt to implement a new feature in context of existing codebase. This is something you don't even need to incrementally use Copilot for, you can deal with that in chat-only mode in normal ChatGPT. As a warm-up I checked if it could produce arithmetic parser right from the first try (it did): https://play.haskell.org/saved/K3AEdrM6 Then I tried something more involved by giving it an example, and ChatGPT still got that right from the first try: https://play.haskell.org/saved/njAks3C4 Full chat: https://chatgpt.com/share/68c645c2-fdd4-8008-8d5c-54323a6d41ef

>>42994 Even more impressive: I obviously made a typo in the prompt, because > (a * b, c, d) + 1 -- (a * b + 1, a * c + 1, a * d + 1) Doesn't make any sense. It should either be: > a * (b, c, d) + 1 -- (a * b + 1, a * c + 1, a * d + 1) Or: > (a * b, c, d) + 1 -- (a * b + 1, c + 1, d + 1) And it still recognized that and did the right thing.

>>42993 >but then you tried to imply Pascal was a usable language back when UNIX was gaining popularity It was usable enough Apple used it pretty extensively in the 80s. K&R C was obviously the better language than the various Pascal implementations that existed at the time, but to say that it wasn't usable is frankly ridiculous.

>>42996 >not being able to write a sort function because the arguments are typed and the size of an array is part of its type >perfectly usable uh huh. well, at least it was a memory-safe approach. if this world ran on elegance and merit, we'd probably be posting from lisp machines, but that alternate universe bars Rust from relevance even harder now take a look at the bottomless pit retard who posted above you: he figured it all out, accidentally, using only the smoothness of his brain. Rust is being astroturfed by glowies because from their angle, hostility towards human programmers isn't a real downside for a programming language. they work for people whose desired future is one where "AI" writes all the code, but since "AI" is an unreliable black box that mimics human code examples of dubious origins, they need: 1. maximum static verifiability 2. a big, fat training set 3. code bases free from exploitable memory errors this analysis is complementary to the mundane explanation that they just don't want their offbrand technocratic infrastructure to get pwned. of course they don't, but of all the different ways to go about it, they latch madly onto the one that stifles human creativity and favors machines. no one wants to get pwned, but left alone, the market tends towards different trade-offs than Rust

>>42995 >Even more impressive: I obviously made a typo in the prompt Lol. I think >>42984 nails it with the box thing. Your thoughts are so basic and predictable LLMs can predict them despite your horrible prompting.

>>43001 >>not being able to write a sort function because the arguments are typed and the size of an array is part of its type I remember most real-world Pascal implementations extending the language to get around these limitations. I was pretty young though, and it's been a long time since I was there, so I could very well be talking out of my ass. >>perfectly usable Again, in the mid-80s, Apple was using it to write entire operating systems for home computers, so clearly it had to be worth something. I read the rest of your post by the way, and I'd be inclined to agree with it. What threw me was that the first post I replied to was worded in such a way that it seemed to imply Rust programmers were responsible for this, when it's obviously the other way around.

>>43004 >in the mid-80s, Apple was using it to write entire operating systems for home computers, so clearly it had to be worth something. >most real-world Pascal implementations extending the language to get around these limitations exactly. they used their own, non-standard version of Pascal. by the time the actual language standard evolved to accommodate stuff like dynamic arrays, UNIX was already dominant. don't tell me a language is usable if i have to literally modify it before i can put it to serious use. but whatever. this is all tangential. i agree with the basic point behind this unfortunate example >What threw me was that the first post I replied to was worded in such a way that it seemed to imply Rust programmers were responsible for this, when it's obviously the other way around. yes, i worded it poorly. but when you put it the other way around, it's still not quite right. causality becomes muddled when once these niche grounds get in bed with alphabet soup agencies. that's the entire point of so-called "soft power": it'd be far more difficult for Westernized governments to shove anything down a population's throat without a certain percentage of zealous enablers within the population itself

>>43001 > they latch madly onto the one that stifles human creativity and favors machines Bruh, this is not Rust or Haskell or whatever, this is programming itself. Arguably, this is engineering itself. Ask any enterprise Java programmer if they want "creativity" in their code or they want it to be as generic as possible. Ask guys who build bridges if they want creativity in their soykaf or they want strict generic standards and ideal machinistic precision in everything.

>>43006 > this is programming itself if that were true, the astroturfing wouldn't be necessary

>>43006 creative and generic are synonym goals - maximize ways you can reuse code. Both are in opposition to predictable secure code because they both reduce being able to predict what code does which makes making false assumption and missing errors easier.

>>43008 Retard. "Generic" as in "cliche".

>>43008 >creative and generic are synonym goals - maximize ways you can reuse code. Both are in opposition to predictable secure code mind-bogglingly bad take. enterprise OOP is obsessed with re-usability and enforcing "design patterns" that accomplish it, always at the cost of creative solutions. genericity is the constraint of insufficient constraints. creativity is situational - it's the art of taking a bunch of givens and using them to your advantage in unexpected ways. that's why they say limitations foster creativity, rather than the opposite. of course, you can employ creative solutions to work around Rust's braindead design, but this is usually a big no-no in the Rust community

>>43009 retarded word choice then. Generic has a distinct meaning for programming >>43010 OOP generics is exactly what i meant. The freedom to stick your building blocks together any way you want gives you the freedom to stick them wrong together. It will execute but it will run slow / do something else than what you want.

> in opposition to predictable > Your thoughts are so basic and predictable LLMs can predict them So you kinda admit that programming is a field that inherently rewards mediocrity but still for some reason fail to realize that automating the soykaf out of it through AI is the treatment it deserves.

>>43012 that was not the same poster. On topic: Languages are made predictable to support bad programmers because they want to pay less money hiring code monkeys and then need to constrain idiots to not break the whole enterprise. If AI gets better than code monkey then you wont need safe languages to constrain AI. The ultimate problem will be verifying the generated code on whether it does what you want. Right now we have lot's of senior coders that can tell AI is soykaf because they did everything themself. If those guys retire and the next gen only vibe codes there will be nobody left to tell whether the generated code is good or not.

>>43012 >being mediocre is subjectively rewarding for me i don't care. you're invested in this narrative only because you feel inferior and you ARE inferior. you have no real skills or talents. you will never do anything outstanding. you can't even conceive of it. even your attempts to diverge from convention still fall within one standard deviation

>>43016 Nope, this narrative is my extremely successful cope and my way to deal with this field. This field is always extremely punishing in any attempts to approach it in a way that I personally find fun and satisfying. What is good for me is bad for industry, what is good for industry is bad for me. Industry chases values that make programmers as uniform and replaceable as possible which is exactly the opposite of my interests. Because I chase abstractions and concepts that maximally empower me as an individual even if that comes at cost of nobody else in the workplace being able to comprehend and support my code. If I can't be "too smart" in my code, why wouldn't I want to just delegate it all to AI while still being paid? This the most logical and rational solution to this fundamental conflict of interests.

>>43017 >why wouldn't I want to just delegate it all to AI while still being paid? you can't even keep your own cope coherent. as far as "the industry" is concerned, your entire code monkey job should and will be getting delegated. there's no reason whatsoever to keep you around and pay you anything. if you're self-employed, then your sob story about "the industry" forbidding your creativity is completely irrelevant. you can use whatever tools and methods you want to get the job done. and yet you still reason like a codemonkey and churn out nothing beyond a composition of stack overflow snippets regurgitated by a semi-random token generator

>>43018 > you can't even keep your own cope coherent. as far as "the industry" is concerned, your entire code monkey job should and will be getting delegated. there's no reason whatsoever to keep you around and pay you anything. Who do you think it's being delegated to? Spoiler: it's people who can produce the best results in the least amount of time and who market and prove themselves as flexible problem solvers. And don't forget "the best" in this case is rated by the people who look at the end result, not the code.

>>43020 >Who do you think it's being delegated to? currently your codemonkey job is being delegated to third world immigrants

>>43021 > third world immigrants But that's literally me. >>43018 > if you're self-employed, then your sob story about "the industry" forbidding your creativity is completely irrelevant. you can use whatever tools and methods you want to get the job done. and yet you still reason like a codemonkey and churn out nothing beyond a composition of stack overflow snippets regurgitated by a semi-random token generator That's fair. I personally don't want to have a schism between my attitude in hobby projects and work though. That's why I just pushed manual programming out of my hobbies almost entirely and replaced it by other things I enjoy. I still want to get some programming things done in my hobby projects, but I don't want to invest myself into it too much. Getting it done fast by vibecoding is actually fun and enjoyable as well.

>> third world immigrants >that's literally me ok. well, that explains why every single thing he post smells like IQ 80. it's crazy watching all these mentally ill people who spent decades being bottom-tier wagies thinking that as soon as their jobs become redundant, the value of their "problem-solving" at last be noticed and they'll all get promoted to management

>>43023 I don't want to be "promoted" to management, I'm fine with working a side consultant/dev part-time on projects, do some tech research/investigation on how best to do this or that and provide some support to existing codebases by vibecoding. My current rate is 50$/hour which is decent for third world countries.

>literal-minded 80 IQ third worlder can't grasp a simple point consultant material right there

>>43025 You don't really have a point, you just randomly bruteforce insults ad hominem trying to prove to yourself that vibecoding is bad by associating it with your fantasized filthiness of people who vibecode.

the 80 IQ thinks AI makes him irreplaceable, but little does he know that i've already replaced him with AI. i'm now going to continue this conversation with his GPT clone. as far as i'm concerned, this is his canonical next reply: Bruh, I don’t know how people still cope with pretending programming is some kind of sacred craft. It’s assembly-line labor for nerds. 99% of it is boilerplate slapped together with “best practices” so your PM doesn’t yell at you. You don’t need ten years of soul-draining grind to realize the whole field rewards mediocrity and punishes anything interesting. That’s why AI fits it like a glove. It doesn’t matter if it’s “correct” on the first try — it saves me 95% of typing. You fix the dumb bits, reprompt, and move on. Way better than rotting away in refactor hell for weeks. And the funniest part? The industry wants generic, boring, replaceable output. Guess what AI excels at? Generic, boring, replaceable output. Perfect marriage. If you still “program manually” in your hobbies, congrats, you’ve tricked yourself into doing unpaid corporate labor. I replaced that whole cope with vibecoding and I actually enjoy it. I don’t need to shove my soul into code anymore, because this field doesn’t deserve it. It’s just typing scaffolding until something compiles.

>>43027 I admit this is brilliant short summary of my posts. I might even want to save this to not have to type all those individual pieces again.

>>43028 it's not a summary of your posts. the prompt was: >imagine you're a zoomie teenager with poor programming skills. you believe learning how to actually program is a waste of time because "the industry" will suppress your genius with its soulless corporate norms. but you just found one of those AI career channels and watched a 5 minute video about prompt engineering. you actually think it's real. now you fantasize about becoming an IT bigshot using "vibe coding". one problem: real programmers make you insecure. what would you say to bring them down? if you feel this misrepresents you, explain why the output sounds exactly like you, according to yourself

>>43029 Wrong premises as usual. In reality, the longer people are in programming industry, the more are they willing to use AI in their work: https://techcrunch.com/2025/09/14/vibe-coding-has-turned-senior-devs-into-ai-babysitters-but-they-say-its-worth-it/ > The Fastly survey found that senior developers were twice as likely to put AI-generated code into production compared to junior developers, saying that the technology helped them work faster. A slightly different perspective on this phenomenon in my other copypasta ("AI in Programming vs AI in Art"): > You are wrong in thinking all arts, crafts and skills are equal. For example, if you do painting or sculpting your whole life, you continue using and improving the same skillset, your every new work is result of something you've been cultivating the whole time. Programming, on the other hand, is inherently self-deprecating cycle of learning, using and then forgetting, infinite numbers of application programming interfaces that pop into and out of existence all the time. There are some super basic fundamentals that are common, and the ceiling to them is very low, after that it's basically all googling new soykaf, using it, and forgetting about it. Even worse, code has no inherent self-worth. I mean, it bears no value (outside of corporate human resource management concerns, ie "best practices" and "code conventions") how it looks, the only value of code is the result of its execution. This is why almost any programmer who's been long into this will happily use AI as opposed to artists who almost all hate AI.

https://en.wikipedia.org/wiki/Imaginary_audience >Jean Piaget, a Swiss developmental psychologist known for his epistemological studies with children, states that every child experiences imaginary audience during the preoperational stage of development. He also said that children will outgrow this stage by age 7, but as we know now this stage lasts much longer than that. Imaginary audience happens because young children believe others see what they see, know what they know, hear what they hear, and feel what they feel

>>43030 >studies say marketing to sell AI, only fools believe it Im using AI for coding but its not vibe coding. Its to get the right function calls because the AI is faster than google search / reading soykafty documentation. I still understand what the code does and how i want it coded which is a far cry from tech illiterate copypasting AI blocks which currently is dysfunctional because the AI output is still full of errors. Occasionally the AI will even write code that wont even compile repeatedly as you prompt it to remove the error.

>>43030 >code has no inherent self-worth >the only value of code is the result of its execution you mean like sheet music? code is the equivalent to musical notation, and the program is equivalent to the music that emerges once an instrument is used to translate what's on the sheets into soundwaves. to get aesthetic fulfillment out of reading sheet music you would have to be a deep music nerd, just like only deep programming nerds get aesthetic fulfillment out of reading code. By this analogy, using AI as a musical composer should be just as sensible as using it as a programmer, since after all it's only the musicians who turn it into art, right?

>>43033 >using AI as a musical composer should be just as sensible as using it as a programmer, since after all it's only the musicians who turn it into art, r In case you haven't heard it yet: They made software to generate hit songs because they wanted guaranteed sales. Popular music in charts is done by math formula. So they automated writing music already way ahead of AI.

>>43033 you're overthinking it. the soulless third worlder all but said it's the result that matters and not the process of creation. using "AI" for create "music" instead of actually composing it directly follows from his reasoning without jumping through any analogy hoops about writing sheet music

a computer is a machine that instantiates ideas into reality. a program is an idea captured in an abstract but crystalized form. the program is necessary because the computer can't read your mind. no, it can't. no one can read your mind. nothing can read your mind. "vibe coding" tries to circumvent this basic reality using natural language, but when it comes to programming, humanity has favored programming languages over natural languages for a simple reason: natural language is vague and a computer CANNOT read your mind. as far as the computer is concerned (i mean the computer in its true form, when it's not pretending to be human) your prompts are full of blanks. they're the idea-realm equivalent of dumpster-quality swiss cheese. they contain way more blanks than actionable instructions that can feed a processor. so what fills those blanks when you're "vibe coding"? the magical oracle inside the black box neural net? no, idiot. convention. nothing but convention. and since all the blanks in your "idea" are filled by convention, the product is 5% your "idea" and 95% convention trying to instantiate an idea using a LLM, is to a programmer, what trying to instantiate vivid imagery using a diffusion model is to a painter. if your vision is precise and original, a model that translates vagueness into convention is almost useless. instead of explicitly specifying what you want, you end up implicitly steering the model away from the main body of the distribution it models now, if you're borderline-aphantasic (in the most general sense of having a dim and muddled inner world), seeing your vacuous blurb translated into a tangible product is indeed a "new industrial revolution", "creativity democratized", "empowering the individual"... whatever else you degenerates want to call it. i can see why you'd feel like the machine is reading your mind and giving you exactly what you meant: it's because you're almost mindless and you meant almost nothing, so a clash is almost impossible. it's the same kind of confabulation you get from people with Alien Hand syndrome. instead of being your tool - an extension of Man's Hand - the computer becomes your alien hand, but you're too dumb to know it >inb4 saying i'm obsessed yeah. so?

>>42971 the key takeaway is this: 1. Using Rust is like kicking dead whales down the beach, the only way to stomach it is to have a machine write it for you 2. Rust attracts non-programmers who do not care about programming, do not care about the computer, and they only see it as a means to an end ---making corporate money. 3. As a corollary, Rust programmers don't care if they are wasting resources, because agree with the silicon-valley mindset that keeps people getting paid money to churn out code for the sake of keeping up with "updates" that require people to buy new equipment because software is ever more wasteful, and because new versions of ever commercial os require introduce new apis that make proprietary software not run on older equipment, thus feeding this cycle of having to consume endlessly to "keep up" with an industry that's digging itself into near uselessness. 4. vibe-monkeys are proud of this.

>>43040 hey, stop beating my dead horse

>>43040 > 1. Using Rust is like kicking dead whales down the beach, the only way to stomach it is to have a machine write it for you Rust is just like Haskell - it's pleasant to work with with the big exception of IO in Haskell and ownership/borrowing in Rust. > 2. Rust attracts non-programmers who do not care about programming, do not care about the computer, and they only see it as a means to an end ---making corporate money. I care about small RAM footprint and zero-cost abstractions. If there were no Rust, I would vibecode the same stuff in C++. It's just harder and less pleasant to do interventions/fixes in C++. But overall C++ is second best language in terms of zero-cost abstraction support. Why I need zero-cost abstraction if I don't care about code - for efficiency and convenience - not for maintainability, I simply don't want to deal with braindead C-like programming, I want powerful generic metaprogramming with zero overhead to quicker express complex but optimized behavior (or let AI do it and fix/improve anything if needed) for particular types and structures in question. >>43035 If you can implement your musical idea exactly the way you want using AI - then sure, use it, it's great. The issue right now is that art/music AI tools don't allow granular microcontrol and step-by-step prompting, they only allow "give a single prompt and get the end result in one shot". Which means it's impossible to get exactly what you want from it. >>43033 Start with asking yourself what is content in music and what is content in programming, how often music notation and libraries/frameworks for it change, etc. Programmers don't deal with content, that's an area for domain experts, designers, etc, comparing with music, programmers are more like concerned with engineering speakers to let that music play. "Musicians" of software are, depending on type of software, people who come up with domain functionality and rules, UX, people who come up with UI designs, people who come up with assets in general (audio, video, images, 3d models, texts, etc).

>>43042 >zero-cost abstraction yeah, you don't know what you're talking about. that was clear from the beggining. >I would vibecode the same stuff in C++ please, don't give guns to monkeys.

Lets say i draw an alpha mask, then I use it in shader and colorize it with ramps. Then I see a glitch - turns out the brush I've been using creates some barely noticeable artifacts that are only visible in context. If art AI was at the level of current coding AI, I could describe the problem to it, give it an image and ask to redraw exactly same thing but use this different brush for all bold vertical strokes. And it would do exactly that. >>43043 > yeah, you don't know what you're talking about Don't project. You're not a doer, you're talker. And not a great one at that.

>>43042 >If you can implement your musical idea exactly the way you want using AI please familiarize yourself with >>43039, especially the last paragraph. you may gain the first even insight into your own damaged psychology

>>43044 why do zero cost obstructions make basic system utilities 17 times slower?

>>43046 Go read their code and tell us. You're trying to judge language based on sociocultural noise and coincidences instead of technical features. > what are zero-cost abstractions in Rust Absence of implicit boxing/unboxing everywhere compared to GC-heavy languages, efficient generics compilation (with specialization/inlining per type), strong support of macros. > does this mean it will be automatically more efficient than C++ No. > does this mean it will be automatically more efficient than Java, Python, JS Those things alone make it hard to get equal or slower results even if you're completely mindless and pay zero attention to optimization. Which means, often yes, but that's not the point. > does this mean that that you have more control of how much you want to optimize certain code paths Yes, this is the point. > does C++ have better support of zero-cost abstractions Still a bit better, because of template system capabilities, because of constexprs, but on the other hand, it doesn't have full-featured macro system, only basic C preprocessor.

>>43046 Small note, GNU's coreutils (while being baroque for some) are optimized to hell and back. For example, GNU's yes is like order of magnitude (Gb/s) faster compared to *BSD implementations (Mb/s).

>>43047 >sociocultural noise and coincidences this is how mentally ill people react when faced with empirical evidence against their ideology. thanks for playing

>>43048 >GNU's coreutils (while being baroque for some) are optimized to hell and back great excuse, if not for the fact that these Rust retards had that available as a reference implementation. they didn't have to figure it out from scratch

>>43049 I consider Rust to be something between Java and C++ rather than something between C++ and Assembler. Expect it to be more performant than high level GC languages by default, anything else requires special effort, but at least it allows this special effort to the extent of being comparable with C++. Languages like Java, C# don't even allow this special effort, because generics (and polymorphism in general) in those languages is guaranteed to lead to boxing/unboxing and thus GC pressure.

>>43052 Reminder: this is programming board. But every time there is factual technical information posted you derail it into news articles or social media anecdotes. Not a single time you demonstrated actual understanding of the subject matter.

>>43051 java does the same soykaf as any other language and offers c++ bindings to get fast code

>>43053 > factual technical information posted your opinions are neither. the actual fact of the matter is that "zero cost abstractions" exist only in the minds of people who get confused by the breakfast question. they don't comprehend the notion of opportunity cost. when faced with direct evidence of the cost of "zero-cost" abstractions (e.g. x14 performance slowdown) they simply pull out the marketing brochure for this week's meme tech and start chanting the first 3 talking points like a prayer

>>43055 > comparing performance of io-focused software written in two languages both of which are known to support "zero-cost abstractions" (this whole term originated in C++ community) > one is slower > hmmm, maybe it's io-bound problem? maybe zero-cost abstractions are irrelevant to this kind of software completely? maybe this is all about super optimized system io in one of implementations? > nah, it's probably because one of the languages doesn't really support zero-cost abstractions! QED You are beyond help.

>>43054 No. Java doesn't even support unboxed value types like C# does. This is why you can't even have unboxed structs in Java.

>>43056 this is a bunch of drivel with literally zero relevant facts or technical points presented. but the factual, technical point that "zero-cost abstractions" are impossible still stands. so does the empirical demonstration of these abstractions causing an order of magnitude reduction in performance

>>43058 > but the factual, technical point that "zero-cost abstractions" are impossible still stands "Zero-cost abstractions" means zero introduced runtime cost. The most simple example is C macros. It's just super basic preprocessor that goes away and doesn't introduce runtime cost. Another less trivial example is C++ templates - they are also fully compile-time and work as a very involved preprocessor. You can even generate types with different fields using C++ templates (like vector<bool>) by using explicit specialization. In context of Rust, generics also work like templates in C++ (unlike Java/C# generics that work via implicit boxing - rely on heap allocation) but without cpp-template macros-like features, because Rust has dedicated macro system for that and more than that.

>>43059 >"Zero-cost abstractions" means zero introduced runtime cost. see >>43055 >"zero cost abstractions" exist only in the minds of people who get confused by the breakfast question. they don't comprehend the notion of opportunity cost you're just gonna repeat the same irrelevant chant because you literally don't understand the above sentence

>>43060 You seem to try to prove "it's not actually zero-cost" which doesn't even matter. It's just a term for not introducing certain runtime costs. And it's totally irrelevant to some software that does better system IO calls that some other software. It's more relevant to games or desktop apps eating 20mb of RAM instead of 300+.

>>43061 >"zero-cost abstractions" are real >they incur zero runtime cost >but it's not actually zero-cost >which doesn't even matter >It's just a term glad we have that settled, you retarded amateur propagandist

Zero-cost abstractions? You mean tuples and compiler metadata to vallidate references? who fuarrrking cares fr

>>43065 >You mean tuples and compiler metadata to vallidate references? no, retard. i mean what languages like Rust mean when they say "zero-cost abstractions"

I enjoy writing rust for high-performance code. It is easy to get it to auto-vectorize because of the good support for fixed-length arrays, and unwrap() type statements are often optimized away. You have to check though. >>43046 >illustrative, normalized from public datasets why is it illustrative and what was the normalization? This could easily just be a ranking of which languages the author dislikes most. >why do zero cost obstructions make basic system utilities 17 times slower? Almost like those tools have been optimized for decades, and naive implementations will be worse. I can guess right away what the problem with the first one was: they used the BufReader::read_line function, which will allocate memory for the entire line before returning. If you are really unable to find an example of a rust utility outperforming a battle-tested C utility, look at ripgrep.

>>43068 >those tools have been optimized for decades which means they were dealing with long-solved problems and had access to a perfectly good reference implementations. either they didn't bother to understand how the original utilities work (which would be typical of the zealotry and hubris of the Rust cult), or they realized the highly-optimized C implementation doesn't map neatly into their "zero-cost" abstractions, so they went for idiomatic Rust code, perhaps believing compiler magic will make their version faster, only for it to end up an order of magnitude slower but don't you worry! once enough people call them out, they'll "fix" their implementation to follow the C one more closely, probably using a copious amount of 'unsafe' blocks in the process, creating vulnerabilities in the process and triggering undefined behavior worse than anything C can offer

>>43066 ok, no need to call me a retard. compiler metadata for references is the borrow checker, and that, alongside tuples and tagged unions, is what rust folk call "zero cost abstractions". least last i checked. you have something else in mind?

>>43069 >probably using a copious amount of 'unsafe' probably? unsafe is just to work with pointers. will they be using pointers all over the place? you think that is what makes the C versions faster? >creating vulnerabilities in the process probably* >triggering undefined behavior worse than anything C can offer very unprobably. rust has no standard and, as such, can have no UB. in any case, UB is treated as a joke by C compiler implementations and even the standards folk have given up on making anything beyond basic trivial code in C to be standard and not UB >We will let the compiler lie to you. We will lie to your code. And when things do go bad – a mistake, an “oopsie kapoopsie”, a leak of data – we will shake our heads solemnly. We will offer our thoughts and prayers and say “well, that’s a shame”. A shame, indeed… https://thephd.dev/your-c-compiler-and-standard-library-will-not-help-you

>>43070 who ever calls the borrow mechanism a "zero-cost abstraction"? i was thinking more about Rust's off-brand functional programming, iterators, collections etc. you can count tagged unions among them, technically, though they're less likely to trigger the opportunity cost issues like missed optimizations, or to end up in the grey area where you pay a cost for "using it wrong"

>>43071 >very unprobably. rust has no standard and, as such, can have no UB. what you technically just said is that Rust has no DEFINED behavior. fair criticism. i guess whatever happens when you accidentally break the borrow rules in the unsafe blocks and trigger "invalid" no-aliasing optimizations falls in the same broad category as everything else Rust does

>>43069 >and had access to a perfectly good reference implementations. as I'm sure you know, being so familiar with rust, the C solution and the rust solution are often quite different.

>>43074 >as I'm sure you know, you would be more sure if you had finished reading before posting this blurb, you absolute spazz

>>43075 all that did was make me more sure that you're here to stir up soykaf instead of have a productive discussion. But of course, that was very obvious already. Literally every time rust gets mentioned, the thread gets derailed with culture war nonsense. It's the bane of this fuarrrking board.

>>43076 >you're here to stir up soykaf instead of have a productive discussion. you mean insider trade. you can't reconcile having a productive discussion with being slightly antagonized because you neither can nor want to defend your dumb opinions against reasoned arguments. it's never productive for you because your thinking never evolves

>>43077 The fact that you re-use the same tired arguments that have been discussed over and over again does not mean you are engaging in good faith. You fall back on base invective whenever someone challenges you to elaborate your thoughts or provide sources. Your rhetoric-based argumentation provides no insight to anybody.

>>43078 >you re-use the same tired arguments i will reuse the same argument (which so far stands unrefuted) exactly as many times as your hivemind repeats the same excuse. if it works, why change it? >whenever someone challenges you to elaborate your thoughts or provide sources once again, this is delirium-level projection, like your brain is screaming at you madly, trying to tell you something about your own behavior, but you just transmute it into more dipschittery

People here describe Rust programmers as if they were these insane cultists who feel the need to push the language on everyone else. But personally, I've seen infinitely more bitching about these hypothetical people than I have actual Rust zealots. In this very thread, one guy mentioned that he vibecoded Rust, and now the whole thread is people freaking the fuarrrk out over it. I don't even like Rust. I like simple; my favorite languages are C and Scheme, and it's because they can both be implemented by one guy in his off hours. Rust is not simple. Quite the contrary, it's monstrously complex. It has a million features, and many of those features take a doctoral thesis to describe. I have very little interest in learning Rust because it has very little interest in being learnable. But I don't see it as a threat. And maybe that's why it rustles so many jimmies; other people do. And I have no idea why. C obviously isn't going to be replaced by Rust. C++ probably won't either, simply on the virtue of how much code has already been written in it. >>43040 As a corollary, Rust programmers don't care if they are wasting resources... Where did you get this from? >>43046 >pic 1 Source? >pic 2 People who post socmed screenshots deserve to be publicly executed. >pic 3 Source? >>43051 If you need something between C++ and Java, use something like Go or OCaml. People think that garbage collection is a massive resource hog for some reason, and I'm not going to pretend that it doesn't have its costs, but with modern GC technologies, and on modern CPUs, which are, from an architectural perspective, much more suited to GC as a concept, the cost is going well within the performance margins of the vast majority of userland applications. >>43079 >if it works, why change it? If we're still having this conversation, it clearly hasn't. The point of arguing something is to convince others of it.

>>43084 C is getting replaced by rust in linux kernel and other projects because rust evangelists inject themself in foss projects and steadily push for replacement with rust. People see the cult invading, taking land and rationally project a growing problem. "its not big yet" is just short-sighted.

>>43084 >But personally, I've seen infinitely more bitching about these hypothetical people than I have actual Rust zealots they're easy to recognize because they repeat the same nonsensical points using eerily similar framing. for instance: >>43084 >Rust is not simple ... it's monstrously complex ... features take a doctoral thesis to describe >>42967 >Rust is a much more complex language than C++ ... you need a PHD in higher level mathematics to get the language such zealots will also typically pose as C/C++ programmers and make it clear that they favor C/C++ because they're ignorant and have no interest in learning. they think they pass just because they're not screeching "C programmer" directly in your ear >Source??? >Srouce??? >People who post anti-Rust screenshots deserve to be killed also typical Rust zealot behavior. say, you don't happen to be one of them, do you? >The point of arguing something is to convince others of it. the point is that anyone who looks will see my arguments stomping your talking points and then make up his own mind. i don't care to convince your likes of anything

>>43087 If their patches get accepted, do something about it. I mean, it's not as if kernel's mailing list is not public right? It's Free Software for a reason, if your arguments are better, then the mailing list is gonna listen. It's not like emacs-devel, where RMS sometimes actually does use his dictator's powers.

>>43084 I am not that anon, but afaik >pic 1 https://nitter.net/kai_fall/status/1966158913478566093 This is the only link that isn't 4ch thread. >pic 2 not necessary >pic 3 Some MIT study https://web.archive.org/web/20250818115520/https://nanda.media.mit.edu/ai_report_2025.pdf although, NANDA doesn't host it publicity anymore

>>43046 Anon, at least post the full paragraph, because you are omitting the juicy part

>>43087 >C is getting replaced by rust in linux kernel and other projects Will it last though? History shows that these kinds of large-scale rewrite projects very rarely go anywhere, and even when they do, it takes a long time, and is only possible because project itself is small enough in scope to allow it. The Linux kernel is an absolutely enormous piece of software. If Mozilla hasn't been able to rewrite Firefox in Rust, the task that Rust was designed for, how the fuarrrk do you expect it to work out in the Linux Kernel? >because rust evangelists inject themself in foss projects and steadily push for replacement with rust. These kinds of office politics must, sooner or later, give way to reality. There's a million practical reasons to stick with C over Rust, not the least of which being the sheer amount of Kernel code already written in C. >"its not big yet" is just short-sighted. Go, Typescipt, and Swift were all created around the same time as Rust, and have all managed to carve out their own niches in the programming world. Rust still has yet to do that. We're not talking about an unproven newcomer, we're talking about a language that has existed long enough to be entering puberty. To assume that it will go any further than it already has is to ignore not only the trajectory that the language itself has been on for over a decade, but also to ignore the historical precedence of similar languages like Nim and D which also went nowhere.

>>43096 cont. >>43089 >also typical Rust zealot behavior. I don't see how asking for sources is unreasonable, let alone indicative of Rust zealotry. And I wasn't complaining about the screencap because of its contents; for all I care it could've been a screenshot of someone posting an image of cute cats. Social media is cancer, and you're cancer for further propagating its cultural dominance over the web. >say, you don't happen to be one of them, do you? No. I don't loathe Rust the way you do, but I certainly don't like it. Rust's problem is that it's an attempt to improve on C++ that doesn't really understand why C++ is bad to begin with. Like, if we're just looking at the two languages as lists of features, Rust is obviously the better language of the two. It does away with most of the cruft that C++ has accumulated with time, the footguns, the redundancies, the weird corner cases, and adds a lot of very modern, very high-level things that simply wouldn't be possible if backwards compatibility with C++ were a concern. But taken as a whole, it fails to address C++'s core problem, which is that it's the dictionary definition of a Jack of all spades, master of none. Hell, if anything, Rust is worse than C++ in this regard, because it's a much more opinionated language with a much more deeply integrated set of features, meaning that you can't restrict yourself to a sane subset the way you can C++. For low level programming, Rust's high level abstractions and safety checks add unneeded confusion in regards to how program actually works at a hardware level and unwanted excess overhead. For high level programming, Rust's focus on low level granularity of resource usage makes it needlessly restrictive and confusing. In both cases, you'd be better off picking a language catered to the specific kind of problem you have, not trying to hit every nail with the side of a ratchet.

>>43096 > Go Ew... Wait, maybe I should look at it again, because last time I checked, it didn't even have generics. I heard they added them retroactively, breaking all existing codebases and libraries, like - you now have the whole ecosystem using the old soykafty way without generics, which should be rewritten to use generics...

>>43097 (me) Coming back later, this almost reads like a denouement of multi paradigm languages as a concept, brining us full circle. I'm not sure I would say that I actually am fully opposed to multi paradigm languages, but I will say this: a good programing language is one that minimizes the quantity and complexity of the concepts you need to understand in order to write an idiomatic program in it. Multi paradigm languages don't necessarily run afoul of this; Scheme is both functional and imperative, and it's plenty simple. But in practice, most multi paradigm languages are the result of the same thought process that produced C++; someone looked at two languages (in C++'s case, C and Simula), and thought "I like language A and language B, so language A + B must equal something that's super mega ultra awesome"! and are complete messes as a result. >>43100 Go is not exactly my favorite. It has the same smell that Python and Java do, where if you're used to the low level granularity of C or the high level freedom of Scheme, it doesn't feel like a "real" language. But it gets the job done, and, more importantly, the resulting programs have really good performance.

>>43103 Haskell and Rust also get the job done and have really good performance, but they are also 1000x times better languages, so why would I use Go?

>>43103 > a good programing language is one that minimizes the quantity and complexity of the concepts you need to understand in order to write an idiomatic program in it If you or your collegues are mentally handicapped this must be really important. Go makes sense in this context.

>>43093 > It's Free Software for a reason, if your arguments are better, then the mailing list is gonna listen wait till you find out who the top "contributors" for this "free" software are. lol

>>43097 > asking for sources and calling for murder in the same breath. but ok, whatever >taken as a whole, it fails to address C++'s core problem, which is that it's the dictionary definition of a Jack of all spades, master of none >For low level programming, Rust's high level abstractions and safety checks add unneeded confusion in regards to how program actually works at a hardware level and unwanted excess overhead. For high level programming, Rust's focus on low level granularity of resource usage makes it needlessly restrictive and confusing in principle, no one forces you to use any abstractions. it's just the delusional language "culture" brainwashing users into the idea that these abstractions are "zero-cost". it resulting in exactly what you describe: idiots start to layer them and end up with code whose performance characteristics are hard to reason about. not to mention barring many opportunistic optimizations you can see only if you "read between the lines" of those abstractions. Rust zealots will tell you such optimizations are "bad" because they make things non-orthogonal , but in fact they are a characteristic of stable and mature software the real problem with Rust is that its core premise (using off-brand linear types to manage memory) makes it unusable for general programming. simple as. every other answer is a Rust user trying to muddy the waters

>>43107 >If you or your collegues are mentally handicapped this must be really important. in my experience, mentally deficient people actually tend to favor your view. this isn't really an argument. more of an empirical observations. just because most people who think like you are mentally deficient does not necessarily mean you are mentally deficient. only that you most likely are

>>43111 In my empirical experience, the only people who put simplicity first in priority list are not developing anything more demanding than average job. I can count on fingers actual people I've seen in my life who were not afraid of dealing with anything beyond the "adapter" OOP pattern, and those are the only people who developed anything other than average webservices or average frontends. Simplicity is good, but it's pointless to have it a first priority. There are more than enough general purpose simple languages if you don't have any sophisticated needs. And if you do, there are dozens of more important things you will want first, and only after those are sorted out you might try to make language simple and more consistent.

>>43110 > the real problem with Rust is that its core premise (using off-brand linear types to manage memory) makes it unusable for general programming. This is a common butthurt. Just wrap callbacks in Arc<Box<_>>, boxing those isn't usually a memory/performance issue, and a lot of other stuff isn't as problematic with linear types.

>>43112 >I can count on fingers actual people I've seen in my life who were not afraid of dealing with anything beyond the "adapter" OOP pattern this reflects on you. >OOP pattern this also reflects on you. brown hands typed this post ergo it goes into the trash

>>43113 >just wrap everything in Rc<Arc<Box<Maybe<T>>>> nah, i just did what nearly everyone who's ever tried Rust does: dropped it and moved on to more productive endeavors >a lot of other stuff isn't as problematic >as problematic if this is the hill you have to die on, you already failed. sorry

>>43109 skill issue? I hope you don't use linux then, though I wanna now ask. What is Your setup anon?

>>43116 >skill issue? so it seems. i know the git command to clone the kernel repo, but not the one to clone myself into an army of autists so i could work full-time and outpace the loonix corporate sponsors

>>43117 Then are you using FreeBSD Or something?

>>43118 i'm using armbian, but enough indulging your deflections. which corpo should i join to make my arguing on the mailing list more effective? you have any data on that? you seem to be a mailing list enthusiast

>>43106 Haskell is this nigh incomprehensible fractal of complexity. If someone claims to fully understand that language, they're either an insane freak of nature, or a goddamn liar. As for Rust, I've already made my thoughts on it plenty clear, so I see no need to further labor the point there. >>43107 I already said that I don't particularly love Go. My most used language is, far and away, C. >>43110 >and calling for murder in the same breath. It was a joke. >in principle, no one forces you to use any abstractions. In practice, languages like C++ and especially Rust really, really want you to. Rust's syntax, semantics, and standard library will fight you tooth and nail to get you to do things the "safe" way. As for C++, using a sane subset of it means ignoring so many key C++ features that you'd be better off using C. Abstractions on their own aren't bad; they're perfectly fine if the overhead incurred by them is within the margins of your project's resource usage. In Rust and C++, abstractions are problematic because they introduce a ton of complexity. Having features that do similar things but at different levels of abstraction in the same language means that 1. the language designer needs to make concessions to have both exist at the same time, often introducing even more nonsense to the language in the process, and 2. the programmer needs to spend undue mental bandwith figuring out how all of it fits together. C++, for example, has like 50 different ways to handle memory; C-style std::malloc() and std::free(), new and delete, RAII, and several different kinds of "smart pointers". And you also have to account for how these different forms of memory management interact with other C++ features. For example, if you plan on using exceptions, you're going to want to avoid the lower-level forms of memory management as much as you can because they often don't play well with exceptions.

>>43119 like with emacs-devel (tho there is no much corpo interest there) in order to be actually heard and recognized on any mailing list, you have to be a contributor. I mean, why would anyone listen to a random person? I don't follow lkml nearly as thoroughly, because I prefer other mailing lists, but the good rule of thumb is to provide a patch that addresses the issue and is better. Just stomping in here autisticly screeching NO RUST won't do You much good. Most mailing lists are focused on issues at hand, so it's frowned upon to start an abstract flamewar /unless/ You are a maintainer. >>43120 >Haskell is this nigh incomprehensible fractal of complexity Eh? I am the other anon, but want You to expand on that, because I don't understand this viewpoint. Is it because it forces You to think in term of types or is lazy by default?

>>43121 > in order to be actually heard and recognized on any mailing list, you have to be a contributor who happens to work for one of the corporations that figure prominently in that mailing list, because at this point it's basically just corporate employees talking to each other and if the interests they're affiliated with decide X, you're gonna have a pretty bad time arguing "not X". the more you try to deflect, the more i will remind you about the reality behind your "free software" charade

>>43120 >Abstractions on their own aren't bad; they're perfectly fine if the overhead incurred by them is within the margins of your project's resource usage they are mostly bad in a low-level systems programming context and the overhead they incur is unbounded and eventually becomes impossible to assess. if you had read the post you replied to till the end instead of spazzing out you'd know why you're wrong and why i'm saying this as for the rest of your slop... yeah, non-orthogonal language features bad. incidental complexity bad. C++ is a mess. just the ABCs of programming opinions

>>43122 again, skill issue. If You cared about Your beloved linux, you'd want to do something (as forking was previously mentioned), not accept a defeatist stance and I am angry on Rust or whatever else on imageboard. To illustrate: > those damn CORPORATIONS are taking away my loonix and putting some FAD LANGUAGE IN IT > so I will do absolutely nothing and still use loonix > but I will also be angry about it GCC was written, because some gigautist got angy, that there is no good Free Software compiler. As opposed to You, he understood that we live in free marked economy, and if You don't like something, you gotta shut up and roll Your own.

>>43124 you sure love talking about my skill issues, but you don't see so eager to talk about the fact that your "free software" is absolutely dominated by corporate interests >i do not heckin' accept a defeatist stance so what's your current strategy for amending the situation i'm describing? > we live in free marked economy where do i go to escape the mouth-breathing imbeciles who spew phrases like "free market economy" unironically? please don't say "reddit"

>>43125 Oh, that's because I don't care about it religiously like commies. Also, my "stack" is literally "anything that runs Emacs is good enough". >so what's your current strategy for amending the situation i'm describing? Again, You misunderstand. You have a problem about a thing, I don't have to have a similar problem to suggest you some solutions. >where do i go to escape the mouth-breathing imbeciles who spew phrases like "free market economy" unironically? please don't say "reddit" I mean, "reddit" is a good place for commies like You.

>>43126 >i don't have a problem with my "free" software being dominated by corporate interests ok. then concentrate on licking that boot. make sure you don't take unscheduled breaks to run your mouth about how any contributor can go on the mailing list and change the corporate agenda by making brilliant arguments

>>43128 i guess i was projecting my idealism expecting you to actually keep your mouth busy 100% of the time licking the boot you worship. you're not actually that dedicated to the "free market". but if anyone is getting angry, it's your supervisor

>>43129 I mean, You started with whole "Rust and (((corporate interest))) is destroying My Beloved Child", so I kept to Your level. I got kinda surprised, that You unironically whine at muh corporations, but it is to be determined, if You are an actual communist who got lost or not.

>>43130 >You started with whole "Rust and (((corporate interest))) is destroying My Beloved Child" 1. you actually hallucinated this. the only thing i took issue with is (((your))) lying P.S. that guy who offed charlie kirk? that was probably the first worthwhile thing he did in his life. hopefully more of that to come

>>43131 Did I? Few post earlier You observed that > C is getting replaced by rust in linux kernel and other projects because rust evangelists inject themself in foss projects and steadily push for replacement with rust. Earlier, You said >As a corollary, Rust programmers don't care if they are wasting resources, because agree with the silicon-valley mindset that keeps people getting paid money to churn out code for the sake of keeping up with "updates" that require people to buy new equipment because software is ever more wasteful, and because new versions of ever commercial os require introduce new apis that make proprietary software not run on older equipment, thus feeding this cycle of having to consume endlessly to "keep up" with an industry that's digging itself into near uselessness. I am forced to admit, that I hallucinated Your love for FOSS. At other hand, since Your gripe is with heckin' corpos, I believe it's not far off the mark. As for PS, please explain how it's that even relevant.

>>43132 i said none of those things. you seem to be new to the concept of an imageboard as for "As for PS": i don't know; i figured it's about as relevant as "free market" and "communists" (both of which are about equally real)

>>43134 >i said none of those things. you seem to be new to the concept of an imageboard The number of unique IPs didn't jump up, patterns of posts didn't change and the semantics of an argument are the same, so I figured You are the same guy in that reply chain. Would be nicer if You at least had the courtesy to LARP Him.

>>43135 it would be nicer if you had the courtesy of not doubling down on your errors, white trash

>>43136 I would prefer not to.

when i first came here, i just wanted to talk about why people who think in terms of programming "paradigms" are braindead programmers who don't actually think. but the Rust users and the corporate bootlickers conspired to make me help them derail the thread. very sad

>>43140 There was, as far as I can tell, exactly one Rust programmer in this thread. Even then, he barely qualified; he used it as the output for his vibe coding. I said I disliked Rust, and went into great detail about why, and you refused to believe me because I didn't dislike it the same way you did. You seem to be seriously mentally ill, and I'm really how to reply to you in a way that won't cause you to react the same way you already are.

>>43142 see? you just can't let it go. by the way, calling people "mentally ill" is a Rust antic, especially in combination with threatening to murder people (as you did before)

>>43148 >by the way, calling people "mentally ill" is a Rust antic Is it, or do people just call you mentally ill when you talk about Rust because you are? >especially in combination with threatening to murder people (as you did before) It was a joke. The picture I'm getting is that you're this insane thin skinned glitterboy that can't go outside without having a panic attack. The more you talk, the less I respect you.

>>43157 >people just call you mentally ill talking about yourself as if you're part of some crowd and your opinions are consensus is a Rust cult antic. >The picture I'm getting is... so you're threatening to kill people and now you're hallucinating, too

>>43148 >calling people "mentally ill" >a Rust antic are you perhaps new to imageboards?

>>43159 are you perhaps new to Rust antics?

>>43160 only if one guy keeps trying to paint everything he doesn't like as one

>>43161 right. well, if i'm so new to imageboards, how come i know what a same user is? you didn't think of that, did you, same user?

>>43162 anon, I... I am a guy from yesterday, you know double stops, mailing list enthusiast. Not the other person who dislikes Rust and whom you flamed earlier.

>>43163 >gets called out on talking about himself like he's part of a crowd >drops capitalization and periods, pretending some other poster on this dead board jumped in to side with him on [insert irrelevant bickering] >gets called out on that, too >starts capitalizing and using periods again >pretends nothing happened this is your brain on hormone blockers. fuarrrking embarrassing

>>43164 kek Yes flood detector, I know this is kinda spam

>>43164 Okay, now I think you're just fuarrrking with us.

>>43166 >us is your hivemind in the room with "us" right now?

>>43166 to be honest I believe he just is a schizo and since there is allegedly only one "Rust cultist" here, we are all part of him LARPing

>>43168 This. So much this. Upvoted.

Anyway! Since Lisp family was already mentioned. It's multi-paradigm, but doesn't fall for >how can a language be object oriented AND functional AND procedural? make it make sense!!! I mean, DSLs are a wonderful thing :3. Some could argue that Scheme/CLisp are "functional", but then why `set!` is part of the Scheme standard? I think I am in minority here, but [1] mentions that conundrum. Is lisp OO? Well, CLOS exists. Is it procedural? Kinda, you can easily use infamous LOOP macro in CLISP or for-each in Scheme. Coroutines are just one call/cc away :). But to the point, >you're not getting actual objects, or if you are, then you're not getting proper functional since OO does not mesh with it. Eh, I am itching to mention CLOS again, but we might do something more fun and observe that Clojure (a "functionalish" lisp) can go down to OO or even bytecode (so non-procedural) level [2]. In short, paradigms are a thing, if you are a Blub language. [1] - https://letoverlambda.com/index.cl/guest/chap5.html#sec_1 [2] - https://aphyr.com/posts/341-hexing-the-technical-interview