@tylerl Whenever you need to implement a lot of memory management and all, like a GC. You either have to use tons of unsafe blocks, or just wrap around C
@ManishEarth Right. But at least you're being explicit about your unsafety. At least you're painting a big red sign over the part that requires extra vigilence. So much of the vulnerabilities in C++ code happen in places where you're doing boring stuff that requires no particular speed or fancy language features.
@tylerl Yep, agreed. But as of now, I'm pretty sure that a Spidermonkey written in C++, with years of vuln testing, will be more secure than a Metalmonkey written in Rust
Note that unsafe blocks aren't the only place unsafety happens
I might do fn foo(){unsafe{blah}}, and whenever I call the function, I'm doing something unsafe. But I don't have to put up a big red sign when calling foo. Poor decisions like this ("I don't think foo can be used in such a way so as to cause a memory safey hazard", even though it can) will still happen
And if unsafe fn foo is used, you get more unsafe blocks littering the place. If we started from scratch, Metalmonkey or whatever would be more secure than Spidermonkey. But we aren't starting from scratch ;)
So Rust is a language that doesn't trust the programmer, that's where the memory safety comes from
It's like that thing teachers used to say when you asked to go to the bathroom. "Can I go to the bathroom?" "I don't know, can you?". They know perfectly well what you mean. They want you to express it better.
And this is one of the reasons why I don't think it will completely replace C(++), C++ is easier and less of a mental tax
The mental tax of Rust cleans up segfaults and stuff, though. It tries to transfer the headache from unpredictable runtimes to predictable compile times. But that doesn't alleviate the point that the compiler is just plain pedantic.
But at the end of the day, it's supposed to be :)
Memory safety is an issue because programmers are stupid. Don't trust 'em ;p
@ManishEarth ugh. now I don't even remember. I spent a long time with Rust about a year ago and I remember being distinctly disappointed with the way the core paradigm is organized, having just recently before that started using Go in production stuff. I was hoping to start using Rust for developing shared libraries.
@tylerl It's more of a "use it for a month, learn to love it" sort of thing but to be fair one can even learn to love PHP if they are forced to use it for a month :P
In comparison, when I started using Go I remember distinctly thinking "WOW, why haven't we all been doing this from the beginning." Everything was just so clean and well-designed.
@tylerl Agreed, Go is fun. But after using Rust for a few months, my C++ code is now better, I have an internal borrow checker that tries to check for memory safety. Annoying at times when I really don't want to think so much, but I take it as an improvement :)
/me needs to write more Go, haven't touched that in months
@ManishEarth I had to abandon Go a couple of years ago because of bugs in the stdlib. But at 1.0 they really cleaned it up. It's totally production ready, I think.
Rust is at a stage where they're punting stuff around the core libs, most of the functionality is frozen. Though there are talks of removing certain types of cumbersome syntax.
@TerryChia I designed a C-replacement language just for fun several years ago. Never implemented it, but it was a fun exercise. The FFI was to simply expose and consume functions using C calling conventions.
Because it's immediately compatible with literally everything.
@TerryChia yeah. They try really hard to get you to not write Java. They have something like exceptions, but you don't do the class hierarchy thing with them.
it's just any object that can be printed to a string.
I still have not found a language I enjoy writing as much as Python yet. Explains why I keep going back to it even with the warts like horrible packaging and not too good performance.
@tylerl Yeah, not the same as exceptions though. The way Python uses exceptions is really neat, especially the chained exceptions thing in Python 3.
Don't tell me you never run into a situation in python where a chunk of code makes a call and catches an exception to tell what path to follow, but instead of the call in question throwing the exception it's some other code referenced somewhere. So instead of properly reporting the error, the program squashes it and just adds another array element or something.
@tylerl Ah, I see what you mean. I have encountered this once or twice but not frequently. I think the idea here is that well written libraries should make sure to catch whatever exceptions the stuff it is calling raises and either handle it or chain the exception properly. I can see how this isn't always the case though.
But I dunno, I really like using exceptions as flow control.
@TerryChia It's convenient, but it leads to crappy programs. Because exceptions get ignored and frequently bubble up to the user. And you end up with yum printing out ValueError: invalid literal for int() with base 10 and the user is like "FUUUU" and now has to go read the damn source to find out that this means that a upstream source timed out....
The patterns that a language design encourages or discourages is an important feature of the language, and necessarily influence the the programs that get written with it
Some language designs make good behavior more difficult
@TerryChia The problem is that the extra work of catching and handling all possible exceptions from lower levels negates the perceived advantage of the way Python does exception-based flow control
@TerryChia I prefer the fact that Go discourages programmers from using exceptions for driving mundane flow decisions
As Stroustrup said, "They're called exceptions for a reason."
@tylerl I think the idea here is not that I need to catch all possible exceptions at a lower level, it's just that I should handle the exceptions before it hits anything outside my app/library boundary.
So any exception a user encounters will be documented.
@TerryChia And ideally all programmers do that, so ideally all exceptions tossed by lower libraries are properly documented and you actually can handle them.
In Rust you have Results. A method who returns a Result can return an Ok(data) or an Err(errordata). When you call the method, to use the Result you either have to match on it (in which case you have to handle every possible Result, possibly bubbling the error out, since match statements are exhaustive), or you can unwrap() it, which will cause a task failure (and usually a crash), if it doesn't work out. But you get to be explicit about the "I know there's an exception here. Screw it"
The go exception-flow is interesting, too. Rather rust-y with the "return the error" bit (without forcing you to match on it, though, so less powerful), and the panic-recover bit gives you "normal" throwing support in a slightly safer way.
The stable build update every 3 months. The nightlies are, well, nightly. Updating a library to a new stable build is annoying. With nightlies, it's less hard since there are less breaking changes at once
@TerryChia if you're writing a library at any time, let me know. I can help with the upgrading and possibly the library writing
assuming I have all the information and I know the whole story, of course.
@tylerl @TerryChia there are two ways of considering a language: how bad can crappy programmers screw up, and how hard for good programmers to NOT screw up.
@AviD Not really. It's actually pretty good from a readability standpoint and fits really well with the "it's easier to ask for forgiveness than permission" idea that Python encourages.
@LucasKauffman I will never again, either. And I would recommend about it to everybody.
@Kisunminttu the scary part is how the people there treat it like something normal.
@tylerl hey, I used to work for a company that sells software for these clocks. and I can tell you that you are oh so very right.
actually, there are some semi-legit uses. for example, if you receive government grants, and they require clocks. or if all your employees are outsourced and paid hourly by someone else.
basically, if the entity paying the money does not trust the people doing the work. In which case, you're mostly screwed already anyway.
@kalina That's just the FAA trying to grab a bit more authority for themselves... despite the fact that the relevant legislation explicitly denies them that authority.
@tylerl I would say a "model aircraft" with several miles of range capable of carrying its own weight would cease being a "model aircraft" in the recreational sense
@tylerl well it should be, the same way car insurance works
while your example is a little extreme, I think there would be a much larger problem if a bunch of companies started using unlicensed model aircraft for stuff that is really commercial work that should require a permit
sure, let's allow a bunch of people to fly rc helicopters or whatever around, taking pictures
what does shock me though, is the occasional spark of brilliance there. If I meet somebody that is really smart, and is really good at her/his job, I am always puzzled why they would continue to subject themselves to such poison.
I think it might be mostly a case of accepting the lie that work needs to be like that.
I generally don't use symbols in my generated passwords any longer, harder to type on mobile devices where I don't want to sync my password database to.
My current setting is 24 characters, mix of upper lower and numbers.
@AviD Is it more common for Windows applications to dynamically link to "common" libraries, say OpenSSL for example, or for the applications to ship with it's own version of the OpenSSL dll?
I would imagine it's the latter so installation is simpler?
@TerryChia I have an extreme password that I use for my super important things and that is too hard to type out on a mobile device
too much like willingly stabbing yourself in the face
"What are you doing today?"
"In bed"
"oh so you're not doing anything, can I bring my laptop over because it's doing something weird"
"define weird"
"it's not working"
"..."
after several more minutes of back and forth, I concluded that "it's not working" is the most information I'm going to get before offering to look at it
@TerryChia there are several different sets of commonality. It depends.
e.g. C++ / MFC / ATL apps, you have to choose e.g. static linking vs. dynamic linking vs embedding. Each of those has a different default...
"classic" apps e.g. VB / Delphi / etc usually ship with their version of the common runtimes and push it into the System32 folder....
yes, possibly overwriting and not playing nicely with a different version. This is the well known "DLL Hell".
Then there are .NET apps. "Common" libraries are usually stored in the GAC, which allows for multiple versions. Each app will typically bind to a specific version, though they can define to accept a later version too.
not-so-common apps would normally be shipped with the application itself, in versionable subfolders.
