• Digit@lemmy.wtf
    link
    fedilink
    English
    arrow-up
    2
    ·
    6 days ago

    But, Haskell…, it’s so well thought out, so evolved, the best of all functional programming in one, the ability to handle infinite lists, the lazy evaluation, the strict type checking, the compiler that catches whole classes of bugs, the curt syntax, the ability to breathe it like pure thought, the clarity like maths…

    Okay, sorry, I better leave the room too.

  • AldinTheMage@ttrpg.network
    link
    fedilink
    arrow-up
    0
    ·
    7 days ago

    That’s why we use JavaScript on the front end, JavaScript on the back end, and you can streamline it even more by using JavaScript for the db layer too. After all, if you have too much data to be reasonably parsed in a single .json file, you are probably just architecting wrong.

  • MonkderVierte@lemmy.zip
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    7 days ago

    The programming language promotes a thinking model and the ecosystem defines a modus operandi.
    Of course they matter.

  • Johanno@feddit.org
    link
    fedilink
    arrow-up
    1
    ·
    7 days ago

    The language is as important as architecture and stuff.

    Pick the right language for the right task.

    Performance? Don’t use python.

    Everything else? Use python because everyone does.

    /s

  • AnarchoSnowPlow@midwest.social
    link
    fedilink
    arrow-up
    0
    ·
    7 days ago

    Programming languages, much like the jackass in the middle, are tools. Different tools are for different things. The right tool for the job can make your day. The wrong tool can make you question your entire career.

      • Sasquatch@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        6 days ago

        Embedded? Rust!

        Web Frontend? Rust!

        Web Backend? Rust!

        idk what orher kinds of programming exist…

        • Ephera@lemmy.ml
          link
          fedilink
          English
          arrow-up
          1
          ·
          6 days ago

          That is, like, genuinely an advantage, though. At $ DAYJOB, we have a project that spans embedded, backend, web frontend and CLI, and for all of these, Rust is decent.

          Like, I can see why a frontend dev would want to use HTML+CSS+JS/TS (rather than HTML+CSS+Rust), mainly because the massive ecosystem of JS components makes you more productive.

          But you pretty much won’t ever develop a web frontend without an accompanying backend, and then being able to use the same language-expertise, libraries, utility functions and model types, that is also a big boost to productivity, especially if you won’t have a dedicated frontend dev anyways.

          Realizing that also made me understand why people subject themselves to NodeJS for their backend, which has the same advantage, just with the big ecosystem in the frontend and the small ecosystem in the backend.

        • ZILtoid1991@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          6 days ago

          Game dev? Just force Rust into it, despite being quite mediocre for the job, there’s so many engines written in Rust. ECS is the answer to everything!

          • jasory@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            4 days ago

            “Game dev… Just force Rust into it”

            What’s wrong with Rust for game dev? It seems similar to C++, and C# which are the dominant languages.

            I can see arguments that the current projects have poor approaches, but not that the language itself is ill-suited.

            • ZILtoid1991@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              3 days ago

              Rust has constant by default, which many don’t like in gamedev circles. Yes, compilers don’t care and optimize - at the highest optimization setting, otherwise it’s marginally slower, and each constant use will just add up.

              Other Functional Programming features of Rust makes writing transform functions quite good, until you need to get the results of those functions to be displayed.

              Some of the system-level allocation is quite hard with Rust, if not impossible.

              The borrow checker is hard to use with games, not to mention it has a big impact on performance.

              Object-Oriented Programming is possible through macros, but sometimes you need OOP instead of Entity Component System for more system-level stuff. Sure, ECS is really nice for game systems, but Bevy (an engine written in Rust) uses it for everything.

  • SmokeyDope@piefed.social
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    7 days ago

    I’m only a hobbyist no skin in the game but as an engineer first programmer second I feel like how you design the architecture of your logic and how you choose to prioritize computational optimization or feature implementation have a much bigger impact than language. Obviously theres a time and place like using luajit instead of lua if you really need that speed boost, but in big complex programs I’m willing to bet lazy programmers skip optimization steps and copy paste thousands of lines to ship quickly regardless how performance optimized the underlying language is.

    I make a module that does a specific thing for version 1, after initial bug patches and maybe a feature addition theres usually an epithany that the logic can be generalized into an api type registry structure that allows the code to be reused and configured as needed on per item basis. Along the way you do stuff like ask what the not expensive calls are, add accumulator timers to reduce unneeded CPU usage , ensure early returns are up top when it makes sense, choosing to render a cleverly crafted sprite instead of a full 3d entity.

    A conditional if then logic loop Is a logic loop no matter what Turing complete language its written in. What really matters is how you use the loop not which syntax its written in.

    • Ethan@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      7 days ago

      Any function can be written in any Turing complete programming language. That doesn’t mean a sane person would use malboge or brainfuck for a production system. Language choice can have a huge impact on productivity and maintainability and time is money.

    • expr@piefed.social
      link
      fedilink
      English
      arrow-up
      1
      ·
      7 days ago

      No one actually copy/pastes thousands of lines of code. We use libraries.

      Languages do matter a lot. Yes, they are all technically equivalent, but the craft of software engineering is much, much more about social/cultural/community considerations than it is computational ones. What the community around a programming language values matters, because it informs a great deal about what’s idiomatic in a language, what libraries are available, what kind of bugs are possible (or not), how easy code is to read, comprehend, and maintain, and much more.

      What makes a language good is not what programs you can write in it, but how it constrains what you can do such that you naturally writing good code. For example, null pointer exceptions (or segfaults in C, etc.) are a classic problem that plagues many mainstream languages like Java, C#, Python, etc. In Haskell (and a handful of other languages, including Rust), null pointer exceptions are not possible, because nulls do not exist in these languages. Taking away this language “feature” actually increases the power of the language, because you can guarantee that a certain class of common bugs are not possible in your program. So languages that restrict known bad programming practices lead to programmers writing better programs and, more generally, a community around the language that resonates with these philosophies.

    • Ethan@programming.dev
      link
      fedilink
      English
      arrow-up
      0
      arrow-down
      1
      ·
      7 days ago

      Keep your Rust to yourself. I don’t care what language someone else uses for their projects but Rust is an unreadable mess that I don’t want anywhere near my projects.

      • UnfortunateShort@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        7 days ago

        Rust is an unreadable mess to you because you can’t read it. It has a steep learning curve, but the reward is one of the most reliable and efficient languages ever created.

    • tomenzgg@midwest.social
      link
      fedilink
      English
      arrow-up
      1
      ·
      7 days ago

      Not to stereotype too much but I think this is the first Blåhaj I’ve seen (in a programming context) that wasn’t team Rust.

      What your programming language of choice (if you don’t mind sharing)?

    • BehindTheBarrier@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      7 days ago

      I can actually see where this is coming from, as I found Rust hard to read when I started out. I do really like Rust for reference, but I do agree Rust is hard to read for someone that has not learned it.

      For example:

      return statements that are implicit just because the semicolon isn’t there. Even better if they occur inside a if block or something like that. Very hard to understanding when you don’t know the syntax rules.

      Lambda functions, especially when using move semantics too. They are quite simple, but if you don’t know the meaning, it’s more arcane characters. Especially when this is used inside lots of chained methods, and maybe a multi-line function in the lambda.

      A lot for the if let x =… type of stataments are tough the first time around. Same for match statements.

      Defining types for use with function::<Type>() and such.

      Lifetimes, especially when they are all named a, b, c etc. It quickly gets messy, especially when combined with generics or explicitly defined types.

      Macros, though not entry level rust to begin with, they are really cumbersome to decode.

      None of these are sins of Rust, but for new people they are a hill to climb, and often hard to just “get” based on previous programming experience and reading the code. Rust can be really hard to approach because of these things. This happens in other languages too, but I do feel Rust has a particularly large amount of new concepts or ways to do something. And this is on top of learning lifetimes and borrow semantics.

      • wewbull@feddit.uk
        link
        fedilink
        English
        arrow-up
        0
        ·
        7 days ago

        I think that’s a great set of criticisms.

        None of these are sins of Rust, …

        They might not be strictly language issues, but if they are symptomatic of idiomatic rust then they are “sins of rust”. Something about the language promotes writing it using these kinds of idioms.

        Just like French speakers don’t pronounce 80% of the written syllables because it’s impractical to speak fast with all of them…language features (or lack of them) drive how the language is used.

        (BTW the implicit return behaviour on a missing semicolon sounds like Chekhov’s footgun)

        • 5C5C5C@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          7 days ago

          Something about the language promotes writing it using these kinds of idioms.

          As someone who has used Rust professionally for 3 years, the idioms are good. I wouldn’t want the idioms to go away, and I don’t particularly want the style/aesthetics of the language to change unless it can be done without negatively affecting the idioms.

          It’s not a situation where the aesthetics are actually bad, it’s just different than what most programmers are used to, but almost all of the differences are for pretty good reasons. With enough familiarity and practice you’ll start to recognize those differences as benefits of the language rather than detriments.

          But I think a lot of people have so much inertia about tweaking their way of thinking that they don’t feel motivated to try long enough to make it over that hump, especially when their expectations get set by rabid Rust promoters like myself who insist that Rust is vastly superior to any other languages in almost all situations. The stark contrast between how good they’re told the language is and how they feel when first exposed to it might be too much whiplash for some people.

        • 5C5C5C@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          7 days ago

          Being unable to give an actual example proves you’re just a foaming-mouth hater with nothing to contribute.

          • Lucy :3@feddit.org
            link
            fedilink
            arrow-up
            0
            ·
            7 days ago

            From the first syntax examples on Wikipedia:

            fn main() {
                let foo = 10; 
                // Suddenly, types are implicit now. A safe language should never have implicit types (now it's the (IDEs) implementations judgement which type that is. Combined with the variable shadowing "feature", this seems like a major clusterfuck. Now the IDE is the sole thing to tell you that you totally fucked up the logic, and both declarations/definitions (well which one is it? Would be nice to always have a direct KEYWORD telling you which type this fucking variable has. But no, the lazy piece of shit Rust 'programmer' left that as an exercise to the dear reader. Because in they just need to leave that part out instead of explicitly stating "I'm a lazy piece of shit" by *instead* typing 'auto'.) This is just Python-level BS. Yes, I also hate C++ for its auto keyword - but at least it explicit.
                println!("The value of foo is {foo}");
                let foo = 20;
                println!("The value of foo is {foo}");
            }
            
            fn add_two(x: i32) -> i32 {
            // That is, again, the syntax of Python. Why? Because Python is explicitly untyped. So having types be a *literal* afterthought is Ok. They're fully optional anywhere there. Now we're in Rust. They're sometimes optional, sometimes not, but they're always preferred. Yet, they're also an afterthought, seemingly.
                x + 2
                // Implicit statements are bad. Very bad. They so much invite to glossing over stuff, especially when your brain expects to see something else. Also, having every statement ended with ;, except context blocks, but suddenly *not* having statements ending with ;, is fucking ugly (which is the entire point of this rant). It's completly inconsistent. Which in itself is a huge magnet for errors.
            }
            
            if x > 5 {
            // Now why would you leave the parantheses, which are a major contributor to readability, away. Or even allow this. Rust is just memory safe, like dozens of other mainstream languages, but continues by allowing, promoting and requiring hazardous practices.
                println!("value is greater than five");
            }
            

            Now I’m slowly getting annoyed from typing on phone (at least in nvim), and my throat gets clogged with mucus again.

            Remember, some of that are subjective preferences and opinions. And the core idea of Rust - fast but safe programs - is good, yet very obvious and not innovative at all, while the syntax and implementation (of cargo (yes I like to wait an hour for a simple webapp to compile because there aren’t binary crates and cargo just doesn’t multicore 99% of the time)) is subpar to something that’s hailed as the savior for everyone and everything by such a large cult.

            • calcopiritus@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              7 days ago

              “not having mandatory parenthesis in if statements is hazardous, so I prefer to write C instead of rust, because I really care about safety” < that’s how you sound.

            • 5C5C5C@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              7 days ago

              Types are not implicit, they’re inferred by the compiler when there is no ambiguity about what the type needs to be. This is a huge benefit for refactoring code and reducing maintenance. I acknowledge that sometimes you might care to know the exact type of the variable, and sometimes that’s not as easy for a human to infer as it is for the compiler, but every decent IDE will provide inline type hints for you. Interpreting code by reading it in plaintext is an exercise in masochism.

              Python is actually the opposite on this, and it’s one of Python’s worst characteristics. The type is unknown until runtime unless you annotate it, and then the annotation isn’t really enforced. It’s the worst of every dimension.

              C++11 introduced auto, and now the community is split between “almost always auto” and “never auto”.

              JavaScript needed a whole new compiled language (Typescript) to fix its type system problems, and Typescript is only an incremental improvement at best.

              Rust has the best type system of any modern language by far. If you’re tripped up by not always seeing the type declarations then you’re either focusing on the wrong details in the code or you just need a little more practice. The key thing that needs to sink in for new Rust users is that the compiler is always providing safety rails. That means it’s no longer your job to verify that every aspect of the code is correct. You can relax a little and actually have something akin to duck typing without all the pitfalls that usually come with it.

              • Shanmugha@lemmy.world
                link
                fedilink
                arrow-up
                0
                ·
                7 days ago

                Sorry for intrusion, but mhm, nah. I get it there are people who want to play around and have language/compiler babysit them, but there are also people like me who want to see exactly what something is. So no, Rust, just like JavaScript, can be liked by some people, but it is in no way something that has “best type system”

                There actually is no such thing as best type system, same way there is no such thing as best language

                • [object Object]@lemmy.world
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  7 days ago

                  If you don’t realize that x = 10 denotes an integer of some default length, and that y = 10.0 is a float, then the language isn’t the problem.

                • 5C5C5C@programming.dev
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  7 days ago

                  I get it there are people who want to play around and have language/compiler babysit them, but there are also people like me who want to see exactly what something is.

                  This is a false dichotomy when it comes to Rust. Despite everything I said and despite Lucy’s complaint, there is nothing that actually stops someone from explicitly annotating the exact type when declaring a variable. It’s just not required by the language, and most developers eventually realize that it’s not actually useful.

                  You’re right that these preferences are subjective, be although much of that subjectivity has more to do with how our past experiences have shaped what we’re familiar with, rather than any intrinsic characteristics of person. By that I mean, someone who uses Rust enough will most likely come to like the way the general community styles its code, sooner or later. In the meantime you’re welcome to do things in a way that suits your needs.

                  The only thing that Rust’s type system is weak on is runtime reflection. There are ways to achieve it within Rust’s type system, but it’s considerably more work than what you get in Python and JavaScript. Imo the only reason to choose a language other than Rust for a greenfield project is if you have a strong need for runtime reflection all over the place and aren’t very concerned about performance, threading, or avoiding entire categories of bugs that the Rust compiler protects you from.

      • rtxn@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        8 days ago

        Enums and nested blocks. I understand the importance of Option and Result, but it’s fucking infuriating when I have to check and destructure the result of every function call and either bubble the result up the stack from six levels of nested if let blocks or risk Cloudflaring my program by using .unwrap(). And while I like being able to extract a return value from an if...else expression, the structure gets really convoluted when multiple if and match blocks are nested (of course each one returning a value), and it gets completely fucked once closures are introduced.

        I like Rust, but calling it pretty is delusional.

        • tatterdemalion@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          7 days ago

          Enums are the best part of the Rust language IMO, so I’m not sure how you can view them as ugly. Having the choice to destructure something is fantastic. You generally aren’t required to destructure every return value. Make sure you’re using the ? operator as much as possible. If destructuring is getting in your way, it sounds like the code is not very idiomatic.

          I can’t really comment on your issue with nested if and match. Too much nesting is bad in any language; try extracting more functions and let bindings to make it more readable.

          You can enable a clippy lint to deny .unwrap() if you’re worried about it.

        • SorryQuick@lemmy.ca
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          7 days ago

          You can also use let else.

          let (Some(count\_str), Some(item)) = (it.next(), it.next()) else {
              panic!("Can't segment count item pair: '{s}'");
          };
          

          But really it’s the exact same as other languages, it just forces you to handle it better. C-based languages will return 0/null/-1 and you’ll have to check all 3 of those because they might not mean the same thing. How is that better?

        • marcos@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          8 days ago

          have to check and destructure the result of every function call

          Learn how to use enum error types, how error bubbling works, and how to convert between Options and Results.

          It’s Rust you are talking about, not Go.

          • rtxn@lemmy.world
            link
            fedilink
            arrow-up
            0
            ·
            8 days ago

            This isn’t about some feature of the language being good or bad. It’s about Rust being ugly or not. The things I mentioned will always look ugly in the source code.

            • 5C5C5C@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              7 days ago

              It’s hilarious to me that people talk about “ugly” as if their opinions are objective.

              I found Rust unpleasant to look at for the first two weeks of learning it, and now that I’ve been using it professionally for three years I loathe when I need to read code in other languages.

              No other language can rival Rust in showing the exact information needed to understand the code — never too much and never too little — while being concise, correct, and handling all edge cases.

              You can be more concise in other languages, but it will come the loss of handling every little possible bug. You can be prettier in other languages, but it will come at the price of adding a lot of useless boilerplate.

              Of course there are cases where Rust can be verbose or confusing, but that’s when you’re doing very esoteric things that would be just as confusing in other languages.

              Like any opinion on aesthetics, how someone feels about the prettiness of a language will have far more to do with familiarity than with any objective metrics.

      • Lucy :3@feddit.org
        link
        fedilink
        arrow-up
        0
        arrow-down
        1
        ·
        7 days ago

        Average Rust code:

        macro_rules! sum {
            ( $initial:expr $(, $expr:expr )* $(,)? ) => {
                $initial $(+ $expr)*
            }
        }
        
        fn remove_prefix<'a>(mut original: &'a str, prefix: &str) -> &'a str
        
        let mut up = 1;
            'outer: loop {
        

        This is on the level of the esolang I made at 8 y/o, with random characters denoting random actions everywhere, at random positions.

      • Lucy :3@feddit.org
        link
        fedilink
        arrow-up
        0
        ·
        7 days ago

        Average Rust code:

        macro_rules! sum {
            ( $initial:expr $(, $expr:expr )* $(,)? ) => {
                $initial $(+ $expr)*
            }
        }
        
        fn remove_prefix<'a>(mut original: &'a str, prefix: &str) -> &'a str
        
        let mut up = 1;
            'outer: loop {
        

        Hell I don’t want to know what you define as ugly then.

        • fuck_u_spez_in_particular@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          6 days ago

          Definitely not your average Rust code, more like a very ugly example of it.

          Also, as the syntax first put me off as well, I gave it a chance years afterwards, and have now (or rather years ago) officially joined the church of Rust evangelism.

          A lot of the syntax you define as ugly makes sense when you learn it, it’s just so much more explicit than a more dynamic language, but that exactly saves your ass a lot (it did for me at the very least) (I don’t mean macros, macros are ugly and should be avoided if possible)

          • wewbull@feddit.uk
            link
            fedilink
            English
            arrow-up
            0
            ·
            7 days ago

            What language are they then? They’re not Python, JS, <insert any other language here>

            • calcopiritus@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              7 days ago

              You used macro_rules, which is not common at all. Most rust files don’t contain any macro definition.

              This code doesn’t even compile. There is a random function definition, and then there are loose statements not inside any code block.

              The loop is also annotated, which is not common at all, and when loops are annotated it’s a blessing for readability. Additionally, the loop (+annotation) is indented for some reason.

              And the loop doesn’t contain any codeblock. Just an opening bracket.

              Also, the function definition contains a lifetime annotation. While they are not uncommon, I wouldn’t say the average rust function contains them. Of course their frequency changes a lot depending on context, but in my experience most functions I write/read don’t have lifetime annotations at all.

              Yes, what you wrote somewhat resembles rust. But it is in no way average rust code.

    • Ethan@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      7 days ago

      Almost any language is ok but some ecosystems make me want to turn into a murder hobo (looking at you, JavaScript).

      • fuck_u_spez_in_particular@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        6 days ago

        You can’t imagine how often I just sweared today about js. What did go through the mind of their designers, when they created this growing disease, and why did web browsers accept this as the lingua franca for the web. So… much… pain…

      • Lucy :3@feddit.org
        link
        fedilink
        arrow-up
        0
        ·
        7 days ago

        Also looking at Rust. Yeah, I totally like recompiling thousands of crates for a single webapp single-threaded.

        • WhyJiffie@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          1
          ·
          7 days ago

          well if you are recompiling thousands of crates with a single thread, for a simple webapp no less, then you are doing something wrong. multiple things, actually, I count 3.

      • tyler@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        7 days ago

        List comprehensions are much stranger than tabs vs spaces. There are very very very few languages that use them, and python’s is by far the worst out of the popular ones.

          • tyler@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            6 days ago

            I’m not saying I don’t understand them. I’m saying the syntax is terrible. Compare it to Ruby (or any other modern language) and it’s abundantly clear.

            python (uses syntax not available in any other top 25 language)

            print([j**2 for j in [2, 3, 4, 5]]) # => [4, 9, 16, 25]
            

            ruby (normal chain syntax with map)

            puts [2, 3, 4, 5].map{|j| j**2}
            

            even kotlin is more readable, even though you have to convert to a double and back kotlin

            val list = listOf(1,2,3,4)
            println(list.map{it.toDouble().pow(2.0).toInt()})
            

            For nested cases it’s even more apparent:

            python

            digits = [1, 2, 3]
            chars = ['a', 'b', 'c']    
            print([str(d)+ch for d in digits for ch in chars if d >= 2 if ch == 'a'])    
            # => ['2a', '3a']
            

            ruby

            digits = [1, 2, 3]
            chars = ['a', 'b', 'c']   
            digits.product(chars).select{ |d, ch| d >= 2 && ch == 'a' }.map(&:join)
            

            kotlin

            val digits = listOf(1, 2, 3)
            val chars = listOf('a', 'b', 'c')
            println(digits.flatMap { d ->
                chars.filter { ch -> d >= 2 && ch == 'a' }.map { ch -> "${d}${ch}" }})
            

            just from a base level, you have to read the middle of the comprehension first, then the end, then the beginning. It’s a completely backwards way to write and read code. unlike other languages that use a ‘functional’ approach, where it’s chained methods or pipes, etc. Even Elixir, which does have list comprehensions, reads and writes in the proper order:

            elixir

            for x <- 0..100, x * x > 3, do: x * 2