Any alternative to C++?

Hello LULZ. Is there any alternative to C++, that still has OOP and classes, while not having separate source and header files, and with perhaps a bit cleaner syntax, especially for the templates?

  1. 1 month ago
    Anonymous

    yes

    • 1 month ago
      Anonymous

      which one?

  2. 1 month ago
    Anonymous

    >having separate source and header
    How is this a problem? How do you feel about c++20 modules?

    • 1 month ago
      Anonymous

      It gets annoying quickly when you have to add a method to an existing class and have to edit two files. Or when you edit the function signature. It just seems much more clean to just have one file. I would love a C++ with java package system if that is possible.
      >C++20 modules
      AFAIK that is experimental and my compiler does not support c++20 yet. I tried building it from source, but it couldn't find some libraries or something. The distro provided g++ supports at most C++11 afaik. That's debian for you. Might have to dual boot with fedora or arch to get the newest compiler and try 20 out, it it isn't experimental

      • 1 month ago
        Anonymous

        >C++ with java package system if that is possible.
        You've just described C#

        • 1 month ago
          Anonymous

          C# is a higher level language tho. I meant that literally, not just syntactically

    • 1 month ago
      Anonymous

      It gets annoying quickly when you have to add a method to an existing class and have to edit two files. Or when you edit the function signature. It just seems much more clean to just have one file. I would love a C++ with java package system if that is possible.
      >C++20 modules
      AFAIK that is experimental and my compiler does not support c++20 yet. I tried building it from source, but it couldn't find some libraries or something. The distro provided g++ supports at most C++11 afaik. That's debian for you. Might have to dual boot with fedora or arch to get the newest compiler and try 20 out, it it isn't experimental

      literally just do header only, what's the problem?

      • 1 month ago
        Anonymous

        >literally just do header only, what's the problem?
        Circular dependency

        • 1 month ago
          Anonymous

          >what are include guards?
          >what is forward declaration?

          • 1 month ago
            Anonymous

            You cannot do forward declaration in header only.
            You would need to do
            class A;

            and declare pointers to A in the class B in B.h, then include A.h in B.cpp.

      • 1 month ago
        Anonymous

        compile times blow up. Add template as well and you will spend >10s

  3. 1 month ago
    Anonymous

    In terms of direct replacement, D probably.
    https://dlang.org/

    • 1 month ago
      Anonymous

      I see that it uses GC by default and most libraries use GC as well. But it is still faster than java right? Is it about as fast as Go?

      • 1 month ago
        Anonymous

        It depends how you use it. If you heavily rely on the GC you will see some slowdown, but Code that is equivalent to C++ should be similarly fast. Idiomatic D is to rely on stack allocation
        Most Benchmarks I know of score it somewhere in the middle between go and C++ if you use the stdlib and not use raw pointers heavily
        https://github.com/frol/completely-unscientific-benchmarks/blob/baeadaac61807f0049ad35b9282b0c27eeb6d104/README.md

  4. 1 month ago
    Anonymous

    yeah, beeflang fits this description

    • 1 month ago
      Anonymous

      In terms of direct replacement, D probably.
      https://dlang.org/

      I am checking these two out. thanks!
      Keep em coming tho

      • 1 month ago
        Anonymous

        though, beef doesn't have template meta programming, it sports generics, comptime evaluation, mixins, code generation & comptime/runtime reflection which all together effectively amount to the same thing

  5. 1 month ago
    Anonymous

    D is good, Beef is for gamedev iirc, and then you have all the new memelangs like Zig, Nim etc. Or Rust if you care a lot about memory safety.

    Honestly what are you gonna use it for, why not just use C#/Java/Go? Do you want to manage memory yourself?

    • 1 month ago
      Anonymous

      >and then you have all the new memelangs like Zig, Nim etc. Or Rust if you care a lot about memory safety.
      None of these have classes however. I worked with OOP programming languages for about 4 years and while I can see the appeal of rust, I am not willing to entirely change my ways of thinking about a program just to use these. I have tried using rust for game development, but I got frustrated when I could not avoid the error I got "SDL_Texture cannot be shared between threads safely", which I did not care about really, because I knew that my game will run on a single thread, and passing the texture array to every render call seemed like a stretch. Otherwise I also worked with C, so I technically could use langs without OOP just fine, but I prefer C++.
      >Honestly what are you gonna use it for, why not just use C#/Java/Go? Do you want to manage memory yourself?
      I already am using these. I use Python as my preferred scripting language, Java and C# as my preferred middle ground languages and C++ as my preferred low level language. So I was wondering if there was anything better. So far it seems like D, or C++20 might be the best options

      • 1 month ago
        Anonymous

        >"SDL_Texture cannot be shared between threads safely"
        I dont know any rust at all, but if you need to use something that cannot be shared between threads safely either make it single threaded or use unsafe

        >C++20
        Module support in 2 more weeks

        • 1 month ago
          Anonymous

          Well you see, by making it unsafe, I would have to make nearly all rendering code unsafe and therefore the scene class and the game loop class and the main class unsafe as well. thread_local! requires unsafe as well afaik.

      • 1 month ago
        Anonymous

        I am interested in knowing what types you were using that lead you to being forced to have to worry if SDL_Texture was thread safe, there are usually types that don't implement the Sync trait for example to avoid things like this.

        • 1 month ago
          Anonymous

          The SDL_Texture itself is not thread safe. Normally the way I would do it in C++ is create a resource manager class and then either make all methods static, use a singleton pattern, or create a global of said class in a namespace. I don't remember which is the one I did in rust, but I did have a statically accessible hashmap of String -> SDL_Texture, I believe

      • 1 month ago
        Anonymous

        Just wrap it with a mutex? Classes are pretty much the same as structs in Rust. The only difference is that they only allow one level of inheritance. Which isn't bad

      • 1 month ago
        Anonymous

        Nothing in SDL is thread safe. If you were trying to thread it in C++, you were going to get a crash eventually, the compiler just isn’t smart enough to tell you, whereas the rust one is

        • 1 month ago
          Anonymous

          Okay, but I know for a fact that my simple 2d game will be singlethreaded when it comes to drawing (literally which games have more than one threads for drawing???), so there should be a better way to do this other than #[unsafe] blocks everywhere

    • 1 month ago
      Anonymous

      well, it's designed with high level ergonomics as well as lower level granularity to make it suitable both for gameplay & engine development - that said, it's not bloated with things that are only relevant to game devs

  6. 1 month ago
    Anonymous

    Rust

    • 1 month ago
      Anonymous

      >Hello LULZ. Is there any alternative to C++, that still has OOP and classes
      >that still has OOP and classes
      >OOP and classes
      >Rust
      ????????????

      • 1 month ago
        Anonymous

        https://doc.rust-lang.org/book/ch17-00-oop.html

        • 1 month ago
          Anonymous

          >If a language must have inheritance to be an object-oriented language, then Rust is not one.
          Sounds clear cut to me.

        • 1 month ago
          Anonymous

          Rust lacks inheritance, which while abused many times, it is still a viable feature and allows code sharing.
          Rust also lacks proper encapsulation, access modifiers work on module level, but not on the struct level.

          In the end Rust is not an OOP language, though it still allows to do 80% of what you need OOP for.

          • 1 month ago
            Anonymous

            The other 20% is gui dev apparently.
            https://www.areweguiyet.com/
            Without complex and deep inheritance it is hard to make a good gui library. Gui is one of those things where inheritance > composition, which is why rust is bad at it

            • 1 month ago
              Anonymous

              >Without complex and deep inheritance it is hard to make a good gui library
              Why the hell do you think that?

              • 1 month ago
                Anonymous

                Because elements have a hierarchical structure. Seriously, look at GTK for example.
                >Object < Widget < TextWidget < TextBox < RichTextBox < CodeEditor
                One example of gui library structure I have personally seen.

                no reason why inheritance is necessary for GUI development. If anything the way traits function make much more sense for making an extensible GUI than the rigidity and unnecessary complexity OOP introduces.

                >If anything the way traits function make much more sense for making an extensible GUI than the rigidity and unnecessary complexity OOP introduces.
                Then why is there no real GUI library in rust, just bindings to already existing stuff?
                In all these years, Rustaceans are still expected to do the GUI in a webshit way which would void any sort of performance gain from Rust

              • 1 month ago
                Anonymous

                >Then why is there no real GUI library in rust
                https://github.com/iced-rs/iced
                https://github.com/emilk/egui
                https://github.com/imgui-rs/imgui-rs
                >inb4 these are not real GUIs
                Rust is still a relatively new language as are its packages, and projects like these show promise towards their future development and that Rust is perfectly capable in creating GUI libraries.
                >Rustaceans are still expected to do the GUI in a webshit way
                What the fuck are you actually even on about

              • 1 month ago
                Anonymous

                >Rust is still a relatively new language as are its packages, and projects like these show promise towards their future development and that Rust is perfectly capable in creating GUI libraries.
                It's 8 years old at this point, isn't it?
                >What the fuck are you actually even on about
                >Current approaches to building GUIs in Rust include interfacing with Electron and building GUIs with HTML (or a framework on top of it), while others have taken to using graphics APIs and various wrappers to emulate classical widgets. The cross platform parallel rendering engine Webrender, built for Servo and usable in Firefox Nightly, takes this latter approach and is multi-platform, but is more of a base for a GUI framework than one in itself.
                So there are apparently classical widget libraries, but they don't even deserve to be mentioned

              • 1 month ago
                Anonymous

                Gtk was released in 1998 and C was released in 1972, so what was your point again?
                Why does this even matter? Do you think new projects challenging existing established ones are supposed to happen as soon as a language is released?
                >Current approaches to building GUIs in Rust include interfacing with Electron...
                Are you just going to ignore the GUI libraries I posted that don't do any of that? Where are you even quoting this from anyway? The ones I posted either let you target directX or wgpu which lets you target Vulkan among other backends like metal or directx.

              • 1 month ago
                Anonymous

                Okay, but this is for games. Generally the general purpose ui should use either win32 api, or whatever the linux equivalent is. Software rendering anyway. Because computers that are more than 6 years old perform worse with opengl than software, at least in my experience

              • 1 month ago
                Anonymous

                I don't see where these are restricted to games, you're going to have to show me an example of something that you'd think would be impossible to implement with Rust's GUI libraries AND is fundamentally unimplementable because Rust does not support inheritance (same thing with C which made libraries like GTK)

              • 1 month ago
                Anonymous

                Maybe they arent, but the fact that you mentioned Vulkan made me think so. So these are basically Dear ImGui for Rust? Well, it is something so thank you for this

              • 1 month ago
                Anonymous

                >GTK
                Written in C, which lacks inheritance.
                Instead the hierarchy you describe is forced into the toolkit, because GTK was created in a time when OOP and inheritance were considered "cool" and "good".

              • 1 month ago
                Anonymous

                >Instead the hierarchy you describe is forced into the toolkit
                So it does have it!
                Anyhow, you still haven't proved that inheritance would be "bad" for gui, nor provided an alternative approach which would be better and easier to code

              • 1 month ago
                Anonymous

                I am convinced you don't actually understand what inheritance is, otherwise you'd understand that just because there is a hierarchy like you posted for GTK (written in C that doesn't support inheritance) doesn't actually mean that it's utilizing inheritance in an OOP sense.

              • 1 month ago
                Anonymous

                It does, because inheritance allows you to take elements of the parents and extending them
                >Object < Widget < TextWidget < TextBox < RichTextBox < CodeEditor

              • 1 month ago
                Anonymous

                show me an example of how this would look in C (not C++), either with this example or something simpler if you like. It has to respect the properties of inheritance of OOP.

              • 1 month ago
                Anonymous

                Well C doesn't support OOP out of the box, so you need to emulate it like GTK does. It's not perfect, but that's what you get for stuffing shit into a language that is not built for it.
                Or you can take win32 approach, where you register classes and then use class name as string in argument of CreateWindowA

              • 1 month ago
                Anonymous

                >you still haven't proved that inheritance would be "bad" for gui
                No one said that. I asked why you think it's apparently necessary for gui.
                >an alternative approach which would be better and easier to code
                In terms of API usability, there's the declarative approach, which is fairly easy to use without the need for a widget hierarchy at all.

                It does, because inheritance allows you to take elements of the parents and extending them
                >Object < Widget < TextWidget < TextBox < RichTextBox < CodeEditor

                What if you want to create a widget that would need to be extended from two unrelated types?
                Say, a WYSIWYG editor that can itself contain both rich text, images, and other widgets.
                How does that fit into your neat little hierarchy?

              • 1 month ago
                Anonymous

                >What if you want to create a widget that would need to be extended from two unrelated types?
                >Say, a WYSIWYG editor that can itself contain both rich text, images, and other widgets.
                >How does that fit into your neat little hierarchy?
                C++ can extend multiple classes

              • 1 month ago
                Anonymous

                >Written in C, which lacks inheritance
                Sadly it's not true.

              • 1 month ago
                Anonymous

                The absolute state of OOP apologists. Your UI doesn't need to be OOP, look at elms UI model

            • 1 month ago
              Anonymous

              no reason why inheritance is necessary for GUI development. If anything the way traits function make much more sense for making an extensible GUI than the rigidity and unnecessary complexity OOP introduces.

            • 1 month ago
              Anonymous

              I'm literally making a simple gui library in rust right now. (pic rel)

              >Without complex and deep inheritance it is hard to make a good gui library.

              Strongly disagree. OOP patterns is not a limiting factor for how good a GUI library is.

              • 1 month ago
                Anonymous

                OK, but will your gui library ever get to a scale of GTK/Swing/Win32?

              • 1 month ago
                Anonymous

                literally a school project/hobby and you are comparing to enterprise solutions

              • 1 month ago
                Anonymous

                I know I know, but the point is that while it is indeed possible to do widgets and ui without OOP and inheritance, it is easier to do so with, which is why almost all well known enterprise solutions do so

              • 1 month ago
                Anonymous

                if win32 api/gtk managed to do it with pure c, then it is possible to do it in a rust way, which is similar to c+haskell

                im dumb and replied to myself

              • 1 month ago
                Anonymous

                It's not easier or better either way, OOP was only picked because it was hip at the time when UI frameworks and toolkits came out

              • 1 month ago
                Anonymous

                if win32 api/gtk managed to do it with pure c, then it is possible to do it in a rust way, which is similar to c+haskell

              • 1 month ago
                Anonymous

                What's the graphics API?

                Whenever I see people building libraries on Rust, they do on top of C/C++ tools. It's extremely rare to see work that's 100% Rust and half the reason I haven't adopted the language(the other half being tranny drama).

              • 1 month ago
                Anonymous

                >they do on top of C/C++ tools
                Yeah no shit. At some point you're probably gonna link to a c-lib regardless, espeically on linux. Who the fuck is gonna sit down rewrite shit like xlib?

                Not me, that's who.

                Anyway, for graphics i'm just using opengl(for desktop) and webgl for browser.

                For windowing the crate i use conditionally compiles between two windowing crates:
                -glutin
                -rust-sdl2

                for the web browser I use:
                wasm-bindgen

                >waited the entire webum for the n-word (nagger)

                fuck you anon. go back to Rreddit

                Not my problem. Seekbar exists for a reason.

              • 1 month ago
                Anonymous

                >waited the entire webum for the n-word (nagger)

                fuck you anon. go back to Rreddit

  7. 1 month ago
    Anonymous

    Try Odin

  8. 1 month ago
    Anonymous

    There's the botnet's new language, explicitly designed to be C++ "but nicer".

  9. 1 month ago
    Anonymous

    >Hello LULZ. Is there any alternative to C++, that still has OOP and classes, while not having separate source and header files, and with perhaps a bit cleaner syntax, especially for the templates?
    Yes, there is! Common Lisp!

  10. 1 month ago
    Anonymous

    If you just want OOP and no header files, then Java or C# should be fine.

  11. 1 month ago
    Anonymous

    I'm not sure why you are obsessed with header-only anyways. It's a terrible way to do things. It just means you have to recompile everything which includes that header every single time you make any changes to the code definitions inside. If you have the declaration in the header and the definition in a separate source file, then you can make changes that source file and not have to recompile anything other than that 1 file.
    Plus, having the header basically serve a double function as an easily human-readable description of the API is really quite nice. I won't even attempt to try to learn someone else's project if they dump everything in one giant header. Retards like that should neck themselves. I can kinda understand it as a method of distribution which caters to retards who are too stupid to figure out how to compile a source file, but that's about it.

  12. 1 month ago
    Anonymous

    Nim

  13. 1 month ago
    Anonymous

    >not having separate source and header files
    you just lost the ability to load C libraries natively.
    just use rust.

  14. 1 month ago
    Anonymous

    You want Java. Java is C++ done right. Only downside, it isn't compiled down to your language.

    • 1 month ago
      Anonymous

      C# is java done right

      • 1 month ago
        Anonymous

        You want Java. Java is C++ done right. Only downside, it isn't compiled down to your language.

        This is the day when Sir Nagoor Babu and the German Microsoft Employee clash!!!

        • 1 month ago
          Anonymous

          Sorry the Java guy is the German in this case.

          • 1 month ago
            Anonymous

            But there are rumors of a fat german microsoft shill ...

            • 1 month ago
              Anonymous

              Doesn't wonder me. The company which I am working for does also shill for MS and C#. I am currently doing C++, but I like Java the most of the three. Java is nicely designed in comparison to C++ and C#. Both are just bloated.

  15. 1 month ago
    Anonymous

    Alternatives Golang for sure, Dlang,C# and kotlin.

    Rust has a really good module system and has the best tooling OOTB that i've ever used,however, its not really and OOP language. Its way more procedural than C++ and has no inheritence, no classes, and a very limited kind of polymorphism (trait objects/dynamic dispatch).

    • 1 month ago
      Anonymous

      D is really good, it's like natively compiled Java with C mixed in

      • 1 month ago
        Anonymous

        Is there any significant piece of software written in D? It's like 23 years old already lol

        • 1 month ago
          Anonymous

          Serpent OS's package manager and other tools as well as the video game Quantum Break. Thats about it. IMO its good, it just doesn't have a league of shills like Rust.

          • 1 month ago
            Anonymous

            A failed lang

  16. 1 month ago
    Anonymous

    C#

  17. 1 month ago
    Anonymous

    tard OP what lang did you pick?

    • 1 month ago
      Anonymous

      looking into D right now

      • 1 month ago
        Anonymous

        >meme dead lang

  18. 1 month ago
    Anonymous

    Rust

  19. 1 month ago
    Anonymous

    >perhaps a bit cleaner syntax, especially for the templates?
    The only way you're likely to achieve those is by "C" wizardry ( and they'll be a fucking mess regardless of the implementation ).
    Not sure of your use case but have you thought about a single translation unit and ditching templates?

  20. 1 month ago
    Anonymous

    what kind of homosexual uses a white background in 2022? seriously fucking kill yourself

  21. 1 month ago
    Anonymous

    Cross platform are pretty tricky to make. For some reason Foliate, which is built on GTK, doesn't work on Windows.

    >https://github.com/redox-os/orbtk

  22. 1 month ago
    Anonymous

    nim

  23. 1 month ago
    Anonymous

    The GUI situation is an interesting one.

    I am slowly coming to the conclusion, that GUI programming is really a different animal as compared to the rest of the application.

    Most software systems interact with other software systems. For instance, your backend server makes use of file services provided by the OS, of network services, of perhaps computational libraries to offload heavy compute jobs. All of these interfaces have one thing in common, which is that they have very tightly constrained surfaces.

    But the GUI is unique, in that the "interface" it communicates with is the human. and this is the source of all problems. The notion of "elegant" programming essentially means, that the program handles all the possible outcomes of whatever API it consumes, without any extra bloat. With system-provided API's, this is possible thanks to the small surface area of the system.
    But with the human "API", the surface area of inputs is very very large, and very quickly becomes unconstrained. The human is fully asynchronous, random-input machine that can click, do keyboard input, move the mouse, press any combination of buttons at any point, and worst of all all of this happens continuously as time moves forward. And not only "time" is a variable, but "time durations" are variables too: You have to respect the human reaction time of ~80ms, if you blink a window, it must know how long to blink - not too long, not too short, and maybe you want to show a tooltip too - perhaps the tooltip should come from the UI element that the user clicked - oh and if its on the edge of the screen, it should automatically re-adjust itself, etc, etc.

    so really, I don't think its possible to provide a GUI library with statically-typed languages practically. they will either be extremely convoluted, and will never be flexible enough except for the most simple apps. The other option (the most difficult, but solves the problem) is to roll a bespoke GUI framework specifically for your app.

    • 1 month ago
      Anonymous

      Just create a template, stylesheets, and events. Ez. Webshit solved GUI, it just needs that someone would implement these ideas without a browser in the middle.

      • 1 month ago
        Anonymous

        javascript is good, but for complex apps the HTML and CSS becomes a major bottleneck.

        for simple apps, it definitely kills stuff like Qt and Java, simply because the barrier to entry and the friction is lower. but semantically, the classic desktop frameworks are just as powerful as the HTML layout engine (even a little bit more.)

        • 1 month ago
          Anonymous

          Java GUIs suck. You have to make your own classes and inherit from the GUI library to modify stuff.

          HTML is declarative, and CSS makes it super easy to style, and the relationship between these elements becomes much clearer and easier to see too.

          You don't even have to use JavaScript. Just port these ideas to your own language. All these JS frameworks try to implement mainly a few ideas. Reactivity, creating your own html tagscomponents, and state management which usually uses some central state store

          • 1 month ago
            Anonymous

            >and the relationship between these elements becomes much clearer and easier to see too.
            no, i disagree. this is where it gets *harder*, and you have to use, as you correctly said, "state management which usually uses some central state store".

            when one component wants to talk to another, it essentially pushes that message to the "top" of the tree (updates the central store), and the central store then ends up basically being one massive switch-case statement that dispatches that event to some element down the hierarchy. your app is still shoe-horned into a hierarchy.

            • 1 month ago
              Anonymous

              It's more flexible. Stores aren't that complicated. Plus, I don't think that traditional OOP would be easier clearer to work with on big apps. How do they even manage shared state?

          • 1 month ago
            Anonymous

            >Satan digits
            >Java GUIs suck. You have to make your own classes and inherit from the GUI library to modify stuff.
            That's how it should be done. Compare that to GTK

    • 1 month ago
      Anonymous

      i hit the word limit, but i wanted to add some more thoughts.

      the common theme with GUI programming, is that you essentially end up with a "many-to-many" relationship, vs. the tree-like structure of relationships that typical systems programs often fit inside of.

      A good example of a tree-like code structure: parsers and lexers. There is very clear encapsulation of responsibility, and you can reach a near-perfect elegance (ofcourse, it gets complicated if you want niceties like correcting errors mid-stream and continuing to parse, etc.)

      With GUIs, you end up with these dense, many-to-many relationships, that aren't really constrained in any obvious way, between all your different functional elements. e.g., you may have a paint program, with mutiple canvases, multiple different filters (and live previews for them), tooltips, etc. and they all have to be synced to their source data. some of those widgets live inside the parent window, some are independent windows, and they also need to stay out of the users way while still providing information. its a ton of heuristics with no discernable "rule" of how GUIs should be done, because the API interface (the squishy human) doesn't have any rules itself! what is a good effective workflow is 100% experimentation based.

      so I think for GUI programming, its unsurprising that javascript has taken off, because its very dynamic nature hold you to no inherent structure. it readily lends itself to spaghetti-code, which is just a pejorative for many-to-many relationships that is inherent in GUI interfaces.

      so I think, in the end, GUI is really its own animal that needs its own language. I would seek to "containerize" the GUI logic, sort of how electron does it, and have the GUI then make calls to the "backend" for resources.

  24. 1 month ago
    Anonymous

    Racket

  25. 1 month ago
    Anonymous

    you could do this in C/C++ already just by using macros and the preprocessor.

  26. 1 month ago
    Anonymous

    Dlang. Its Carbon before Carbon but actually good.

  27. 1 month ago
    Anonymous

    no

  28. 1 month ago
    Anonymous

    >I want to draw UML diagrams and think about class hierarchies all day instead of actually coding stuff
    >...and when I finally code stuff, my class hierarchy becomes a hot-fixed mess anyway

    I don't get you, OP. You complain about having to declare and define in two different files sometimes but you will happily re-arrange your class structure all day long when you realize expressing a motorcycle as a car with only one seat wasn't as clever as you thought in the first place.

    • 1 month ago
      Anonymous

      Nah I don't do that. I don't work in corporate and I never plan ahead for longer than 30 minutes. I also never draw class diagrams lmao. I just imagine a functionality and if it involves some initialization and data bound to a datatype I use class

  29. 1 month ago
    Anonymous

    Unironically? Free Pascal.

    • 1 month ago
      Anonymous

      this

      • 1 month ago
        Anonymous

        Why

  30. 1 month ago
    Anonymous

    Common Lisp, unironically.

  31. 1 month ago
    Anonymous

    Use the grownups language, aka Forth

  32. 1 month ago
    Anonymous

    Nim

  33. 1 month ago
    Anonymous

    node-fortran

  34. 1 month ago
    Anonymous

    > Alternative to C++
    Literally almost any language that came after it.

  35. 1 month ago
    Anonymous

    what exactly you do need OOP for?

Your email address will not be published.