LWN: Comments on "A taste of Rust"

Integer overflow

dark — Wed, 01 May 2013 15:03:35 +0000

The first part is basically what floating point math is :)

Integer overflow

mathstuf — Tue, 30 Apr 2013 13:43:09 +0000

The second part has been implemented (see boost::unit). I don't believe that the first part has been in any of the unit libraries I've seen (they are mostly compile-time constructs and just reduce to doubles).

Integer overflow

etienne — Tue, 30 Apr 2013 09:11:19 +0000

> Python for example just overflows integers

I wonder if a language exists which separate "data" and "counter" variables, and associates every "data" with a unit - considering counters do not tend to overflow.
When a "data" overflow, it would then change the unit to something more appropriate.
For instance, if a variable contains "300 millimetres" and I multiply it by 10^9, the resulting variable would not contain 0x2BA7DEF3000 millimetres but 300000 meters.
Obviously it can be bad in some rare cases, but it would also have a lot of advantages: you can compare "data" variables in different compatible units (miles and kilometres, degree Fahrenheit and Celsius, joules and calories...) and it could deduce the unit of calculus (divide miles by hours and compare it to meters per second) and flags errors (compare kilowatt per hours to Amperes)...

A taste of Rust

mpr22 — Tue, 30 Apr 2013 07:24:47 +0000

A world where the 432 was designed by sane people instead of architecture astronauts would have been quite interesting, yes.

A taste of Rust

FranTaylor — Tue, 30 Apr 2013 06:43:05 +0000

It comes with an emacs mode.

A taste of Rust

FranTaylor — Tue, 30 Apr 2013 06:39:31 +0000

Yet another attempt to emulate a tagged-architecture.

The computing world would be a much different place if the Intel iapx432 project had been successful.

A taste of Rust

FranTaylor — Tue, 30 Apr 2013 06:33:28 +0000

Even the longest journeys start with a single step.

Fix the programming languages we have.

FranTaylor — Tue, 30 Apr 2013 06:31:36 +0000

That's rather akin to patching up your old VW bus for a trip to the space station.

Integer overflow

FranTaylor — Tue, 30 Apr 2013 06:20:53 +0000

You can do the same thing in any language that supports operator overloading. Write your own setters and you can restrict any type in any way you want.

A taste of Rust

cocoOS — Mon, 29 Apr 2013 01:51:04 +0000

any plan for a full support ide?...it's a pain in the ass coding a statically typed lang in a text editor...

I really like the language, the algebraic data types and the pattern matching looks great, but the syntax for lambdas is really ugly, why they chose the ruby lambda syntax instead a more clear and universal syntax line ((x : type) => ....//code here//) ....

A taste of Rust

mathstuf — Sat, 27 Apr 2013 20:04:48 +0000

This is one the main drawback of having your sentinel value(s) not being a discriminated union with your actual values. If it's not the sentinel, the code can only assume that it is valid. I suppose that in C, you could do some heuristics to check for plausible heap and stack pointers, but then if you see a pointer from some other allocator, you're going to reject perfectly valid pointers. Not to mention it being very not cross-platform.

Not just Ada...

ibukanov — Fri, 26 Apr 2013 23:18:10 +0000

> The thread-shared heap is not reference counted.

You are right, the ownership is fully tracked with the compiler.

> The thread-local heap is managed, though they currently use reference counting rather than mark/sweep garbage collection.

It is reference counting plus a cycle collector. For practical purposes it is just a form of GC with different trade-offs compared with a mark and sweep case. In Rust the reference counting allowed for simpler compiler implementation as one does not need to track the native register and stack roots. Plus for non-cyclic cases the garbage is collected faster. But when the cycle collector runs, it runs much slower than a mark-and-sweep due to significantly more complex algorithm.

Not just Ada...

neilbrown — Fri, 26 Apr 2013 22:20:12 +0000

This is not quite how I understand the documentation.

The thread-local heap is managed, though they currently use reference counting rather than mark/sweep garbage collection. That might change.

The thread-shared heap is not reference counted. The compiler tracks references of which there may only be on primary reference and possibly several borrowed references that can only exist within the scope of the primary reference. When the primary reference is dropped, the object is freed. No counting.

Not just Ada...

ibukanov — Fri, 26 Apr 2013 14:55:26 +0000

Rust model is to use referenced-counted objects for a thread-shared heap and separated GC-heaps for each thread. As long as one keep number of thread-local objects small, the GC pauses should be on the scale of microseconds, not milliseconds, as with typical global GC solutions.

A taste of Rust

VITTUIX-MAN — Fri, 26 Apr 2013 08:46:07 +0000

"valid pointer or NULL" as in:

#define VALID 0^1^0

Not just Ada...

phred14 — Thu, 25 Apr 2013 18:44:48 +0000

At least part of the idea has always been to mark those extensions as unsafe. You can't always be safe, but you can at least identify and minimize the times when you're not. You have a better idea of where the dragons are likely hiding.

Admittedly once you're messing with the stack frame, which I was with the interrupt handler, you've kind of unlocked the doors for the dragons, too. But I only played with the stack frame in that one example, knew it was a very risky thing, and tried to use extra care.

Not just Ada...

rahulsundaram — Thu, 25 Apr 2013 18:31:23 +0000

Did you mean Ceylon or Cyclone?

Not just Ada...

Cyberax — Thu, 25 Apr 2013 17:13:42 +0000

The elephant in the room here is garbage collection. It's impossible to make a real and usable safe language without garbage collector of some sort. You might try to get away with reference counting and region inference (like in Ceylon) but it soon becomes too problematic.

Not just Ada...

viro — Thu, 25 Apr 2013 14:55:35 +0000

And how safe does it remain after you add those extensions?

Not just Ada...

phred14 — Thu, 25 Apr 2013 12:21:45 +0000

There was a strong bout of "safe programming languages" 30 or 40 years ago, and it seems that Ada is the only barely viable survivor, with FreePascal also making a minor presence. Now it looks like there are emerging efforts to get to a "safe programming language" again.

Which begs the question... Would it be easier to "make C safe" or to "make Modula-2 or Modula-3 usable"?

I focus on Modula-2/Modula-3 because others have mentioned that Ada has certain deficiencies which ought to be fixed. But Ada is rather rigidly standardized, and though there is a process to eventually change it, that takes time and makes experimentation difficult. Modula-2/Modula3 could make a better test-bed or starting point, recognizing that those would need work, as well. They're also less complex to begin with.

Even the usability argument against the old "safe languages" may have some issues, because while as defined they may not have been usable, most vendors back in the day had significant extensions. Back in the 1980s I used JPI Modula-2 to write a TSR (MSDOS Terminate-and-Stay-Resident, for those who are not fossils like me.) that implemented a reentrant interrupt handler for low-level communications. I also interfaced to a C module for (at the time) high-performance graphics, and both read and wrote legacy binary data files. It could be done, and it wasn't that hard.

looks like Haskell

Tuna-Fish — Wed, 24 Apr 2013 20:36:36 +0000

There are many different kinds of speed. OCaml is very fast in *throughput*, but the differences in memory management strategies guarantee that Rust should always be able to promise less worst-case latency. In fact, Rust seems to sacrifice quite a bit of throughput to provide those better latency guarantees (among other things, the language promotes copying in many places where OCaml would be fine sharing), so I would expect OCaml to win most throughput benchmarks. However, if what you want is to guarantee that no task can take longer than 8ms to complete (fe. you want smooth 120Hz frame rates in a game), Rust should be better.

It's a tradeoff. Fundamentally, if a language or system wants to be really good on one metric, it has to sacrifice some of the other. OCaml and Rust choose different points, and there is nothing wrong with the choice of either. However, this does mean that there are some tasks where Rust is better suited.

Severe underestimation of dev laziness

mathstuf — Tue, 23 Apr 2013 19:53:08 +0000

> without having to write extra code at every point — which is what Rust forces you to do.

Rust allows you to say "this value cannot be null" with less words than saying "might be null" would take. Hopefully developers would prefer the former rather than the latter (I certainly do) which means that the checks don't even have to be written. If Rust had do-syntax from Haskell, checking results in a chain of nullable calls wouldn't even be necessary. I assume some common library will probably implement ">>=" and ">>" in Rust which I'd use in a heartbeat when developing Rust rather than check for None manually everywhere.

Fix the programming languages we have.

rahulsundaram — Mon, 22 Apr 2013 15:05:26 +0000

Well, a new programming language is certainly one type of "fix". Not everything can be retrofitted into existing languages due to design differences and backward compatibility.

Fix the programming languages we have.

mpalamara — Mon, 22 Apr 2013 14:44:37 +0000

I don't need another programming or scripting language. I need to fix the ones I have.

looks like Haskell

zooko — Mon, 22 Apr 2013 01:33:14 +0000

I think that's why it is called "Rust"! Because it was originally envisioned to be made up entirely of hoary old ideas that had already been proven out in other languages.

looks like Haskell

ballombe — Sun, 21 Apr 2013 15:12:27 +0000

Converting your code to tail-recursion give:

fib n = fibr n 1 1 where
fibr 0 a b = (a,b)
fibr n a b = fibr (n-1) (a+b) a

(thought there are much faster algorithms to compute this)

Severe underestimation of dev laziness

man_ls — Sat, 20 Apr 2013 08:37:31 +0000

That is what you might think about checked exceptions: at least the regular code does not have to deal with error conditions. It is however a bad policy: the empty catch() block can mask important error conditions and continue silently as if the process was successful, instead of failing.

With Java Null Pointer Exceptions are not checked (i.e. they don't force you to check for them with a try...catch), but at least it prevents the regular code to deal with the null pointer.

My preferred practice now is to leave exceptions as they are and catch them all only at the root level, logging them carefully. This is why I abandoned checked exceptions but in a very few cases. Catching all exceptions (including unchecked) and logging them also deals nicely with null pointers, without having to write extra code at every point — which is what Rust forces you to do.

Severe underestimation of dev laziness

k8to — Fri, 19 Apr 2013 19:43:26 +0000

It's a good point.

But the Rust example makes it seem that you can't say "i don't care if it's null", but rather have to write null-case code independent from access-case code. The null-case code could be degenerate, but the access-case code still can't access the null.

looks like Haskell

b7j0c — Fri, 19 Apr 2013 17:38:07 +0000

graphs have also been a problem for pure functional languages

looks like Haskell

b7j0c — Fri, 19 Apr 2013 17:36:50 +0000

right, but like String -> Text, laziness is another major legacy problem for haskell. how much of hackage has been built with the older thinking? how much of hackage is now merely replicated attempts to get mindshare for the latest Iteratee variant?

you'll never purge Strings or laziness (or bang annotations etc) from hackage, most of those packages aren't that well maintained. rust is the reboot haskell needs.

Ada should be mentioned when speaking of programming languages on safety

HiggsMechanism — Fri, 19 Apr 2013 15:01:00 +0000

procedure P (X : not null SomeAccessType);

Ada should be mentioned when speaking of programming languages on safety

andreasb — Fri, 19 Apr 2013 14:04:12 +0000

> Who catches this? the runtime or the compiler?

Out of range values are checked at runtime per the language specification and will raise a Constraint_Error exception when the check fails.

That said, a friendly compiler such as GNAT will print a warning when it can determine that something will unconditionally raise an exception at runtime.

> The Rust choice of forcing you to write code that checks seems quite sensible.

Ada's access types with null exclusion work exactly like that, as far as I can ascertain, only they just create warnings at compile time. Plus you get to have access types with valid null values if you so choose.

Attempting to dereference a null access will net you a Constraint_Error exception anyway, so a null exclusion just helps with pushing that exception back to the actual cause.

Severe underestimation of dev laziness

man_ls — Fri, 19 Apr 2013 13:34:51 +0000

Yes, Java also forces you to check for (checked) exceptions. We all know how well it has resulted: if I got a penny every time I have seen this in production code:

try {
  ...
} catch (Exception e) {}

I might have bought myself a few pints.

Integer overflow

ibukanov — Fri, 19 Apr 2013 12:18:12 +0000

> It's not like the python program will run fast enough that the overflow check being optimized would ever matter.

I suppose Python has to do overflow checks not only when doing arithmetics. For example, in Spidermonkey, JavaScript engine in Firefox, the code implementing a[index] operation had a path with an overflow check in the implementation code and that did affect benchmark performance.

looks like Haskell

rsidd — Fri, 19 Apr 2013 10:19:57 +0000

Yes, thanks, that's efficient though I'm not sure how easy it is to make it tail-recursive either. When it's more complicated stuff like matrix multiplication or Needleman-Wunsch, it's just too hard for me -- and, I suspect, for most "normal" people. Haskell has clearly proved that it is very useful for some people and some tasks, but I suspect that's the maximum for pure functional programming.

looks like Haskell

neilbrown — Fri, 19 Apr 2013 09:54:41 +0000

How about something like:

fib 0 = (1,1)
fib n = (a+b, a) where (a,b) = fib (n-1)

That's reasonably efficient - not sure how easy it is to make it tail recursive.

looks like Haskell

rsidd — Fri, 19 Apr 2013 09:39:07 +0000

Read "impossible" as "impossible for me to get my mind around" :) I'm thinking of nested loops in particular. Also things like the Fibonacci function where a naive implementation

fib 0 = 0
fib 1 = 0
fib n = fib (n-1) + fib (n-2)

is not just non-tail-recursive but incredibly inefficient. And every "functional" efficient version that I've seen is just too hard to understand (for me) by reading the code. And that's for a trivial beginner-level example.

looks like Haskell

peter-b — Fri, 19 Apr 2013 09:24:00 +0000

Given that every loop has an isomorphic tail recursive form, I suspect that you are running up against "ugly" much more often than "impossible"!

Integer overflow

k8to — Fri, 19 Apr 2013 09:20:20 +0000

Maybe so, but it definitely satisfies the "deals with overflows itself" part of the query.

As the language programmer you really don't have any reason to care. It's not like the python program will run fast enough that the overflow check being optimized would ever matter.

Integer overflow

ibukanov — Fri, 19 Apr 2013 09:12:49 +0000

> Python for example just overflows integers to non-machine representations,

I doubt the Python interpreter uses assembly code to detect if a*b overflows via checking the overflow control flag of a CPU. Rather I suppose it uses one of the tricks that C code must use for that. Those are slow compared with the assembly.

It is puzzling for me that modern C/C++ compilers do not offer compiler intrinsics to calculate a+b, a*b etc. together with the overflow status especially given that how trivial is to exploit many of overflow bugs and how non-trivial to write proper overflow detection without hurting performance.