Any alternative to C++?

Hello IQfy. 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?

Beware Cat Shirt $21.68

Rise, Grind, Banana Find Shirt $21.68

Beware Cat Shirt $21.68

  1. 2 years ago
    Anonymous

    yes

    • 2 years ago
      Anonymous

      which one?

  2. 2 years ago
    Anonymous

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

    • 2 years 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

      • 2 years ago
        Anonymous

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

        • 2 years ago
          Anonymous

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

    • 2 years 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?

      • 2 years ago
        Anonymous

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

        • 2 years ago
          Anonymous

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

          • 2 years 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.

      • 2 years ago
        Anonymous

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

  3. 2 years ago
    Anonymous

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

    • 2 years 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?

      • 2 years 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. 2 years ago
    Anonymous

    yeah, beeflang fits this description

    • 2 years ago
      Anonymous

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

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

      • 2 years 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. 2 years 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?

    • 2 years 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

      • 2 years 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

        • 2 years 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.

      • 2 years 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.

        • 2 years 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

      • 2 years 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

      • 2 years 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

        • 2 years 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

    • 2 years 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. 2 years ago
    Anonymous

    Rust

    • 2 years ago
      Anonymous

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

      • 2 years ago
        Anonymous

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

        • 2 years ago
          Anonymous

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

        • 2 years 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.

          • 2 years 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

          • 2 years ago
            Anonymous

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

          • 2 years 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

          • 2 years 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 frick are you actually even on about

          • 2 years 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 frick 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

          • 2 years 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.

          • 2 years 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

          • 2 years 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)

          • 2 years 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

          • 2 years 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".

          • 2 years 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

          • 2 years 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.

          • 2 years ago
            Anonymous

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

          • 2 years 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.

          • 2 years 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

          • 2 years 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?

          • 2 years 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

          • 2 years ago
            Anonymous

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

          • 2 years ago
            Anonymous

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

          • 2 years 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.

          • 2 years 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.

          • 2 years ago
            Anonymous

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

          • 2 years ago
            Anonymous

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

          • 2 years 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

          • 2 years 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

          • 2 years 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

          • 2 years 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

          • 2 years 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 troony drama).

          • 2 years 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 frick 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 (Black person)

            frick you anon. go back to Rreddit

            Not my problem. Seekbar exists for a reason.

          • 2 years ago
            Anonymous

            >waited the entire webum for the n-word (Black person)

            frick you anon. go back to Rreddit

  7. 2 years ago
    Anonymous

    Try Odin

  8. 2 years ago
    Anonymous

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

  9. 2 years ago
    Anonymous

    >Hello IQfy. 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. 2 years ago
    Anonymous

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

  11. 2 years 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. morons like that should neck themselves. I can kinda understand it as a method of distribution which caters to morons who are too stupid to figure out how to compile a source file, but that's about it.

  12. 2 years ago
    Anonymous

    Nim

  13. 2 years ago
    Anonymous

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

  14. 2 years ago
    Anonymous

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

    • 2 years ago
      Anonymous

      C# is java done right

      • 2 years 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!!!

        • 2 years ago
          Anonymous

          Sorry the Java guy is the German in this case.

          • 2 years ago
            Anonymous

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

          • 2 years 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. 2 years 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).

    • 2 years ago
      Anonymous

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

      • 2 years ago
        Anonymous

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

        • 2 years 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.

          • 2 years ago
            Anonymous

            A failed lang

  16. 2 years ago
    Anonymous

    C#

  17. 2 years ago
    Anonymous

    tard OP what lang did you pick?

    • 2 years ago
      Anonymous

      looking into D right now

      • 2 years ago
        Anonymous

        >meme dead lang

  18. 2 years ago
    Anonymous

    Rust

  19. 2 years 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 fricking mess regardless of the implementation ).
    Not sure of your use case but have you thought about a single translation unit and ditching templates?

  20. 2 years ago
    Anonymous

    what kind of homosexual uses a white background in 2022? seriously fricking have a nice day

  21. 2 years 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. 2 years ago
    Anonymous

    nim

  23. 2 years 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.

    • 2 years 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.

      • 2 years 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.)

        • 2 years 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

          • 2 years 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.

          • 2 years 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?

          • 2 years 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

    • 2 years 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. 2 years ago
    Anonymous

    Racket

  25. 2 years ago
    Anonymous

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

  26. 2 years ago
    Anonymous

    Dlang. Its Carbon before Carbon but actually good.

  27. 2 years ago
    Anonymous

    no

  28. 2 years 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.

    • 2 years 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. 2 years ago
    Anonymous

    Unironically? Free Pascal.

    • 2 years ago
      Anonymous

      this

      • 2 years ago
        Anonymous

        Why

  30. 2 years ago
    Anonymous

    Common Lisp, unironically.

  31. 2 years ago
    Anonymous

    Use the grownups language, aka Forth

  32. 2 years ago
    Anonymous

    Nim

  33. 2 years ago
    Anonymous

    node-fortran

  34. 2 years ago
    Anonymous

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

  35. 2 years ago
    Anonymous

    what exactly you do need OOP for?

Your email address will not be published. Required fields are marked *