On Thursday, 2 March 2017 at 22:25:49 UTC, H. S. Teoh wrote:
> But again, the elephant in the room is that in the good ole clear-weather days, such an error would at most take out one or two (or a small handful) of related sites; whereas in today's cloudy situation a single error in umbrella services like AWS can mean the outage of thousands or maybe even millions of otherwise-unrelated sites.

Well, but on average the outcome (SLA) is better, assuming that they can have more specialised personell and spend more time on harnessing the infrastructure.

It's just that you get global scale downtime.

On 2017-03-03 03:11, Moritz Maxeiner wrote:

> For what it's worth: I do hope memory safety becomes a common feature
> and what languages like D and Rust do on that front is great (even
> though both D's still heavily integrated GC as well as Rust's static
> analysis have their downsides).
> My major gripe, though, is still that people tend to create "safe"
> wrappers around "unsafe" (mostly) C libraries, which (in the sense of
> safety) doesn't really help me as a developer at all:
> Now I not only have to trust that the C library doesn't do horribly
> stuff (or audit its source), I *also* have to extend the same trust/time
> to the wrapper, because since it must interface with C all possible
> compiler guarantees for what that wrapper actually *does* are null and
> void (-> D's @system / Rust's unsafe blocks).
> Great, if I *truly* care about safety my workload has increased
> significantly compared to just using the "unsafe" C APIs myself (which
> is easy in D and a PITA in Rust)!
> In reality, of course, I just use the wrapper and die a little inside
> about the fact that I have to trust even more people to get things right
> when all evidence shows that I totally shouldn't.
> TL/DR: I wish people would write more native libraries in safe
> languages, but who has the time for that?

So we need operating systems and the core libraries to be built from the ground up with memory safety in mind in these kind of languages.

-- 
/Jacob Carlborg

On Friday, 3 March 2017 at 09:22:31 UTC, Jacob Carlborg wrote:
> On 2017-03-03 03:11, Moritz Maxeiner wrote:
>
>> [...]
>> TL/DR: I wish people would write more native libraries in safe
>> languages, but who has the time for that?
>
> So we need operating systems and the core libraries to be built from the ground up with memory safety in mind in these kind of languages.

That would be a good next step from an engineering standpoint, I agree, to proceed to minimize the amount of trust in people you need to have vs verifiable safety.
I have considered porting something like seL4[1] to Rust, but ultimately this would take a significant amount of time and even if done you'd then have the biggest problem any new kernel faces: Hardware support. Driver development is AFAIK mostly done by people working for the hardware manufacturer and you're going to have a hard (probably closer to impossible) time convincing them to spend money on driver development for you. And if they don't you'll have close to 30 years of hardware support to catch up on by yourself.
But suppose you limit yourself to a single (or at most a handful of homogeneous) platform(s) like [2], e.g. a new AArch64 board. Suppose you even take one where the hardware is open so you can audit its schematics, then you'll *still* either have to use proprietary firmware for the (partially onboard) periphery (and have unsafe interfaces to them), or - once again - write all the device firmware yourself.
And once you've done all of that you're still missing userspace, i.e. you have a nice new OS without any actual use for it (yet). So you either start writing your own incompatible, safe userspace, or you're going to decide to integrate the userspace of existing OSs (probably POSIX?) to your new OS, so you're going to be writing your own (safe) libc, (safe) pthread, etc, exposing (once again) unsafe APIs to the top. It will be safer than what we currently have on e.g Linux since you can probably make sure that unsafe use of them won't result in kernel exploits, though; this will, of course, take even more time.
Finally, at the arduous end of your journey you're likely going to notice what - in my experience - most new OSs I've observed of the years experience: Essentially nobody is interested in actually switching to a volunteer-based OS.
Honestly, I think you need serious corporate backing, a dedicated team, and like 5-10 years (low estimate) of guaranteed development time to have a snowballs chance in hell to pull this off and the only possible sponsors for this I'm both aware of and would currently trust not to cut you off in the middle are either already working on their own OS[3], or have dedicated their R&D to other things[4].

[1] https://sel4.systems/
[2] https://genode.org/
[3] http://fuchsia.googlesource.com/
[4] https://www.ibm.com/watson/

On Friday, 24 February 2017 at 20:16:28 UTC, Timon Gehr wrote:
> No. Worse. It turns failures into UB.

On the other hand disabled bounds check can result in buffer overflow, which is already UB enough, so asserts turned into assumes won't add anything new.

On Friday, 3 March 2017 at 02:48:46 UTC, Nick Sabalausky (Abscissa) wrote:
> I think it's safe enough to just go ahead and interpret it as "...evidence that memory safety is important and SHOULD be the direction we take."

In D you have less memory corruption than in C++, which in its modern incarnation has much less than in C, etc. That C programs have a lot of healine-making memory corruptions says not much about D.

Unsafe D provides:
- initialization
- bounds checking
- slices

and it does take away a lot of memory corruptions.

My point is that memory safety beyond what unsafe D may not provides as much value as it sounds. I could quote the Pareto rule, which is gimmicky but exactly how I feel about it.

On Friday, 24 February 2017 at 21:22:10 UTC, Ola Fosheim Grøstad wrote:
> I don't really buy that bullet-proof and under-performing solutions is improving on system level programming. It is an improvement for application level programming and performant libraries.
>
> Maybe, but most personal user data is at some level handled by programs written in C: database engines and operating systems. Although I've noticed that the current trend is to focus less on performance and more on scaling, e.g. cochroachdb is an implementation of a Spanner like SQL database in Go.

If it doesn't scale, then it's slow no matter what it's written in. For example SQL is slow even though it's very optimized: you simply can't handle millionfold increase in server load and data size with C optimizations, and that increase happens just fine. If it's 1usec vs 1msec it doesn't matter because the user doesn't see such difference, it it's 30sec vs 60sec it's still doesn't matter, because both are beyond user patience. Performance doesn't work incrementally, it just either works or doesn't, so you're unlikely to achieve anything by making it twice as fast.
Also why Cloudflare wrote new parser? Because ragel parser was slow. It's written in C and does all funny C stuff, but is slow. So where's famous C performance?

On Friday, 24 February 2017 at 15:15:00 UTC, Ola Fosheim Grøstad wrote:
> If you don't want to max out performance you might as well consider Go, Java, C#, Swift etc. I don't really buy into the idea that a single language has to cover all bases.

Ewww, java? Why not COBOL?

On Friday, 3 March 2017 at 02:11:38 UTC, Moritz Maxeiner wrote:
> My major gripe, though, is still that people tend to create "safe" wrappers around "unsafe" (mostly) C libraries, which (in the sense of safety) doesn't really help me as a developer at all

Wrappers are needed because C libraries have unsafe (and underdocumented) API that's easy to get wrong. I saw it happening twice in druntime. Safety is like optimization: you can handle it one or twice, but code handles it always, that makes a difference.

On Friday, 24 February 2017 at 19:19:57 UTC, Moritz Maxeiner wrote:
> *Then* you have to provide conclusive (or at the very least hard to refute) proof that the reason that no one could break them were the memory safety features; and then, *finally*, you can point to all the people *still not using memory safe languages* and say "Told you so".

Such proof is impossible because correct programs can be written in unsafe languages.

On Friday, 3 March 2017 at 02:48:46 UTC, Nick Sabalausky (Abscissa) wrote:
> On 03/02/2017 06:00 PM, Guillaume Piolat wrote:
>> On Friday, 24 February 2017 at 13:38:57 UTC, Moritz Maxeiner wrote:
>>> On Friday, 24 February 2017 at 06:59:16 UTC, Jack Stouffer wrote:
>>>> https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
>>>>
>>>> [...]
>>>
>>> This isn't evidence that memory safety is "the future", though.
>>
>> Completely agreed.
>> This only shows that memory safety is not the present. Not that it is
>> "the future".
>
> I think it's safe enough to just go ahead and interpret it as "...evidence that memory safety is important and SHOULD be the direction we take."

I agree with the sentiment that taking that direction is likely to yield significant benefits in the long run for both developers, as well as end users. But "important" is another one of those things that are entirely dependent on one's viewpoint.
If I have a business that incorporates a risk analysis based on penalties due to past bug occurrences and likely presence of more bugs in my software and come to the conclusion that investing in a transition to a memory safer language (however we define that) is just not worth the associated costs then it's not important for me.
I'll assume for the moment, though, that with you mean the D community and the direction D should take in the future. In which case I agree, though technically a correct garbage collector is memory safe by definition (unless I missed something).
What kind of changes to D (spec, druntime, phobos) would you envision (I'm honestly curious)? And are they possible without breaking existing user code (because I don't think that with the current userbase size D can survive yet another break of the phobos/tango, D1/D2 dimensions)?

>
> It's English, not an ISO RFC.

Interpretations in engineering are often necessary (I'm looking at you, ISO "specification" 7814-4), but in a technical discussion I don't want to interpret. I want to discuss the topic at hand; and I consider hyperboles such as "X is the future" to be detrimental to the effort of X, whatever X is. And besides, while I consider memory safety to be important and use it whenever viable, unless there is sufficient proof that people using languages with memory safety builtin actually produce memory safe(r) programs we don't have a leg to stand on.
And while this may seem an intuitive and reasonable hypothesis, it's still something that has to be proven; one current case shows to me, at least, that people writing Rust code can (and sometimes do) make the same kinds of mistakes they would've made in C regarding memory safety[1]. Which does not suprise me, honestly, since all of these languages I'm aware of currently allow you to expose a "safe" API over "unsafe" internal mechanics (or in the linked example the other way around) and if the unsafe code is broken you're screwed. Period.
The only kind of language for which I'd implicitly accept the conclusion that writing in it produces more memory safe programs than in others is one where unsafe operations are utterly forbidden. This, of course, is impractical, since it means no C interop and would make such a language more or less irrelevant.

[1] https://www.x41-dsec.de/reports/Kudelski-X41-Wire-Report-phase1-20170208.pdf