Hacker News Reader

Comment by J_Darnley | Hacker News Reader

So what language to you propose we use to rewrite all video and audio software? Javascript, Lua, Brainfuck, what? Sure make every numeric value a double, nobody ever wants a char. Don't allow contiguous blocks of memory. Or if you do check every access is within the bounds. Its all safe! Nobody cares that suddenly we can't decode an MP3 in realtime.

Are you going to outlaw assembly too?

What utter insanity.

View on HN

> So what language to you propose we use to rewrite all video and audio software? Javascript, Lua, Brainfuck, what?

It's not proposing a particular language; only a property was proposed: memory-safety. This was defined loosely:

> Garbage collection was invented in 1959, for Lisp, the first memory-safe language. It provides the foundation for memory safety and it is used in most memory-safe programming languages today. (It is also possible to have memory-safe languages without garbage collection, e.g., Cyclone or Rust.)

We could compare this with other properties of programming languages which have been tried in the past, but are now considered bad ideas or a last resort:

- DWIM (Do What I Mean): if a name (function, variable, etc.) doesn't exist, use one with a similar spelling

- Ignore errors by default: eg. Bash without "set -e", visual basic's "On Error Resume Next", etc.

- GOTO: still useful on occasion, but no longer the "go to" control structure in most code (pun intended)

- Dynamic scope by default

- NULL: Perhaps controversial, but also infamous. Can be tamed with nullable types, or eliminated with option types.

- "Loose typing", ie. the casting rules in PHP, JS, etc. which break symmetry and transitivity of "=="

- Automatic semicolon insertion: Either require semicolons or don't; trying to guess leads to problems

- Name-based typing: eg. in FORTRAN any variable name beginning with I, J, K, L, M or N are implicitly ints, anything else is implicitly float

I would certainly consider memory unsafe languages in the same category. There's no need, now that we have garbage collection and linear types.

I suppose the answer would be Rust or similar because they aim to be as fast as C/++; however, that is currently only a goal and most certainly not the reality (according to some source I read a month or two back that I can no longer find).

I also hope to end C/++, but it's simply not time yet.

Please show me how to implement a graph library without using unsafe in Rust.

This argument is very flawed, since you are forced to use `unsafe` when you need anything communicating to the outside world (which includes, obviously, `println!`). The very point of Rust is to limit the unsafe surface, not to completely eliminate that.

First of all a graph library does not communicate with the outside world.

My point was that even for the ubiquitous task of implementing a graph structure, unsafe is necessary.

So while Rust may provide a clean separation between unsafe and safe code (enforced by the type system), the original problem remains: How do we ensure correctness of the unsafe parts of the code.

For what it's worth (and I intentionally didn't point this out in the parent), you can make a safe graph library in Rust with a typed arena (slightly less ergonomic and faster) or a refcounted smart pointer (slightly more ergonomic and slower). But this still does not validate your point, since the memory allocator is in many cases unsafe.

On how to ensure correctness of the `unsafe` code: that was what we were doing with the entire C/C++ code for decades, so what's the problem? We could however concentrate on the much less amount of code if we were using safer languages.

Several answers to this challenge

1) It's doable http://smallcultfollowing.com/babysteps/blog/2015/04/06/mode...

2) Which attack surface would you rather deal with... the small fraction of your graph library that deals with mutability... or all of Adobe Flash?

3) The fact is that "unsafe" doesn't mean unsafe, it means "trust the programmer that this is safe". It's reasonable to assume that safety can be maintained in Rust libraries that use the unsafe keyword.

I've never actually used Rust myself - I'm just familiar with their goals: so I'm not entirely sure what you are referring to.

Just keep in mind that the amount of work done on the various C++ compilers is most likely measured in man-decades, where Rust is probably still man-hours.

Do you mean a directed graph or a graphical graph? I've implemented directed graphs in at least two different managed languages (which are more constrained than Rust) and had to use no unsafe breakouts. There might be some complexity for some reason with Rust, but if it's possible in a managed language then surely...

  >  Rust is probably still man-hours.

It's nowhere near the amount of time put into various C++ compilers, but

  1. We use LLVM, so all that time is working for us as well.
  2. Mozilla has been paying at least 4 people for at least a
     few years to write Rust full-time, I would bet we're coming
     up on a person-decade of time for Rust. The project has existed
     for eight years in total, though four of that was just as a side
     project.

I would guess that it's well past one decade for Rust (there's been 8 paid people on the team for at least a year).

It seems to me that an undirected graph can be represented as a map from keys to sets of keys (which can be integers, strings, or anything else), with the invariant that map[x] contains y iff map[y] contains x. For a directed graph, use two maps for incoming and outgoing, with the invariant that incoming[x] contains y iff outgoing[y] contains x.

This approach doesn't require unsafe anywhere and all graph operations are easy to implement, including deleting nodes. Am I missing something?

  > (according to some source I read a month or two back that
  > I can no longer find).

Stuff changes fast in Rust-land, so even if it were a month or two, it might be wrong. We should always be pretty close, and we're sometimes faster, depending on the code.

I think the main reason we aren't moving away from C and C++ is interopability, and not performance. I can come up with a number of benefits of C in this regard:

1) Ability to use existing libraries directly (just #include and add to LDFLAGS).

2) Ability to be called (as a library) by code written in almost any language, without indirection through serializing function calls or similar.

3) Modern operating systems can share code and constant data sections between processes for normal compiled programs (but not byte-compiled ones).

4) C has a good tool support, such as debuggers and packaging tools for Linux distributions.

5) A practice of backwards-compatibility in the C language and libraries written in C makes it possible to mix code that was written for different versions of C or that use different versions of the same library.

Ada, Modula-2, ....

> What utter insanity.

Insanity is that C and C++ keep being used.

The question is about defaults. Current default of C and C++ is to cut all corners wherever it is not clearly impossible (sometimes even then). That is the insanity.

Of course you should optimize wherever sensible.

Never panic early. Look e.g. at Rust - just as efficient, much more secure.

I say every language except Logo should be banned. Programmers can't be trusted with memory and all these weird things!

Also processors should directly interpret Logo. And operating systems too. And memory access isn't allowed. Memory is dangerous.

Pffft... Javascript. Don't you read CodingHorror? W/E!

Reply on news.ycombinator.com