Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming

'Rust Is Hard, Or: The Misery of Mainstream Programming' (github.io) 123

Posted by msmash from the closer-look dept.
Hirrolot's blog: When you use Rust, it is sometimes outright preposterous how much knowledge of language, and how much of programming ingenuity and curiosity you need in order to accomplish the most trivial things. When you feel particularly desperate, you go to rust/issues and search for a solution for your problem. Suddenly, you find an issue with an explanation that it is theoretically impossible to design your API in this way, owing to some subtle language bug. The issue is Open and dated Apr 5, 2017.

I entered Rust four years ago. To this moment, I co-authored teloxide and dptree, wrote several publications and translated a number of language release announcements. I also managed to write some production code in Rust, and had a chance to speak at one online meetup dedicated to Rust. Still, from time to time I find myself disputing with Rust's borrow checker and type system for no practical reason. Yes, I am no longer stupefied by such errors as cannot return reference to temporary value - over time, I developed multiple heuristic strategies to cope with lifetimes...

But one recent situation has made me to fail ignominiously. [...]
This discussion has been archived. No new comments can be posted.

'Rust Is Hard, Or: The Misery of Mainstream Programming' More

'Rust Is Hard, Or: The Misery of Mainstream Programming'

Comments Filter:

  • What did you say? (Score:4, Interesting)

    by Kremmy ( 793693 ) on Tuesday June 07, 2022 @04:44PM (#62601222)
    You mean that a language designed as a replacement for C inherited literally every problem it was trying to solve?

    • Re:What did you say? (Score:4, Funny)

      by GoTeam ( 5042081 ) on Tuesday June 07, 2022 @04:58PM (#62601256)
      I'm just glad the title "Rust Is Hard, Or: The Misery of Mainstream Programming" wasn't the title of a Rocky & Bullwinkle episode that includes sexual innuendo...
      • Actually just the "What did you say?" is enough, the summary conveys virtually nothing useful except that the author seems to be very angry about something, problems with a programming language by the looks of it.

    • Re:What did you say? (Score:4, Insightful)

      by Tough Love ( 215404 ) on Tuesday June 07, 2022 @05:01PM (#62601264)

      You obviously know nothing about Rust. Rust gets rid of nearly every major issue with C but adds devilishly difficult new problems of its own (object lifetime). Whoever manages to work through maniacally difficult lifetime issues usually ends up loving rust. Or loving and hating at the same time. But I repeat, you know nothing about Rust. Time to learn, because Rust isn't going away.

      • Rust gets rid of nearly every major issue with C but adds devilishly difficult new problems of its own (object lifetime).

        You mean like just about everything that replaces something else. Just sayin' ...

        • No, not very much like that.

          • Re: (Score:2, Informative)

            by Khyber ( 864651 )

            Out of the 30 or so odd languages I've worked with - YES, VERY MUCH LIKE THAT.

            It's all so full of shit that I went back to coding in native assembler.

            • 4F4B424F4F4D4552

            • You may know 30 languages (which I assume is an exaggeration) but you obviously don't know even the superficial basics of Rust or you would not have posted that incorrect nonsense.

              • Re: (Score:2)

                by Khyber ( 864651 )

                I've been doing this shit since TI-BASIC and GW-BASIC, know the fun of PASCAL (and the shit-tier Turbo Pascal) and much, much more.

                Rust fixes some things, and fucks up a bunch of others.

                ASM beats it all. Because ASM can do ANYTHING - if you have a BRAIN, which you seem to not possess.

      • Re:What did you say? (Score:5, Insightful)

        by keltor ( 99721 ) * on Tuesday June 07, 2022 @05:28PM (#62601342)
        Rust mostly just gets rid of two classes of issues in C, in both cases it adds complexity. The issues it address are helpful in dealing with a certain class of security issues. It also brings a community of elitist bike shed painters.

        • Re: (Score:3, Interesting)

          by gweihir ( 88907 )

          Ah, yes, the bike-shed painting idiots. One more reason to ignore Rust.

          • Weighing in on the subject with no knowledge? Thought you were better than that.

            • Re: (Score:3, Informative)

              by gweihir ( 88907 )

              You think I have no knowledge as to the bike-shed color comment by Poul-Henning Kamp? Or why KISS is so important in _all_ secure and reliable engineering? Or why using complex tools when simple ones do the job is the road to hell by non-understanding of what one does, at least as long as we do not use mostly well understood and strongly standardized components in software?

              Or is this simply baseless arrogance of the "You are not an experienced Rust coder, hence you are not allowed to comment on Rust!" varie

              • You know fuck all about Rust and you know that was what I was referring to. What an asshole. No wonder nobody invites you out.

                • Re: (Score:2)

                  by gweihir ( 88907 )

                  You seem to have mental issues, among them an obviously unwarranted vast overestimation of your own skills and insights. Just because you have found a fetish you now pray to does not mean other people lose all rationality too.

                  FYI: Once you have seen the 10th or so magic hype language that promises to fix all problems with coding, you stop believing the crap claimed and start looking at facts. Obviously you have not reached that stage or you may just lacking the skills for it.

                  • I know what I've estimated for your skills in insights: zero. Or more realistically, negative. People who read your comments end up losing IQ points.

        • in both cases it adds complexity

          Not only complexity, but also obscurity. There is an unfortunate and growing tendency for projects of this nature to create their own cutesy names and jargon with, as far as I can tell, the sole purpose of distinguishing the heathens from the initiates - and then to surround themselves with a hinterland of NIH reworkings of established concepts.

          From development "methodologies" through to programming languages we seem to be increasingly in thrall to a panoply of cults for whom the solution to problems ultima

          • Not only complexity, but also obscurity.

            Example please. We know about the lifetime difficulties so try to find a different example.

        • If it's about the type checker, the complexity was always there, Rust just rubs your nose in it and demands an explanation from you in how you're going to deal with it.

          There are other things which add more questionable complexity, though. I was recently made aware of the whichever_compiles macro... which is a joke, to be clear. But it nicely illustrates how Rust, too, can be abused in ways to make Perl or the C preprocessor blush. Maybe that's what it takes to make Slashdot grognards like it.

          • Ah, first person with a clue in the thread. What a relief. You are right about macro_rules, if that is what you are referring to. This is considered to be a temporary hack that will be replaced with something more elegant when the community is satisfied with the new approach. Haven't been keeping up on the progress there but I assume it's progressing. In the mean time you can do some amazing and useful things with macro_rules, with just a tinge of cringe. Minor wart.

      • Re: (Score:2)

        by splutty ( 43475 )

        If someone forces me to use Rust for a project, I'll use it. Otherwise there are pretty much always better programming languages for whatever you're trying to do.

        Rust as a low level language is... A decent idea, I suppose, but the implementation is fucking awful.

      • Re: (Score:1)

        by Anonymous Coward

        Does it ADD object lifetime, or does it REMOVE the ability to ignore race conditions?

      • Re:What did you say? (Score:5, Insightful)

        by Zontar_Thing_From_Ve ( 949321 ) on Tuesday June 07, 2022 @07:47PM (#62601798)

        Time to learn, because Rust isn't going away.

        Well, with all due respect, are you in your twenties? Because Rust indeed will be going away, but what I mean by that and what you mean by that may be slightly different. I will explain below. Short version - Rust isn't going away like Cobol and Fortran aren't going away in that it is still theoretically possible to use them.

        Here's what's going to happen. In about 10 years, somebody who is a punk kid now, maybe a tween or in his early teens, is going to decide that Rust is crap because __. Whatever the reason, it really doesn't matter. He's going to write something that will be "better" than Rust and "fix all of Rust's problems". And all your buddies are going to jump ship and start using that as soon as they can and it's possible that you will too and you will laugh and say "What was I thinking in believing that Rust was perfect?" And then 10 or so years after Rust's replacement comes out, it too will be replaced with "something better". Sorry kid, but I'm old enough to have seen this story more times than I care to count.

        • I'm skeptical about this TBF.

          For most languages sure, that happens a lot. But ultimately, we're talking about C++.

          For 25 years, I've seen many many many languages come along attempting to replace C++. Sometimes they manage for one domain, but yet I'm still using C++. In all cases they fail because they don't actually do what C++ does and cannot replace it for a whole host of tasks.

          The only one I've seen so far where the creators actually understand what C++ can do and what domains it spans and then adds som

          • Re:What did you say? (Score:4, Interesting)

            by Walking The Walk ( 1003312 ) on Wednesday June 08, 2022 @10:15AM (#62603516)

            For 25 years, I've seen many many many languages come along attempting to replace C++. Sometimes they manage for one domain, but yet I'm still using C++. In all cases they fail because they don't actually do what C++ does and cannot replace it for a whole host of tasks. ... ... The only one I've seen so far where the creators actually understand what C++ can do and what domains it spans and then adds something substantially new is Rust. Without comment on whether rust is any good or will replace C++, that's one actual credible replacement.

            Aren't you just validating the poster's position? He or she posited a 10 year cycle, let's see how close we are: C++ was standardized in 1998, 24 years ago. Then in 2010 along comes Rust, so that's 12 years later. Here we are 12 years after Rust, we're right on schedule for a replacement. It's easy to say right now that none of the replacements will dislodge C++ and Rust, yet who's to predict which of the new languages will take off?

            My own self-reflective experience was dotNet. I looked at it when 1.0 and 1.1 came out and laughed. Later when my dotNet dev friends gushed about the CLR and generics and some other features, the devs for other languages like Java rolled their eyes as they'd had those features for years. Yet when I picked it up around v 3.5 of the framework I realized it had matured to the point where it was better than a lot of the alternatives for some of my tasks. I rolled my eyes at Node.js, "Javascript is for the browser!", Python "It's slow and I can mess up my code by indenting wrong!", React "Why do I want a server layer on the client?", etc. They've grown and improved and found their niches, to the point now where I don't even question whether vue is better, or why we're pulling out JQuery, or whether EventHubs in Azure is better than Kafka in AWS. I just learn enough of the new thing to understand what it can and can't do, put it in my toolbox, and follow the standard of whatever group I'm working with.

            • I think your timeline is a bit off. C++ dates from the early 1980s, but became what we think of as C++ later. By the time it was standardised in 1998 it was already very well established and widely used. Rust hasn't reached that stage yet, neither is it standardised.

              C to what's recognisably C++ took about 20 years. C++ to Rust took about 20 years. Perhaps from a sample of 2 there'll be another big shift in another 10 years.

        • That is not going to be what happens. What will happen is that in 20 years, someone will come up with something new cool that solves a bunch of hard problems (and opens up some new ones).

          And then the OP is going to go to whatever is the outdated tech discussion site in 20 years, and make a smarmy post like yours.

          • Bingo. BTW, core Rust devs are in favor of obsoleting Rust with something that does what Rust does but handles, e.g., object lifetime more elegantly. Nothing on the horizon at the moment, but who know.

            The most likely successor to Rust will be Rust, with an evolved approach to object ownership.

      • Or loving and hating at the same time. But I repeat, you know nothing about Raku. Time to learn, because Raku isn't going away.

        Well said.

      • You obviously know nothing about Rust.

        That's the main issue. Hardly anyone does. Getting to know Rust is tricky.

        You have a relatively immature language with no formal definition that does all kinds of weird, cranky stuff "because it's good for you", and any time people complain that things don't make sense, the fanatics quickly retort with, "You just don't get it."

        I very quickly picked up on the preachy, political vibe of the community and told myself, "That's all I need to know. For now, I'll pass."

        • Well I'm not preachy or political, but I do have zero tolerance for entitled assholes loving the smell of their own shit on the internet. And by that I do not mean you.

          I'm also not a member of the Rust community per se, I'm a user and I understand why there is no better tool for many mission critical projects. And yeah, I hate certain things about Rust and even the Rust community but I'm not such a fucking idiot that I wallow in my delicate sensibilities instead of getting on with creating technology in th

        • You obviously know nothing about Rust.

          That's the main issue. Hardly anyone does. Getting to know Rust is tricky.

          Absolutely. In my case it took about two weeks of intense work. On the scale from zero to ten of things that are difficult in life, that's about a 2. But even so, it's too much for 99% of the devs out there.

          Then it took about 2-3 months of actual regular use to be fluent. On the whole, just a fraction of the time it took me to become a c++ expert, and to be frank I still don't feel I really know c++. Rvalue references anyone? Just for starters. So yeah, c++ is an impossibly difficult language but I still d

      • Re: (Score:2)

        by lsllll ( 830002 )
        Out of 104 comments at the moment, you have made 18 of them and almost every one of them is trying to rebuke the parent or insult it. It almost looks like you think you're right no matter what.

        • Nothing to see there, there are just so many rebukable idiots posting trash. You being one of them. Waddle off now.

      • ... Rust isn't going away.

        Not true!

        Google for "rust removal" and you'll find all sorts of ways to make it go away. At least for a while. It takes constant vigilance to keep it away.

        (For the record, I think Rust has valid uses cases. But for me, it's a painful solution to problems that don't bother me all that much. The cure is worse than the disease.)

    • Nah, it fixed the problems it was trying to, but created entirely different problems. With C, you can do just about anything. With Rust, it's hard to do even simple things. It's like RUST is the exact opposite of C.

      • Re: (Score:2)

        by kmoser ( 1469707 )
        Clearly the perfect solution is to write in a mixture of Rust and C, using each language's strengths. The resulting code will therefore be easy to write, read, and maintain, right? Right?

        • Re: (Score:3)

          by hAckz0r ( 989977 )
          That's why the language has the "unsafe" keyword. Specifically so you can do all kinds of stupid things(tm) and still feel good about it working (kind-of). Well at least then you can tell everyone you program in Rust. Or that the program is "safe" because its written in Rust.

          • You can write safe functions with unsafe code and sometimes you have to. Rust does a nice job of making it convenient to do this. Obviously, you need to know what you're doing writing the unsafe code. If you do it with taste you end up with something nice and robust, and hopefully efficient to enjoy at a higher level.

        • Clearly the perfect solution is to write in a mixture of Rust and C, using each language's strengths. The resulting code will therefore be easy to write, read, and maintain, right? Right?

          Or ... you can use a single language that has both, ie. C++.

        • Yeah, but what you almost certainly would get is the mixture of Rust and C using each other's weaknesses. Given the aim of this approach seems to be circumventing Rust's borrow-checker, this is using Rust without the safety! Might as well just code in Javascript, so much more convenient...

  • Summary (Score:5, Insightful)

    by enriquevagu ( 1026480 ) on Tuesday June 07, 2022 @04:47PM (#62601234)

    Dear Slashdot Editors,

    Could you please make the summaries, well, summaries?

    Copying the two first paragraph of a blog post, which do not even specify clearly the content of the post, is NOT a summary. It could be an introduction, but a good summary squeezes the main ideas of the article into a small number of paragraphs.

    In this particular case, the article was not very clear, but there are some clarifications at the end. The most relevant one is this:

    Rust is ill-suited for generic async programming, this is the gross true. When you enter async, you observe that many other language features suddenly break down: references, closures, type system, to name a few. From the perspective of language design, this manifests a failure to design an orthogonal language [^]. I wanted to convey this observation in my post; I should have stated this explicitly.

    • I appreciate you digging up that actually summary, this part makes me wonder:

      Rust is ill-suited for generic async programming, this is the gross true.

      I thought people loved Rust for server programming which is wholly asynchronous, so why does this person think it's ill-suited for the task?

      • Asynchronous can involve multiplexing, multi threading, multi process, signal based or some combination of the above. Who knows which one hes referring to.

        • Re: (Score:3)

          by Tailhook ( 98486 )

          He is referring to combining Rust's async/await with Rust's generic types within the Rust programming language. What is being awaited isn't relevant and could be any of the various forms of 'asynchronous' you mentioned.

          I have to agree with his conclusion. I dove deeply into Rust asynchronous programming around the time Tokio was reaching 1.0. I got it and was happy with it, but that work didn't involve generics much. Since then I've watched Rust experience a combinatorial explosion of complexity as th

          • Possibly because enterprise Java frameworks do most of the nasty stuff for the programmers. Dependency injections, task scheduling, inter-task communication, all that middleware stuff.

            Sure, they may have to write a lot of boilerplate, but its boilerplate that avoids the nasty stuff.

            In some ways, it's the reason why COBOL has lasted so long. Because most of the time, COBOL programs run in CICS, which is the mainframe equivalent of enterprise Java, but for native programs.

          • Java is taking a different road. Having somehow (?) thrived all of this time without a tier 1 asynchronous programming story in the core language/runtime, Project Loom is delivering an interesting solution. OS scheduled threads are becoming runtime scheduled micro-threads transparently. The straightforward (apparently, given the number of work-a-day programmers that seem to be able to cope with it) programming model of concurrent Java is not changing, so Java programmers won't have to deal with async/await. Yet scalability to millions of 'threads' will be possible.

            This sounds a lot like what go does with fibers under the hood for you.

      • Re: (Score:2)

        by jythie ( 914043 )
        I've met a lot of people who's idea of 'server programming' involves micro services with one blocking thread each and something external managing all the little apps.

  • Life Cycle of Programming Languages (Score:5, Insightful)

    by UnknownSoldier ( 67820 ) on Tuesday June 07, 2022 @05:02PM (#62601272)

    Life cycle of programming languages:

    1. Some amateur programmer is too undisciplined to learn how to use an existing language well and work around its pitfalls. They want their pet syntactic sugar feature so they invent Yet-Another-Language -- we'll call it Fad X.
    2. Fad X programming language is announced publicly but is mostly ignored.
    3. It picks up momentum as it has rapid development of new features. It has a surge of popularity as everyone jumps on the bandwagon of its (yet undelivered) promises.
    4. Eventually Fad X gets abandoned and people go back to their old battle-tested languages as people realize all the old problems are STILL there in Fad X. It is half-baked, ends up being over-engineering / complicated, and tries to be a "Silver Bullet" solving some problems and ignoring all the other ones - the ones that actually matter. You are lucky if you get a working Profiler, let alone Debugger. People get tired of waiting for breadth and depth on libraries and good, correct documentation.
    5. Some new SHINY Fad Y programming promises to fix all the old problems of language X. This time it will be different! All the Fad X diehards remain in denial that their pet language is dying or dead and has problems.
    6. Rinse-and-repeat every 10 to 20 years. /s

    --

    Diablo Immoral = Diablo 3.5, now with Cain and monetized to hell.

    • Re: (Score:1)

      by Anonymous Coward

      That's why I still write all my code in FORTRAN. With computed GOTO.

    • Re: (Score:2)

      by jythie ( 914043 )
      Well, as the saying goes, In the long run every program becomes rococo - then rubble... programming language are no exception.

    • Re: (Score:2)

      by Jeremi ( 14640 )

      and tries to be a "Silver Bullet" solving some problems and ignoring all the other ones - the ones that actually matter.

      A fun tautology there -- the remaining problems are by definition the ones that actually matter, precisely because they remain unsolved and therefore still require programmers' attention. Everybody forgets about the solved problems as quickly as they possibly can, to free up brain-space for the unsolved ones.

    • 1. Some amateur programmer is too undisciplined to learn how to use an existing language well and work around its pitfalls.

      Ah yes, the well known undisciplined amateur programmer Graydon Hoare.

      But maybe one day it will be possible to debug and profile Rust programs!

      I hope I will never be such an advanced programmer as you - the kind who are sure they learned everything worth knowing 25 years ago.

  • Wait ... (Score:4, Interesting)

    by fahrbot-bot ( 874524 ) on Tuesday June 07, 2022 @05:04PM (#62601278)

    'Rust Is Hard, Or: The Misery of Mainstream Programming'

    Rust is mainstream now?

    • Well when someone only interacts with other devs who only use a specific, niche language, it is pretty easy to fall into the trap of thinking that the language they are using is mainstream because they've found some camaraderie.

      Rust is mainstream like NodeJS is mainstream. NodeJS has less than 2% marketshare globally. Rust has 0.01% marketshare. Thus Rust is even less "mainstream" than NodeJS by a factor of ~200. For comparison, C++ still holds 23% marketshare. (Disclaimer: Percentages here are from a

  • The "Example" Problem (Score:5, Insightful)

    by Octorian ( 14086 ) on Tuesday June 07, 2022 @05:18PM (#62601312) Homepage

    This reminds me of something I often end up running into whenever using some hyped/popular new development environment. I basically call it "The Example Problem."

    Basically, it posits that because examples and tutorials are all written against contrived problems, it is possible to have complete books and websites chock full of these examples and tutorials that never touch on things you're going to run into during the FIRST FIVE MINUTES of trying to write a real world application with the system.

    Part of that is because its really easy to follow the clean success path, and to come up with ever more clever ways of implementing it. However, real systems aren't hard because of the success path. They're hard because of all the failure paths and corner cases you need to handle in addition to it. And finding elegant ways of handling those is often quite a challenge. If your code base devolves into a ball of mud full of cross-cutting code that shouldn't be touching each other, its often in a frantic effort to deal with these things.

    • Agree... But programming languages (and associated programming approaches) that emphasize modularity can provide some significant assistance for that. One of the mistakes (IMHO) made by most object-oriented languages is expecting that classes are sufficient/the best way to organize programs. There are some languages that provide program modularity independent of the class hierarchy. Additionally, languages that emphasize strongly typed interfaces (ESPECIALLY for scalars, where it's really easy to make m

    • I think of this as the bubble problem. Often, the people designing languages or frameworks are working for huge megacorp X and doing so is their entire job. They never work on "real" problems, and rarely ever speak to developers outside their corporate bubble. So, as you said, what they end up building is targeted towards demo cases and also hugely influenced by internal politics rather than general need.

      I've been an active part of the C#/.NET open-source community since they went open-source in 2013 and th

  • Hard soft ware (Score:3)

    by kackle ( 910159 ) on Tuesday June 07, 2022 @05:24PM (#62601326)
    The problem I find with "hard" programming languages is that few people become experts at them. That means eventually we're dealing with a lot of code that is not as well done as one would hope and/or the language all but fades away. I'd say we need more "experts", not less.

  • Not to mention.... (Score:5, Funny)

    by sconeu ( 64226 ) on Tuesday June 07, 2022 @05:24PM (#62601330) Homepage Journal

    Suspending a process is impossible, because we all know that Rust Never Sleeps.

  • programming tradeoffs (Score:5, Insightful)

    by david.emery ( 127135 ) on Tuesday June 07, 2022 @05:30PM (#62601352)

    Particularly in the context of concurrent programming, I'm reminded of a discussion from 35 years ago: "Would you rather write simple programs in a complex language, or complex programs in a simple language?" Now I have a personal bias, but I recognize that both approaches have their advocates and their arguments in favor/in opposition.

  • So calling it mainstream these days is a bit of a stretch. System languages are intended for building ... you're not gonna believe this ... systems. Complaining that Rust is hard for mainstream problems is a bit like complaining that Webapps built with C++ are a little rigid and hard to debug.

    To emphasize: Rust is a wonderful PL but if you're using it for anything else than systems, embedded or real time critical daemons you're using it wrong. Using Rust for websoftware is a really dumb idea for instance. So don't do it.

  • Oh please, grow up. Back in the 80's when I learned C, do you think that was easy? I had one book "The C Programming Language" that was it. But I learned c. How about in the late 60's when I learned FORTRAN via punch cards? Do you think that was easy? The problem is not the learning of the language, the problem is that anyone thinks they can learn to program in a language. Language programing requires certain skills. Not everyone may have those skill innately. Yes, to learn those skills may not be

  • Short Love Affair with Rust (Score:4, Interesting)

    by Slicker ( 102588 ) on Tuesday June 07, 2022 @08:55PM (#62601994)

    My love affair with Rust was short. The goofy error handling bothered me at first (and still) but the devil does live in the details.

    On the other hand, there's a lot to like about Go Lang. I am writing something in Go, right now. You have to be willing to change your philosophy on how errors are dealt with, among other things but it's very clean and neat. I do have some pet peevs it hits, like ":=" syntax but I like the concepts.

    Personally--and I know few will agree, I would prefer a language that smoothed out the rough edges leaving as little nuance as possible for me to work out. That is, no mandatory strict typing and flexible reflective data structures. I think a mix of Go and JavaScript would be ideal. That is, allow strict typing but don't mandate it. Provide flexible reflect data structures. Destroy memory holding things when the last reference to it is removed. Auto-convert data types for me, where possible.

    Provide prototype object-orientation (not classical) but, better than JavaScript, make the prototypes cascade. Also better than Node.js, have a when( condition ) { code } for concurrency without losing data scope on return--boom, suddenly very clear, simple, and efficient asynchrony.

    Also provide something like the Date.js library for dates/times--dates/times suck in every language, even though it's so important. However, Date.js makes it easy. I'd also add a Money library for accurately dealing with different currencies--calculations based on the the lowest unit, e.g. pennies (for US dollar), while also being aware of the other denominations. And one more important library is for high level support of complex data structures. For example, sorts, compares, etc. of deep data, such as arrays of objects. Also, effectively joins and queries from sections of or all of a data structure. I would also implement a half-cache, whereby data structures could be partly in memory and partly in slower storage (e.g. disk/network). It should be possible to work with unlimited sized data structures.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      I think Go and Lua would be a better mix. In fact Lua should have been used as Javascript in the first place. It's very similar except Lua is more stable, solid, easier, smaller, faster*, and rationally designed. Lua has a simple object structure that exists throughout the entire language.

      * I just wish they would fix hash tables in Lua. It's ironic that it's THE core feature of the entire language yet when you start dealing with lots of string data in Lua it bogs down.

      As far as Rust. It's been tried a milli

    • Re: (Score:3)

      by Tom ( 822 )

      Similar story here - still like the idea behind Rust. Solving a bunch of big problems at the language level definitely is the better approach than hoping coders will avoid them through - gasp - knowing how to actually write code. But for the last project, I went with Go and I like that unlike most "modern" languages you can actually READ the code without a degree in hieroglyphics. The idea that code should be its own best documentation got lost somewhere when people thought that {()=>[]*} was somehow coo

      • Re: (Score:3)

        by dyfet ( 154716 )

        Indeed, this is my main issue with rust; poor syntax and expression. It is really a declarative language (think about let and unifications) falsely, and hence, confusingly, represented in imperative syntax. This makes it much harder to correctly read and debug. And then you have disjunctive syntax with decorators used for should be core language features like traits, and bizzare idiocy, like who, in their right mind, thought it was a good idea to use the presence or absence of a ; at the end of a statement

    • Big fan of Go here. 5 years ago I started a new job which required me to develop a machine telemetry system from the ground up (including the hardware, I'm primarily an electronics and embedded software engineer). The hardware and embedded software were no problem, but I also needed to develop a server / website for the machines to send the data to, and our customers to be able to view the telemetry data on.

      I looked at Node.Js, PHP, Rust and Go.

      PHP seemed a bit old and getting a bit obsolete.
      Rust just

  • The idea being a language that really works things out thoroughly rather than wallpapering over bugs until everything comes crashing down. Seems intuitive that you would have to work harder for such a thing, but the benefits sound nice. Purely amateur opinion though.

  • When you do real programming, then you need a lot of mental resources.
    When you program by copyhpasting code from a forum without understanding, then you are monkey typing. Which in my opinion is not real programming.

    Ymmv.

    • Re: (Score:2)

      by nagora ( 177841 )

      The point of high-level languages is to take some of that mental load off, not to increase it. That leaves the question, of course, of whether Rust is a high-level language.

  • Rust Prevents Procrastination (Score:3)

    by allquixotic ( 1659805 ) on Wednesday June 08, 2022 @01:59PM (#62604258)

    Python, Ruby, and other scripting languages let you procrastinate completely, because they have absolutely no requirements before you can ship code that attempts to run. So you can literally ship syntax errors in prod.

    Compiled languages with dynamic types at least prevent you from producing a running binary with syntax errors, or a few major language-related errors, so they catch a small percentage of bugs in the compiler before you can ship to prod. But any typing, object lifetime, or multithreading issues are yours to keep.

    Compiled languages with static types additionally prevent you from shipping most (but not all) type mismatch related errors. If the language doesn't support automatic conversion between given types, and you try to pass in a type that isn't allowed, you can't produce a working program. So it forces you to understand your data types before you can ship. This defeats a lot of would-be procrastination, but still not all of it.

    Rust goes much further than your typical compiled language, even, by forcing you to decide on object lifecycle. This is either left up to the programmer in languages like C, varies depending on the API in C++, or is garbage collected in languages like Go, Java and C#, so you take a performance hit in exchange for procrastination about (not having to think about) object lifecycles when writing your code. It also has a very strict type system, and furthermore knows when you're committing a multithreading sin that will corrupt your data or crash your program.

    Rust also makes you think about error handling and possible data inputs, and handle each possibility explicitly. At least, well-designed Rust APIs do -- there are some, especially those that are just C bindings, that have poor error handling that's left up to the user (what do we do if the exit code is negative, 0, or positive?)

    To make a correct program that doesn't crash, everything has to work, no matter what language you're in. But Rust just makes you think about and solve ALL of your problems up-front, before it's willing to produce a binary that executes. One of the only types of problems that can still exist in a Rust program that successfully compiles (without the unsafe keyword) is logic errors; that is, your program does something that doesn't meet your requirements. Example of a logic error: you are implementing an addition function, but accidentally use the subtraction operator. It's not doing what you expect, not because of any language problem, typing problem, etc., but because your requirement is for addition, but you used substraction. No programming language can possibly catch that.

    I, like many others who have used Rust a bit, continue to be amazed by how, more often than not, a Rust program that compiles is usually 1 to 2 builds away from running correctly, performantly, and without any known bugs. This is less true if you have a lot of dependencies on hardware, device drivers, or C APIs from the operating system.

    If most/all of your program is just native Rust code moving data around in memory with CPU instructions -- which is the crux of computing -- there is a very good chance that a compiling program does everything you want it to do, unless your code has logic errors.

    Other common pitfalls of coding involve misunderstanding design contracts between systems (like when designing or consuming a network protocol or an on-disk format, or talking to hardware like a GPU). Because Rust takes a while to build a working binary (both in terms of compile time, and getting it correct), I would say that it makes sense to pull out I/O-heavy pieces of code and write it in a more forgiving language that can kind of "figure out what you mean" (even if you're committing programming sins) while you figure out things like API design contracts and what Vulkan APIs you should be calling to use the GPU correctly.

    Once you get it all figured out in Python or Ruby or JS or C#, you can then harden the performance and correctness of your program by porting all your code to Ru

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close