Rust Creator Graydon Hoare Says Current Software Development Practices Terrify Him (twitter.com) 353
An anonymous reader writes:
On Monday Graydon Hoare, the original creator of the Rust programming language, posted some memories on Twitter. "25 years ago I got a job at a computer bookstore. We were allowed to borrow and read the books; so I read through all the language books, especially those with animals on the covers. 10 years ago I had a little language of my own printing hello world." And Monday he was posting a picture of O'Reilly Media's first edition of their new 622-page book Programming Rust: Fast, Safe Systems Development. Then he elaborated to his followers about what happened in between.
"I made a prototype, then my employer threw millions of dollars at it and hired dozens of researchers and programmers (and tireless interns, hi!) and a giant community of thousands of volunteers showed up and _then_ the book arrived. (After Jim and Jason wrote it and like a dozen people reviewed it and a dozen others edited it and an army of managers coordinated it and PLEASE DESIST IN THINKING THINGS ARE MADE BY SINGLE PEOPLE IT IS A VERY UNHEALTHY MYTH)." He writes that the nostaglic series of tweets was inspired because "I was just like a little tickled at the circle-of-life feeling of it all, reminiscing about sitting in a bookstore wondering if I'd ever get to work on cool stuff like this."
One Twitter user then asked him if Rust was about dragging C++ hackers halfway to ML, to which Hoare replied "Not dragging, more like throwing C/C++ folks (including myself) a life raft wrt. safety... Basically I've an anxious, pessimist personality; most systems I try to build are a reflection of how terrifying software-as-it-is-made feels to me. I'm seeking peace and security amid a nightmare of chaos. I want to help programmers sleep well, worry less."
"I made a prototype, then my employer threw millions of dollars at it and hired dozens of researchers and programmers (and tireless interns, hi!) and a giant community of thousands of volunteers showed up and _then_ the book arrived. (After Jim and Jason wrote it and like a dozen people reviewed it and a dozen others edited it and an army of managers coordinated it and PLEASE DESIST IN THINKING THINGS ARE MADE BY SINGLE PEOPLE IT IS A VERY UNHEALTHY MYTH)." He writes that the nostaglic series of tweets was inspired because "I was just like a little tickled at the circle-of-life feeling of it all, reminiscing about sitting in a bookstore wondering if I'd ever get to work on cool stuff like this."
One Twitter user then asked him if Rust was about dragging C++ hackers halfway to ML, to which Hoare replied "Not dragging, more like throwing C/C++ folks (including myself) a life raft wrt. safety... Basically I've an anxious, pessimist personality; most systems I try to build are a reflection of how terrifying software-as-it-is-made feels to me. I'm seeking peace and security amid a nightmare of chaos. I want to help programmers sleep well, worry less."
ML is a language, not "machine learning". (Score:4, Informative)
Don't know enough about programming languages to recognise a reference to the ML language, even in a tweet that also describes some of its features? Just elide the references you dont understand and replace ML with "machine learning" and you too can be a Slashdot submitter! Don't worry, there are no editors checking that your summary reflects the contents of your links.
Re:ML is a language, not "machine learning". (Score:4, Informative)
ML means Meta Language
Rust: a programming lang with a toxic community (Score:3, Interesting)
What the fuck is Rust? Never heard.
Rust is a relatively new programming language.
I looked into using it a little while ago. On the surface it sounded appealing. It sounded like it would give me a lot of what C++ offers, but without some of the headaches that C++ suffers from.
To keep a long story short, Rust, as a language, did not meet my expectations. The syntax is C-like, but it's also quirky in some ways. The performance was mediocre. The borrow-checking approach to memory management is a pain in the bottom in practice, even after you und
Re:Rust: a programming lang with a toxic community (Score:5, Informative)
Something that I find disturbing is that I actually saw this exact comment before. Why are you copy-pasting this over and over again?
Re: (Score:3)
Something that I find disturbing is that I actually saw this exact comment before. Why are you copy-pasting this over and over again?
I also had this felling and, just in case anyone doubts you: here [slashdot.org] is other instance of that exact comment.
Re: (Score:3)
If the only way to learn a language is by depending on a small group, then that language is either way too complicated or not enough common. You don't depend on ISO to learn C++, you don't depend on Guido to learn Python.
Re:Rust: a programming lang with a toxic community (Score:4, Informative)
If the only way to learn a language is by depending on a small group, then that language is either way too complicated or not enough common.
Kind of a Catch 22 there. If the language didn't support complex powerful features, it would be too simplistic. If it had too much in common with existing languages, it would be derivative and have no reason to exist.
New programming language design is hard, it's painful, it's iterative, and it's thankless. Even though I will not be using Rust for any deployed code for at least the next 10 years, I'm glad people are investing time in it.
Re: (Score:3)
There is a freely available rust book, nobody is going to check your politics before you try reading it. I don't understand, that's how many people learned C or other languages, why is Rust different? Are you saying that whenever someone asks about Rust in stackoverflow he must first show confirmation that he is not a republican?
Re:Rust: a programming lang with a toxic community (Score:5, Insightful)
Re: (Score:3)
Of course, but with thought crimes ever expanding, and the Party Line changing from day to day, it's very easy to inadvertently commit crimes in the eyes of SJWs.
As many people can attest, like Pax Dickinson as one of the most extreme examples. And Curtis "Moldbug" Yarvin, one of the prime instigators in deplatforming him from Strange Loop was none other than "I want a (viole
Re: (Score:3)
Hacker News comment threads are far, far better than Slashdot comment threads. This site has been a complete dump for over a decade now.
Slashdot comment threads are mostly obvious trolling. HN, on the other hand, is Dunning-Kruger central.
What constitutes "better" in this case is a matter of taste, and I wouldn't judge anyone who came to a different conclusion than I do on this one. HN is certainly more civil, for example. But I think that there is something far worse than an extremely stupid person, and that's someone who thinks the extremely stupid person is very smart.
That is why I find the HN comment section worse than the Slashdot comm
Re: (Score:3)
Sadly, his comment is in line with stuff I've seen in the wild. Not *exclusively*, mind. I'm sure there's plenty of normal Rust coders, but it doesn't take a particularly large coterie of insufferable douchenozzles to leave an impression that is really difficult to overcome (in part because, at least for that coterie and those who accommodate them, it's a true impression.)
Re: (Score:3)
SJW is a term coined by SJWs themselves [...]
Nope, not even close.
I think you're thinking of the term "PC", which was indeed coined as a joke by the PC crowd.
"Social Justice Warrior" is a term that arose on Tumblr and Livejournal to describe a certain kind of keyboard warrior (related to what we used to call "flame warrior"). Here's the definition on Urban Dictionary:
A pejorative term for an individual who repeatedly and vehemently engages in arguments on social justice on the Internet, often in a shallow or not well-thought-out way, for the purpose o
Re: (Score:3)
I know, comparing languages to libraries, but have you ever interacted with the ffmpeg/libav developers? I did a little in the 2010-2013 timeframe, they were a challenging lot to deal with.
A lot of the technical shortcomings of Rust might be overlooked based on your opening statement: "Rust is a relatively new programming language." - but, with an exclusive (in a bad way) community behind it, I don't think it will be going far - languages are not like comprehensive video conversion libraries, there are too
Re:Rust: a programming lang with a toxic community (Score:5, Funny)
To keep a long story short
Wow - I'd hate to see your long ones!.
Re:Rust: a programming lang with a toxic community (Score:4, Informative)
I went back to C++, because even if it isn't a perfect language, at least it's a decent language with a honest, open, friendly community.
C++ is arguably the most complicated, the hardest to learn, general purpose programming language in use today. And, in the last seven years, with the last three major revisions, C++ has become, I would estimate, three or four times harder than it was before. If you were to start from ground zero, it would take you much longer than 2-3 years in order to be fully versed in all the arkane features of it. I would say that to become fully proficient in C++, when starting from absolutely nothing more than general knowledge of computer programming, will take at least 5-7 years, maybe even ten.
Because of that, experienced C++ developers tend to be older, and with many many years of experience under their belt. They've outgrown the phase of their lives where they think themselves to be #1 hot-shit masters of the universe. We're older now. We know better.
Re: Rust: a programming lang with a toxic communit (Score:3)
C++ is used for more complicated stuff, on average, than Perl or JavaScript, so you end up feeling like you don't know what you're doing when you jump into the deep end on a C++ project. Again, on average.
Re: (Score:3)
I had no idea. One google search seems to confirm the identity politics approach to defining a language, and I can't think of many more things that would make me distrust a *programming language* more:
https://internals.rust-lang.or... [rust-lang.org]
"Reading this team announcement was really disappointing and I can only agree with what @skade already said. This needs no be fixed before everyone just gets used to it being a male-only team."
Re: (Score:3)
That's actually kind of arguable. OG Marxism said that people's primary identity was from class rather than race or gender.
Modern Identity politics says the opposite. So it doesn't matter if Mummy and Daddy paid for you to get a useless Ivy League degree after a well funded gap year [quickmeme.com], so long as you are part of, or at least claim to be part, of an oppressed group - non white, non male or non straight - you're part of the new proletariat. Conversely a working class straight white man is a part of the evil opp
Re: (Score:3)
If you test at all you recognize your fallibility. If you are fallible then your tools should make bugs less likely to have severe consequences. The only way your thinking could be consistent is if you removed the testing part. If you are convinced you can do it first time perfect without testing, then better languages to be able to consistently express constraints and guarantee them are not necessary ... you are, so they are.
Instead you convince yourself that your tests, which we both know will not have ha
Re: (Score:2)
Re: ML is a language, not "machine learning". (Score:2)
Re:ML is a language, not "machine learning". (Score:5, Interesting)
I've seen it all. DevOps guys who can't deploy kubernetes, build a docker container or setup a decent CI pipeline. Software Engineers that still can't master the to fundamentals of Object Orientation after decades of practice. They have no hope learning ML or functional programming. Typesafe languages are viewed by senior technical leadership as cute academic stuff with absolutely no practical purpose.
At this point, I'll probably join a startup just to get away from charlatans.
Re: (Score:2)
> Software Engineers that still can't master the to fundamentals of Object Orientation after decades of practice.
Worse is junior (or senior programmer) who loves to throw "design patterns", "object oriented programming", "MVC", ... at problems without having a grasp of basic Software Engineering concepts such as separation of concerns or modularity (too many think OOP implies modularity). The result is a heaping monolith of layers of unreadable, unreadable code.
Re: (Score:2)
>The result is a heaping monolith of layers of unreadable, unreadable code.
And for some reason, those same engineers get pats on the back and promotions as they construct their labyrinths of code only they can decipher as everyone who is actually sane screams "We must rewrite it from scratch now!!!". Of course, this is not popular point amongst the deluded individuals who are running things into the ground and wondering why it takes an exponential amount of time and resources just to keep things running.
Re: (Score:2)
Perhaps you should employ more mathematicians. You should be able to get that down to a quadratic amount pretty easily.
Re: (Score:2)
Be bold. Make it negative.
The more you have to do the faster it will be done.
Re:ML is a language, not "machine learning". (Score:5, Interesting)
One extreme is the overuse of layers and abstractions wrapped around abstractions, which makes for nice diagrams that make it look like you worked hard. The other extreme that I see are the self taught low level programmers who didn't get a lot of mentoring along the way, that don't see what's wrong sharing globals across all the files. I have to explain the basics of simple abstraction to a 50 year old programmer who should know better, who complains that it's stupid to put split code into layers or modules because it's easier to understand if it was in one big file.
I want something in the middle, ability to think at a low level and get stuff done efficiently but also able to use the obvious abstractions that makes code easy to change and adapt in the future.
Re: (Score:2, Interesting)
I want something in the middle, ability to think at a low level and get stuff done efficiently but also able to use the obvious abstractions that makes code easy to change and adapt in the future.
You can't have that. People with a varied skillset look weak in any particular area to recruiters.
You're right though, just the right mix of layering and abstraction with practical code getting the work done, nicely cut up in parts by general function, and code written in response to an emerged need for it, not the "we'll write it just in case because the logic of the framework demands it" fluff code. It's one of those things I've been thinking off and on again about for years, because, well, it interests m
Re:ML is a language, not "machine learning". (Score:5, Interesting)
You can't have that. People with a varied skillset look weak in any particular area to recruiters.
As a technical lead, this phenomenon has been a source of great frustration in getting candidates. I'm only allowed to even know about a prospective candidate after 2 or three layers of non-technical folks have "helped" me by making an assessment of the candidate's technical chops. Similarly they "help" in the requirements by padding things out so that a candidate will have everything needed to "hit the ground running", because of course there would be no ramp up needed if they *just* have the right resume...
No recognition that there is always going to be a ramp up period, that you want flexibility more so than existing directly relevant experience.
Re:ML is a language, not "machine learning". (Score:5, Insightful)
This seems to be one of those unfortunate things (for both applicants and existing technical staff) that comes from bureaucracy as an organisation grows. As soon as you're big enough to have HR and Legal running the show in terms of recruitment, they're putting their own filters in between potentially good candidates and potentially interested technical teams within the business. That does avoid a lot of the time-wasters, but it also gets in the way of an efficient hiring process for qualified applicants.
I don't play in that playground any more, but my view when I did was that HR should restrict its screening to formalities (for example, can this person legally work here?) and objective facts about the candidate. And even then, since the objective facts most likely to be interesting are about the candidate's technical skills and experience, you still need someone who doesn't confuse Java with JavaScript and who realises that a candidate with 10 years' experience using SQL Server and MySQL can probably handle the Postgres skills you're asking for.
Re:ML is a language, not "machine learning". (Score:4, Insightful)
Speaking of ML, I once had an interview at Bell Labs and they sent me off to another guy after they saw I had some SML experience. Then I told him that I preferred Lisp and listed some of the stuff I disliked about SML. I just got a funny look. Later that evening it dawned on me that the "New Jersey SML" might have something to do with Bell Labs, and I looked it up and found out I had just dissed the language in front of one of its chief designers...
Re:ML is a language, not "machine learning". (Score:5, Funny)
Don't leave us hanging; did you get the job?
Re: (Score:3)
No. A different company was already interviewing me in the area, so Bell Labs and another company they were willing to interview me as long as I was in the area anyway :-)
Re: (Score:2)
It is a very confusing time. The norm is pretty much to misrepresent yourself to get some position or to look impressive, or in some cases just to get a vendor to connect a customer to someone vaguely knowledgeable.
I have to be sympathetic though, as the vast majority of the time when I encounter someone making their experience/day-to-day job sound more complex than it is, there work is actually being done well as it stands and would not be served by 'legitiamtely' chasing the buzz. They have to appease a
Re:ML is a language, not "machine learning". (Score:5, Funny)
Don't you know? Education is overrated, everyone's supposed to be self taught, theory is for losers, type checking is for incompetents, and languages like ML are for old fuddy duddies.
Terror (Score:4, Insightful)
Well, his zombified hoarde of brainwashed language fanbois terrifies me, so I guess we're even.
Graydon Hoare sounds like he was triggered (Score:3, Interesting)
Graydon Hoare sounds like the SIGSEGVs he got from his crappy C++ code triggered him.
Then, in classic SJW form, he completely overreacted. And keeping with the SJW "thought" process, it wasn't his fault: a bad workman always blames his tools... [wiktionary.org]
Rust is the intersectional racist victim-mongering language - we are all victims of RAAAACIST C and C++ - languages that allow you to think for yourself - and therefore you are responsible for your code.
Rust is the perfect SJW language - it tells you how to think and
Re: (Score:3, Interesting)
He's a hardcore SJW, then employed by a hardcore social justice company that's still the major sponsor of the language, so the answer pretty much has to be "yes".
Facepalm. (Score:5, Informative)
The summary say "machine learning" but if you read this feed you'll see it's "ML". ML is programming language. [wikipedia.org]
I know some people are excited about it but Rust is just the language de jure until it gets an actual spec that other people can implement.
Re:Facepalm. (Score:5, Funny)
Re: (Score:2)
Perhaps he was being subtle and opposing "de jure" as not "de facto". That is, not a "real" language but a theoretical (legal) construction.
Re: (Score:2)
Is Rust currently fashionable? Is there any legal dispute about whether it's a language?
So which fits the context?
Re: (Score:2)
I like your explanation of not being wrong. Consider going into politics! ;)
Because trailing semicolons... (Score:3, Informative)
... making the difference between "return the evaluation of this expression" vs "don't" is such an improvement in software development practices.
Rust is interesting, the way that that wreck on the 101 is "interesting".
Re: (Score:2)
... making the difference between "return the evaluation of this expression" vs "don't" is such an improvement in software development practices.
Really? You think that's all there is to Rust?
I love how people here love to diss stuff from a position of utter ignorance.
Re: (Score:2)
Maybe the ignorance is on your side? Because kfsone didn't claim that was the _only_ problem he(?) have with the language...
So instead of thinking and replying you react.
Re: (Score:2)
So how much time did you waste going deeper? Joke's on you, AmiMoJo.
Terrified to use Master and Slave (Score:5, Interesting)
He is terrified of other language because, being a Social Justice Warrior, his group finds the terms "master" and "slave" to be "problematic."
No, I'm not kidding [github.com], though I wish I were.
When a language is gleefully throwing away well understood, well used terms because of someone's misguided feelings, then quite frankly I wonder what other decisions - truly important ones - have been impacted by the same toxic SJW attitude.
Re: (Score:3)
>No, I'm not kidding, though I wish I were
Master/slave term has been on its way out for 15 years now.
Re:Terrified to use Master and Slave (Score:5, Informative)
Your logical fallacy is: ignoratio elenchi.
The liar is you.
Comment removed (Score:5, Interesting)
Re: (Score:3, Interesting)
"Rust was, by far, the most difficult-to-learn, difficult-to-research, counter-intuitive, unfriendly, constrained, unappealing, etc. of all of them. Warnings and errors appeared systematically and, despite their verbosity, were rarely helpful."
I don't know rust so I can't comment on it directly, but I'm a C++ dev and a lot of that applies to C++ which - it pains me to say - has become a designed-by-commitee dogs dinner with some appalling, borderline unreadable, syntatic hacks and yet they still just can't
Re: (Score:2)
Re:I am also terrified... by Rust! (Score:5, Informative)
I first learnt C++ 2 decades ago and even I have given up trying to keep up with the latest pointless additions to the language that no one outside a small circle of language geeks was asking for.
I'm having a hard job thinking what those are.
Just about every new addition to C++11 saved major ball-ache at many points in the code, even the somewhat botched initializer_list.
C++14 basically fixed all the weird "WTF this doesn't work" bits from C++11 where the features weren't quite complete in obvious ways (e.g. auto lambdas, return type deduction for normal functions and so on).
Except for binary literals and digit separators. Those were new. and holy-o-fuck are those useful if you're hammering on an SPI bus.
I feel sorry for anyone trying to learn it from scratch today as the learning curve eventually gets as close to vertical as you can get in a programming language.
It's vertical if you try to learn modern C++ as 20 year old C++ with extra features. That's not the optimal way to learn it, because then you're stuck with all the misdesigns of the old features with a whole pile of new ones. It's the way we learned it of course, because we learned C++ then C++98 then C++11.
It's bad in the same way that it's bad learning C++98 as C with a bunch of new features. You get the worst combination of complexity overload and feature overload. Again we did it, but I wouldn't teach someone new that way.
Stroustrup has a book on learning modern C++, and it's very well written and makes the curve much gentler.
I very much doubt you need it to learn C++, but I think it's a good read if you're in the position of teaching or mentoring since it sheds a whole new light on how it comes together for new programmers.
Re: (Score:2, Interesting)
I have to agree with the earlier post about so much being added to C++ and how much of it is useful. When looking over my C++ code what I see repeatedly is that I've never needed much more than C with Classes.
The RAII capability, operator and method overloading and basic container classes seem to provide all of functionality I generally use. I more often prefer object orientation using composition to inheritance so I do make use of interface design. But I'm fine with very basic template usage for things
Re: (Score:3)
During the summer I wrote a game in C++11, about 70K lines of code, and one thing I noticed was holy cow how many fewer crashes I had than with the usual non-RAII C/C++98 code. It was less maybe a handful surprising access violations. It could be partly to the VS 2017 IDE, but it can't explain it all. Some things were hard to get right, but they were mostly hard to compile right. And once I got there I was floored by the cleanliness and robustness of it all. Empty destructors, no need for matching closing A
Re: (Score:2)
And even if you do make use of the new featur
Re: (Score:3)
These aren't the stuff of language geeks. Beginner C++ programmers find that stuff more easier.
The problem is you. I
Re:I am also terrified... by Rust! (Score:5, Insightful)
I'm more concerned by trying to debug Rust than the editing aspect. Rust can be debugged through cdb, gdb, lldb etc. but none of that comes "out of the box" on Windows. It's much easier to get going on Linux since you only have a gnu backend and gdb is easy to install but even so you need little scripts to pretty up some of the data inspection. It would be nice if rustup or whatever had a simple way to install the debugger on Windows.
Concerning difficulty I think many of the same difficulties would be encountered if you chose C++ instead of Rust and came from a higher level language background. Both languages force you to think in terms of stack, heap, memory allocation etc. It's just that Rust will kick your ass up-front if you get it wrong while C++ will happily let you write errors into your code and you'll just have to discover them (or not) later when things break. Personally I would take that pain simply because it reassures me that code that comes out the other side has a lot less errors in it.
That might make the language seem more painful to use but its doing you a favor by making your errors obvious now, not later and to write safer code. I think the error messages from Rust are very useful. They tend to be descriptive and usually provide a suggested fix which is often right. Certainly far easier to work out what the error relates to than many C++ errors. It's not uncommon in C++ for a trivial code error to throw up a wall of impenetrable garbage thanks to templates and static typing.
An anecdote - I've been programming Rust for about 18 months now and do you know how often my compiled program has crashed because of a null pointer, dangling reference or some addressing error in all that time? Once. And that crash was in a C library I was calling from Rust! In other words the code I've written has never crashed a single time.
I see nothing major about Rust the language which needs to change. I think the biggest hurdle for people coming from C++ is understanding that stuff moves on assignment and there is no inheritance. So they have to unlearn stuff and think about doing things another way. It's certainly a hurdle but I don't think it's too tricky. The payoff is less bugs and ultimately that means better quality software, less support calls and happier customers. If I were developing for IoT or mission critical software I'd definitely choose Rust over C or C++ unless there was a reason I could not.
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
Besides that, a crash is rarely ever a good thing. It might be simple to identify some crashes e.g. calling a null or dangling pointe
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Haskell and C++ are actually very similar languages with wildly different syntax and defaults.
Re: (Score:3)
Re: (Score:3)
I don't know about the exact reliability of that claim, but it sounds quite similar to what C++ offers. And as commented above, C++ can be very complex but it also has very simple and intuitive alternatives.
It does, but not for everything. One Rust was designed for was large amounts of irregular fine grained multithreading with shared mutable state. You know the sort of think you'd have in a web browser, not a scientific number crunching task.
Personally for most scientific stuff, C++ I find fine becuase the
Re: (Score:2)
Re: (Score:2)
I don't trust Graydon Hoare (Score:4, Insightful)
It's a bit hard for me to trust someone whose webpage had a banner proudly suggesting voluntary human extinction to make a programming language that is more secure.
Comment removed (Score:5, Insightful)
Re: (Score:2)
You've never actually seen much less used a circular saw, have you?
(I have no dog in this fight; I just think that's a very weak argument.)
Re: (Score:2)
Programming languages should be as type safe as possible but I doubt that can be done for low level system programming. A lot more OS programming could be in something like Ada or Java though.
Re: (Score:2)
Re:Um... (Score:5, Funny)
DeWalt doesn't sell power tools that go out of their way to make sure you don't cut off your fingers.
Unfortunately, they do. That's why when I get a new power tool, I have to make modifications to pare it down to an elegant C-style device:
I remove the blade guard. I cut off the grounding prong and file down the ears on the neutral conductor. I permanently glue down the little trigger interlock button. I put a lock washer on the blade arbor so that it can't ever slip and reduce my torque. None of these annoying things even matter so long as I never make a mistake.
Re: (Score:2)
DeWalt doesn't sell power tools that go out of their way to make sure you don't cut off your fingers.
Unfortunately, they do. That's why when I get a new power tool, I have to make modifications to pare it down to an elegant C-style device:
Will you disable their potentially upcoming sawstop substitute [coptool.com]? I, for one, would very much like to own a sawstop table saw. I've never cut myself with a saw (knockonwood) but I have caused myself various minor injuries with some lesser power tools over the years. There is, perhaps, less of a tendency to treat them like the dangerous machines that they are. However, one untimely cramp or spasm and it's goodbye fingers, or at least hello hospital.
Re: (Score:3)
I took shop in junior high and our shop teacher was showing us how to use a table saw. He demonstrated how to use a push stick and then held up a hand with two missing fingers and said "USE YOUR PUSH STICK!" in a very loud voice. I made sure to use the damn push stick.
Re: (Score:2)
Unfortunately, they do. That's why when I get a new power tool, I have to make modifications to pare it down to an elegant C-style device:
That's one extreme. And if you to the other extreme [ssl-images-amazon.com] that's not very useful either. That the code doesn't crash doesn't mean it does anything useful or won't go into an infinite loop or that exceptions or error conditions are meaningfully handled from a user perspective or that the code is secure from unauthorized access or alteration or that data won't get corrupted, deleted or overwritten. Maybe if it's some kind of online service where you're bringing down many users, but if my game client crashes or hang
Re: (Score:2)
People used to criticise C for not having a strongly enforced type system. Now everyone thinks JavaScript is great.
We went from "let's make the language more secure and robust" to just kind of admitting defeat and accepting that most software will be so crap it has to be heavily sandboxed.
Re: (Score:2)
It's not a fair analogy. Software has similar latent failure properties to a poor electrical job. The way we write software now is like wiring a house without a grounding conductor. At one point houses did not have ground wires. Now, if you don't install one it's akin to arson.
Re: (Score:2, Insightful)
I hate to break it to you, but the early power tools were very dangerous, they lacked handguard etc, and they lacked automatic cut-offs in case you cut yourself. You had to actually turn the power off manually to stop them cutting your fingers off, instead of having something you need to constantly hold down to make them work. Those safety features came about in the 1970s mainly, because when power tools started being used by home handymen in the 1950s, they were cutting too many fingers off.
Good tools take
Re: (Score:2)
Because a computer can perform checks faster and more reliably than a programmer can. My understanding is that Rust has thread safety as one of it's main goals, that this is something that is difficult for programmers to check, and that it's becoming increasingly relevant because multiple cores are replacing increasing clock speeds as a means of increasing computer performance.
Re:Um... (Score:4, Insightful)
Re:Um... (Score:4, Informative)
So why does Rust require the programmer to describe intent to an exacting detail, rather than figuring it out on its own? If computers are so very fast at it?
Also, Rust does absolutely nothing about deadlocks. Its multithreading features were designed by people looking for an appearance of parity with e.g. POSIX threads, while neglecting practical applicability. The same problem exists in various other new languages, such as Java and D; omitting POSIX, they can't reach parity despite replicating the threading portion equivalently.
Re:Um... (Score:4, Insightful)
To prevent casual accidents. Nothing is stopping someone from sliding the guard out of the way and jamming their hand into it. Programmers should know how to use their tools so they don't do the equivalent of sliding the guard out of the way and jamming their hand into it.
You'd think so. And yet here we are with buffer overflows still causing havoc, Intel's best and brightest allowing your CPU to get pwned at the hardware level, Apple allowing anyone with local access to authenticate as root with no password, Adobe still shipping Flash Player update after update, Oracle releasing patch upon patch for Java and Microsoft being forced to un-patch systems that have just been patched due to a higher than expected number of reboots. Even OpenBSD which is secure by design and runs fully audited code isn't immune from remote exploits in the base install.
We have spare CPU cycles today, we don't need to code for the bare metal to get the performance we need. What we do need are safety nets and liferafts to prevent human errors from becoming security vulnerabilities. Humans make mistake. Maybe the top 5% of programmers would never make these kinds of errors, but not every programmer writing code for a major (or not so major) corporation is an International All-Star Programmer. By definition, 95% of them are not in the top 5% of coders.
Even with safer languages these errors can, and will, occur - but there are whole classes of errors and vulnerabilities that are able to be prevented by using a suitable language. There are other errors that can still be made in safer languages, but you need to go out of your way to do so.
It's the same with tools. There's a guard on my circ saw, but I can slide it out of the way if I try. It does mean however that after I've made a cut, if I put the saw straight down, it's not going to drive itself across my workshop floor, or cut my toes off.
Re:Um... (Score:4, Informative)
Sure, but his point isn't that the language allows you to make mistakes - they *all* do that, the problem is that the developers are too overwhelmed with frameworks, libraries, architectures and having to use many different languages all the time that they will make mistakes.
I used to code C++ and I was good at it, the number of errors I put in was minimal. But that was the days when it was the only language I used.
Today I'm using C++ and C# and javascript with a dose of scripting and loads of different ways to do the same thing, and every time I think of dong something I realise I don;t have the same level of expertise I used ot have before - not because I'm no longer good at my job, but because there is so much stuff to remember and apply that I will forget the odd bit here and there, and that is where mistakes creep in.
Once you've seen the kind of serious PCI compliance checking tools that tell you your perfectly-working code is unacceptable because of things you didn't consider, then you get a handle on why the language is not the problem at all.
the only safe way to write code today is to keep it modular, and then to keep things separated. Too bad that all the frameworks you code with try to make everything into a single monolithic lump "for ease of coding" so the noobs can find it accessible.
If you had only experienced programmers coding, in a few languages and systems, they'd be able to do all the stuff we have today, but faster and better. As it is, we try so hard to get as many people coding as possible, and have so many different systems to code in, that the whole industry is a massive chaotic mess.
once all I needed to code was a knowledge of C and the IBM big book of library calls (which told me everything their API did). Today, we need google and stackoverflow and looking up stuff hourly, and even then I'm having to filter results on the version of the library I'm working with so even the results for the documentation is often wrong. How does anyone expect our systems to work properly without massive amounts of effort.
Re: (Score:3)
We have spare CPU cycles today, we don't need to code for the bare metal to get the performance we need.
Great points, but I must take issue with this. We don't have spare CPU cycles, because this is exactly equivalent to saying we have electricity to spare, which we most certainly don't, especially on mobile.
Language safey features do not necessarily need to come at a run-time cost in any case, since well-written C++ is about as safe and fast as it gets. Unless you count the hours it ends up taking to compile...
Re: Um... (Score:2)
Re: Um... (Score:4, Insightful)
Re: Um... (Score:4, Insightful)
Unfortunately, Rust doesn't have any way of constraining the side effects of unsafe code, and most nontrivial Rust programs end up using unsafe in at least some places.
This is unfortunate: it would be ideal if there was graduated unsafety. Rather than havina an "unsafe" block with everything off, it would be cool if you could specify what you want relaxed.
On the other hand, it's a lot better than nothing. Having 99% of the code safe and spending extra attention on flagged unsafe blocks is better than having to look for pitfalls everywhere.
Re: (Score:3)
I've never liked the 'unsafe' keyword. It gives two false impressions: code that uses it is unsafe and code that doesn't use it is safe.
A much better keyword is probably 'unmanaged', because that doesn't connote incorrect assumptions and actually represents what the keyword means.
I'm also a firm believer that the most severe software bugs are due to code that isn't designed but merely written. Code is often written only looking at a "nominal" use case without considering failure modes, so even in the rare
Re: (Score:2)
Looks like cayenne8's forgotten his password!
Re: (Score:2)
The problem is, there isn't a perfect language, and there's no language that perfectly covers all styles and domains. Thus people do come up with new ones in order to fill a void. Ie, C was good enough for most things awhile back, but it's hard to learn it well and use it well and very easy to make mistakes in. Then Objective C and C++ gave a couple of different takes on object oriented programming. Modula-II and Ada came from a European lineage, with a good set of abstractions and type safety. Lisp led
Re: (Score:2)
I find it hard to believe that the DoD would use commie unarmed foreign godless pinko commie stuff.
Ada was originally designed by a team led by Jean Ichbiah of CII Honeywell Bull under contract to the United States Department of Defense (DoD) from 1977 to 1983 to supersede over 450 programming languages used by the DoD at that time.[9] [wikipedia.org]
Re: (Score:2)
That must be why the jobsearch websites are full of positions where the main requirement is yacc.
I'd love to work on a 100 person project with 101 different languages. I mean, who wouldn't?
Re:what a bunch of ignorant bullshit (Score:2)
I'd say your a quant with a BBC fetish
So he watches a lot of TV or are you saying he has a big stack of 8 bitters running Teletext?
Re: what a bunch of ignorant bullshit (Score:2, Funny)
That would be the *other* BBC :)
Re:what a bunch of ignorant bullshit (Score:4, Funny)
Not that BBC....
Re: (Score:3)
I'll also add look up a few of your favorite projects on github and look carefully at the "insights" chart on the contributors. Many of them will clearly have one significant contributor, or maybe a small team, and hunderds of one-line contributors (putting your brand on big projects is good for resumes).
I'd take a team of 4 or 5 solid people over dozens of developers. I resisted 'investmnet' in my team at a former employer as I had never seen a project survive such an expansion with quality intact under