Rust is surprisingly expressive

http://words.steveklabnik.com/rust-is-surprisingly-expressive

by steveklabnik • 13 years ago

199 146 13 years ago

words.steveklabnik.com

mpweiher4• 13 years ago

Good examples:

  2.days().from_now()   (Rust)

vs.

  2.days.from_now       (Ruby)

I'd probably still prefer Smalltalk:

  2 days fromNow.

It seems to me that many distinctions we still suffer from are quite arbitrary. Yes, having numbers be objects (boxed or tagged) is one way of achieving this sort of uniform handling, but you can also achieve it statically.

Just like you don't have to switch to a "scripting" language for expressive file manipulation:

  file:hello.world := 'Hello World!'.

EDIT: typo.

steveklabnik10• 13 years ago

It seems to me that many distinctions we still suffer from are quite arbitrary.

Agreed. And it's nice to see newer languages which bring these kinds of theoretical improvements into practical languages we as developers can actually use, rather than just as papers. I don't want to come off as anti-theory, I love theory. It's just nice to see it finally trickling down.

mpweiher4• 13 years ago

Yes, indeed. My last example is from Objective-Smalltalk [1], which straddles academia [2] and practicality [3]. The basic idea is that you really need both the practical application to show the problems and then the time to think about solutions.

[1] http://objective.st

[2] http://dl.acm.org/citation.cfm?doid=2508168.2508169, https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...

[3] http://metaobject.com (used in most products)

EDIT: added sentence about approach.

MichaelGG2• 13 years ago

I guess we'd call these "type extensions"? F# supports this just fine, and C# can do a bit, too.

Overall, I haven't found I need type extensions that much, if I have flexible function handling. It's the same level of expressiveness to write "fromNow 2 days". (fromNow having signature (int -> (int -> TimeSpan) -> DateTime). Or even "2 |> days |> fromNow" (fromNow being TimeSpan -> DateTime).

Actually, this example is pretty terrible, as even C#'s basic format would be "DateTime.Now.AddDays(2)" which seems pretty fine to me - add a top-level binding for now and it's on the same level of conciseness. Also, adding type extensions to integers for time seems quite ugly. Most 3rd party libraries I've seen don't use type extensions in a graceful manner, and end up slapping members on everything and it's just silly. (And I'm ignoring the fact that using .Now in .NET is rarely correct since it's rare when you don't want to use whatever random timezone the server's configured for, instead of UTC.)

bad_user8• 13 years ago

"2.days.from_now" is different from DateTime.Now.AddDays(2), because it can be broken in two parts:

- 2.days is a duration, or a time delta, or time span, or whatever you want to call it

- from_now is a method called on this duration value

This construct "2.days" is useful on its own. It's actually more useful than "DateTime.Now", as durations are often part of public interfaces, whereas usage of concrete timestamps is very often hidden. The equivalent in C# for it would be "new TimeSpan(2, 0, 0, 0)". That's much more unreadable than just "2.days" and often, instead of thinking about the problem, developers fallback to specifying time spans as Ints in seconds or similar.

On TimeZone, "2.days.from_now" is a timestamp. If the underlying library is not totally fucked up, like "java.util.Date" is, then it does have an attached timezone. Or in case this yields a Unix timestamp, it's really not a Unix timestamp unless it was calculated since 1970-01-01 00:00:00 UTC.

riffraff• 13 years ago

scala also allows, AFAIK,

    2 days fromNow

with the additional advantage compared to ruby/smalltalk that "days" is only available for ints in places where you import the extensions.

stiff3• 13 years ago

I don't think the ability to write expressions similar to natural language like "2.days.from_now" should be called "expresiveness". Real expresiveness is about what SICP calls "means of abstraction" and "means of combination", not necessarily about having very nice syntax. In general I think those considerations would benefit from distinguishing a bit more between syntax and semantics. As another example, I have been doing Ruby professionally for almost 10 years now, and despite this I have to strongly disagree with the conclusion of this quotation:

Python is a beautiful, clean language. But the same restrictions that make it nice and clean mean that it’s hard to write beautiful, clean libraries. Ruby, on the other hand, is a complicated, ugly language. But that complexity allows you to write really clean, nice, easy-to-use libraries.

The Ruby metaprogramming magic makes for really nice syntax, which is what made me choose it over Python all those years ago, but it complicates understanding of what's going on - as I matured as an engineer, maintained a codebase over several years, several times spend long hours debugging issues coming from metaprogramming pitfalls, I shift more and more to the Python approach of building APIs in the simplest possible way, as much as possible sticking to simple function calls and no really fancy metaprogramming just to get a cleaner syntax, e.g. compare Rails has_many :foo with Django's models.ForeignKey(Foo) and the internal implementations of those. Same thing with using "BDD" testing frameworks like RSpec vs. traditional assert stuff, what is the nice syntax worth if tricky bugs hit you where you most want to avoid it, in tests. Libraries like RSpec might be "nice", but they are certainly not "easy-to-use", and I don't think I would call them quite "clean", if I look at their source code.

In other words, while clean syntax is luring, in the long run clean and simple semantics is what I think is really important.

mpweiher4• 13 years ago

I don't think it's the similarity to natural language, but rather expressing things directly.

I'd agree that unconstrained metaprogramming can make code hard to read, and Ruby especially tends to go overboard. One of the goals of Objective-Smalltalk is to create a language with cleaner extensions points, making semantically consistent extension/adaptation easier. We'll see how it works out :-)

Touche3• 13 years ago

Exactly, in Rust you can't (easily) pass in a named function into a map because of all of the pointery stuff going on. Rust clearly has its uses but if you can't write high order functions then expressive it is not.

catnaroek14• 13 years ago

You can write higher-order functions in Rust - in fact, much of the standard library relies on them. What you cannot do is use named and anonymous functions interchangeably.

steveklabnik10• 13 years ago

Real expresiveness is about what SICP calls "means of abstraction" and "means of combination", not necessarily about having very nice syntax.

I was thinking specifically of the expression problem:

The Expression Problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts).

http://en.wikipedia.org/wiki/Expression_problem

Now, I'm not saying Rust solves the expression problem, nor that what I'm calling "expressiveness" here maps to it, even. Just that we can easily argue over what "expressive" means.

Libraries like RSpec might be "nice", but they are certainly not "easy-to-use", and I don't think I would call them quite "clean", if I look at their source code.

The whole point of the quote is that the source code is ugly. I think we're in violent agreement here.

stiff3• 13 years ago

This paraphrased quote was quite ambiguous to me, but the conclusion of having preferred Ruby in the end without further commentary makes it seem like the nice syntax is worth the complications, while I would say those "intuitions" of initial liking/disliking a language because of syntax are completely misleading and should not be trusted.

Also, it's not only about ugly internals, I wrote several RSpec tests that looked like a perfectly reasonable "natural-languigish" expression of what I wanted to, but did not work at all, because of the tricky mechanics underneath happened not to support this particular combination of incantations. In the end you have to understand all the ugly internals to know which of the "nice" calls will work and which not, and I all the time see people shooting themselves in the foot because of not having this understanding, e.g. not wrapping some bit in a lambda in Ruby and having something evaluated at the wrong time etc.

vectorpush• 13 years ago

Correct me if I'm wrong but isn't the successful imitation of natural language an example of "means of abstraction" in practice?

stiff3• 13 years ago

You can write 2.days().from_now() in almost any OO language which allows extending primitive types, so it isn't really very impressive. There are lots of example of languages with very powerful means of abstraction / composition and not syntax people commonly consider pretty or natural: Lisp, Erlang, Prolog. There are also programming languages which imitate natural languages to some degree and aren't very expressive, like COBOL.

catnaroek14• 13 years ago

Cannot upvote enough!

Rubyists try too hard to emulate natural language syntax, but in the process forget that natural languages are not particularly clean - in fact, more often than not they are highly dependent on contextual information, not just semantically, but even syntactically.

Ultimately, natural languages and programming languages serve very different purposes: communication in natural languages is highly dependent on context for resolving ambiguity (e.g., if we took this discussion to a non-programming forum, everybody else would be like "WTF is going on?"), while programming languages are all about making it possible to be pedantically precise without reducing convenience.

luuio• 13 years ago

What kind of people still get excited over a language's ability to do this?

* Category functions in Objective-C

* .NET extension methods

natrius• 13 years ago

Django's models are entirely fancy metaprogramming behind the scenes. When it works, it works, but the code that implements it is not easy to understand by any means.

Django models are definitely more self-documenting than Rails models, which seems like a result of the Python legibility culture.

Daishiman• 13 years ago

Yes, but Django model metaclass magic is context-independent; the logic resides entirely in the model and does not affect the rest of the environment, which is something that Ruby's includes can do (and give you no warning when method overloads break stuff).

bascule• 13 years ago

You should really watch Ola Bini's talk "Expressing Abstraction - Abstracting Expression" from Strange Loop 2012:

http://www.infoq.com/presentations/Language-Expressiveness

tl;dw: there are many types of expressiveness in programming languages, and they're all important.

Likewise syntax is important too, but often downplayed by the PLT community. Case in point: your post!

pcwalton6• 13 years ago

In other words, while clean syntax is luring, in the long run clean and simple semantics is what I think is really important.

I agree. And I think that Rust has one of the simplest semantics around in programming languages: the method resolution rules are quite simple, because there is no method overloading and all extension methods have to be explicitly imported to be used. These two restrictions are important for maintainability: the former means that the compiler "never guesses"—multiple applicable methods are a compile time error—and the latter means that you never have to guess about where a method comes from, because it was always defined either alongside the type or defined as part of a trait that was explicitly imported at the call site.

foobarian• 13 years ago

A former developer at our company was someone who was really excited about using Ruby metaprogramming features to the fullest extent possible to enable concise code. He wrote a bunch of subsystems based around a few custom frameworks.

Whenever a project takes me into modifying that codebase I get that sinking feeling you get when you realize you left your wallet at a restaurant or that your car has been towed.

hamburglar• 13 years ago

Sometimes I think I must be a humongous idiot because adding a "days" method to Fixnum smells like the stupidest, most counterproductive, cutesy bullshit to me, but some pretty smart folks think it's great (that's a compliment btw).

Stuff like this is the opposite of expressive to me because cute expressions that read like english scream "please take a moment to analyze this and make sure it does what it sounds like." I am instantly suspicious of code that is so expressive that you can just intuit out its purpose without thinking it through. Code is too subtle for treating it that way.

jhspaybar• 13 years ago

This comment makes no sense to me, you don't like how clear it is? Somehow the clarity causes you to distrust what is actually happening?

Every time I have to write something like

Calendar cal = Calendar.getCalendar();

cal.setDate(new Date());

cal.addDate(-2, Calendar.DAYS);

Date date = cal.getDate();

I want to claw my eyes out. Is this what you consider more clear, less cutesy, somehow more productive than just 2.days.ago ?

wheaties• 13 years ago

How about this 2.days.from_last_update? What does it do? What is going on with "from_last_update"? Is it actually reaching out to a database to find the last updated value? Which database? How do you configure it?

All these questions and more are why you should question "english as a DSL" methods. Granted, there's a ton of great libraries out there which do this well. Take Unfiltered's handling of parsing out requests for pattern matching:

  case POST(Path(Seg("api" :: "calls" :: name :: Nil))) =>

this is "englishy" without having you scratch your head. I've also seen

  case POST(Path("/api/auth")) & Authenticate(user) =>

which then causes a DB access to happen in a configured implicit value. Now try to reason out why something is not hitting a URL or being denied when you first get into a project. Unless there's someone to explain it to you, it just happens like "magic."

TL;DR How much magic do you want to deal with?

ubernostrum• 13 years ago

Years ago I got into an argument about these sorts of "beautiful" and "intuitive" APIs:

http://www.reddit.com/r/programming/comments/21pnl/just_say_...

I still do not have good answers to the questions I asked in that first comment.

tizoc• 13 years ago

From where is that?

This is how it works in C# (and .NET in general)

DateTime.Now.AddDays(-2)

Not wanting to overload integers with calendar functionality doesn't mean you have to make it so cumbersome.

Edit: typo

MichaelSalib2• 13 years ago

I feel the same way that hamburgler does. For me at least, you java calendar code looks horrible. I'm thinking something more like

    date.today() - timedelta(days=2)

philwelch7• 13 years ago

You're conflating different things here. `Date.today - DateTime.days(2)` would be just as clear as `2.days.ago` without muddling the semantics of integers.

steveklabnik10• 13 years ago

As I mentioned in the post,

Now, I should say that I almost never use 2.days, but the point is that it’s a benchmark of expressiveness: if you can write it, you can do all sorts of other flexible things.

I tend to use MiniTest, not RSpec. But I'm very glad RSpec can be built.

danneu• 13 years ago

I use https://github.com/sconover/wrong with MiniTest which might qualify as another example of Ruby "tricks" to achieve a different interpretation of expressiveness.

The result is the ability to express

    assert { :apple == :orange }
    assert { [:apple, :banana, :pear].include? :orange }

and let the computer figure out the appropriate error message and expected-vs-actual diff.

kybernetikos3• 13 years ago

I think I agree with the thrust of what you are saying here. Just as English has rules with what you do with nouns and verbs etc, code has rules too that are different to English.

2.days().from_now()

says that we are performing the action 'days' on the object '2'. What could that possibly do? Well there're a bunch of options and none of them are obvious. It's weird and counter-intuitive. And then we go and perform the action 'from_now' on whatever the result of that was.

I don't mind 'fluent' style interfaces as long as they don't mess up the normal meanings of what objects and methods are, but sadly they usually do. Another classic sign of a bad interface is that with many of these fluent interfaces it's not obvious whether a particular thing should be a chained method call or argument, and if it's an argument, whether it should be got by calling a method, using a field or what.

Code should read like clear code. English should read like clear English. These are not the same things, and efforts to make them the same usually make a mess of both.

xixixao• 13 years ago

You're saying `code` but what you really mean is "Java" or your favorite OOP paradigm. If someone comes up with different rules for what `2.days()` means then they are valid rules (and we can discuss whether they provide benefits to the other ones).

wycats5• 13 years ago

In Rust, you have to import a trait (in this case active_support::Period) into the file that uses 2.days(). It's not a global change.

If you see 2.days(), you know where to look for the definition, and the type system means that you can easily learn what 2.days() returns. In this case, 2.days() returns a `TimeChange` object (https://github.com/wycats/rust-activesupport/blob/master/dsl...).

`TimeChange` implements a `from_now` method here: https://github.com/wycats/rust-activesupport/blob/master/lib... which returns a `Time`.

This is a lot easier to reason about than global modifications to Fixnum in an untyped language.

matthewmacleod5• 13 years ago

Code should read like clear code. English should read like clear English. These are not the same things, and efforts to make them the same usually make a mess of both.

This stinks of principle over pragmatism.

Using the sugar offered by expressions like this requires a bit of knowledge of the development environment. I accept that it's a bit of a different syntax from some other languages, but that doesn't make it unclear at all.

Speaking to Ruby (where ActiveSupport is from), we all know that it's a language that focuses on providing flexible syntax and "multiple ways of doing things", in contrast to some other languages which restrict flexibility to provide more consistently structured code. I don't think it's a bad thing at all to have these options available, and I often find my intentions are much clearer when writing, say:

  if post.created_at < 5.minutes.ago

as opposed to Python:

  if(post.created_at < (datetime.now() - timedelta(minutes=5)))

or Objective C:

  NSDate *now = [NSDate date];
  NSDateComponents *delta = [[NSDateComponents alloc] init];
  [delta setMinute:-5];
  NSDate *fiveMinutesAgo = [[NSCalendar currentCalendar] dateByAddingComponents:delta toDate:now options:0];
  if ([[post created_at] compare: fiveMinutesAgo] == NSOrderedAscending)

That's where the magic comes in, and it makes Ruby ideal for things like web templating, while perhaps making it less suitable for other uses.

TLDR: various constructs like this have their place, they're not inherently bad, but do require knowledge of the tools.

pcwalton6• 13 years ago

2.days().from_now() says that we are performing the action 'days' on the object '2'. What could that possibly do?

It does what the language definition says it does: it tells the compiler to search through traits that were explicitly imported to find a method called "days" and calls that. (Since "int" is a built-in type, it has no methods except for those provided via traits that were imported, so traits are the only potential source of these methods.) If there is more than one matching method, Rust never guesses: it instead signals an error.

I don't mind 'fluent' style interfaces as long as they don't mess up the normal meanings of what objects and methods are, but sadly they usually do.

In this case they don't. It falls out of what traits and methods already provide in Rust.

Camillo3• 13 years ago

I call this phenomenon "language skeuomorphism". See this comment I posted some time ago: https://news.ycombinator.com/item?id=5056667

username223• 13 years ago

The folks who "'think' this is great" are the same folks who self-submit their blog entries to news.ycombinator.com: self-promoting quacks. Bournegol has been around for awhile:

http://oldhome.schmorp.de/marc/bournegol.html

lmm• 13 years ago

I found this a lot less problematic in scala with IDE support. You can write 2.days, with appropriate imports, but the IDE will highlight the implicit conversion on the 2 (a green underline seems to be the standard visual representation), and you can click through to the definition.

lmkg• 13 years ago

I think it basically comes down to trust. Can you trust that the person who wrote the library isn't a dingbat, and that they've thought out the edge cases and composability of the interface they've designed, and that they've taken care that code actually does what it looks like it does, and confusing cases are either inexpressible or at least look confusing so you know you have to look closer. In short, can you trust the author to design interfaces well.

Personally I don't think it's inherently good or inherently bad, it's just one of those things that makes good code better (concise & expressive) and bad code worse (inscrutable & brittle). Glass-half-full and glass-half-empty are both valid opinions on the matter, and I strongly suspect which way you leans towards depends heavily on the quality of other people's architecture that you have to deal with on a daily basis.

brandonbloom• 13 years ago

Can you trust that the person who wrote the library isn't a dingbat

Almost never.

philwelch7• 13 years ago

"Let's just throw away the single responsibility principle and give Integer a method that multiplies it by the number of seconds in a day, and another one that adds it to the current day to get a new Time or Date object. Obviously that's something that an integer should be concerned with."

matthewmacleod5• 13 years ago

That's kind of the philosophy of Ruby though, and ActiveSupport by extension.

Where it makes code clearer and more concise, or where it simplifies an often-used idiom, and where it outweighs the benefit of sticking to principles—as I believe it does here—then breaking those principles is acceptable, in languages where coding conventions support this.

steveklabnik10• 13 years ago

https://news.ycombinator.com/item?id=6976450

jshen2• 13 years ago

We must not mistake principles and guidelines for absolute rules. I'm not judging this particular case, but I see the SOLID guidelines treated as absolutes far too often.

seivan• 13 years ago

Objective-C

@(2).days.fromNow;

@(2).SH_days.SH_fromNow;

dahlberg• 13 years ago

Why is the string representation of:

  2.months().from_now()

printing a date one year in the past?

  date: active_support::date::Date{year: 2013, month: 2u, day: 28u}, hours: 0u, minutes: 59u, seconds: 6u, nanos: 243388962u

jimmaswell• 13 years ago

Why would days be a method of an integer? It feels out of scope shoving date/time stuff into integral datatypes.

icebraining• 13 years ago

That's how they do it in Ruby, but in a language with a different grammar, you could parse '2' as a different datatype depending on how it's being used. In any case, the Rust example is fairly clean, since it only injects the methods for the code that loads the Period trait.

klibertp3• 13 years ago

The basic idea is that objects should know how to represent themselves. In Smalltalk every Object implments writeOn: method, which gets a stream and prints self on this stream.

By extension, if an object knows how to convert itself into another object, it implements a method for doing do. In Smalltalk there is a convention of putting all such methods inside "converting" protocol. For great example of how is this useful you can look at the Collection and it's subclasses in Smalltalk - all collections have many "asOtherKindOfCollection" methds, which are either inherited or implemented, depending on a collection. It's great to be able to send "asSet" to any collection that comes your way and the way Smalltalk does it is natural in purely object oriented languages.

That and the fact that creating IntsToRange or StringToDayOfWeek "static" classes is actually even worse leads to the design where Integers have `to:` and `days` methods.

Actually, there is one more probable cause: in Smalltalk and some other languages extending already defined types is easy, really easy, easier even than creating a new, empty class. The methods are grouped into "protocols", which are grouped into packages and it's - not quite - largely orthogonal to the classes. Combine that with powerful IDE, VC support (Monticello, Metacello) etc. and you have no reason whatsoever not to extend even the most basic classes.

philwelch7• 13 years ago

The question is what "2.days" actually returns. IIRC, in ActiveSupport it returns an integer number of seconds. Is that a sensible convention? If you had another class representing an span of time (with or without any absolute calendar reference) that an Integer could convert into, that might be a cleaner design. But even in that case you wouldn't necessarily have a method on Integer to confer it to a TimeSpan; you'd initialize a TimeSpan with an integer argument.

In general I find it cleaner when less primitive classes can represent themselves as more or equally primitive classes, but not vice-versa. to_integer, to_float, to_list, to_boolean, etc. But on the other extreme, if your application entails establishing database connections, implementing String#to_database_connection would be ridiculous.

For me, integers are much more primitive than date and time objects. `2.days` would be equivalent to implementing `2.meters` in a CAD application, but I suppose you might be OK with that.

But even granting that an integer can transform itself into a representation of a time span, i.e. `2.days` is okay, `2.days.ago` is right out. That's not just an Integer representing itself as a span of time. Now all of a sudden Integer has to have knowledge and, even worse, opinions about the current date and time (which is one of the most hazardous boundary cases in all of software).

seth1010• 13 years ago

While I don't think that syntax is that important, I am fond of sugar.

Because I've been working in D for a while, here's how you'd do it in D.

    import core.time: Duration, dur;
    import std.datetime: Clock, SysTime;

    Duration days(int number) {
      return dur!"days"(number);
    }

    SysTime from_now(Duration duration) {
      return Clock.currTime + duration;
    }

    void main() {
      import std.stdio: writeln;
      writeln(2.days.from_now);
    }

Runnable pastebin link: http://dpaste.dzfl.pl/9b84f820

mcguire• 13 years ago

I haven't really looked at D in a long time, so I'm not clear on what's going on here.

Is D allowing you to write the function call "days(2)" as "2.days"?

(As an aside, Nimrod allows you to do specifically that; first-arg.function-name(...) == function-name(first-arg,...).)

mattmanser2• 13 years ago

Extension methods in C# do the same thing and have been around, what 5ish years now? Since .Net 3.5.

Here's an example implementation:

    public static class DateExtension
    {
        public static TimeSpan Days(this int daysCount)
        {
            return new TimeSpan(daysCount, 0, 0, 0); //days, hours, mins, secs for those wondering
        }

        public static DateTime FromNow(this TimeSpan addTime) 
        {
            return DateTime.Now.Add(addTime);
        }
    }

usage is the same as Rust:

    2.Days().FromNow();

Basically if this impresses you, you really should give modern C# a whirl as there's a lot more you can do than that.

Much of how it does stuff now is how my perfect language would do it. There are bits of Ruby I love, and Rust is looking more exciting to me than Go, but the C# team really have done some amazing work.

steveklabnik10• 13 years ago

I am certainly not implying that Rust is the only language that supports this kind of thing. Haskell is where I first saw some of this. I'm just happy that Rust is doing it well.

C# is a great language, but I don't use Microsoft technology, and it's effectively Windows only.

majorsc2noob2• 13 years ago

I run C# in production on Mac OSX, IOS and Android phones. What do you mean by Windows only?

catnaroek14• 13 years ago

One problem with extension methods is that you cannot statically express the idea that multiple classes implement the same extension methods. In particular, you cannot make a generic whose type parameter is guaranteed to implement a given set of extension methods. This, in my opinion, reduces the usefulness of extension methods from "potential game changer" to "mere syntactic sugar".

bad_user8• 13 years ago

You mean type-classes? Scala and Haskel have them. It's certainly nice to be able to do statically type-checked stuff like:

   list.sorted
   list.max
   list.sum

The problems with languages like C# (or Java) go beyond the lack of type-classes or similar. For example, given a type such as List<T>, you're restricted to define methods only "for all T", as these languages don't allow you to define methods only "for some T". Examples include methods such as "sorted" or "max", relying on type T implement some sort of Ordering interface, or "sum", relying on type T to be some sort of Number.

So even if you would have a way to specify that types X, Y and Z have implementations for this and that set of extension methods, it would still be of somewhat limited use, given that one wouldn't be able to also use this in code making heavy use of generics, much like how interfaces themselves aren't used much in code making use of generics, because code making use of generics is usually some dumb Container<T>, where almost nothing about T is known.

The best part about type classes is that you don't have to control/modify the type's implementation, in order to make it implement a certain type-class. Type-classes are like open interfaces. If the builders of C# never bothered to provide you with some common interface you want for built-in types, that's OK, because you can make one up.

Scala also has implicit conversions and "view bounds". Implicit conversions go beyond extension methods and View Bounds allow one to specify that some type X can be viewed as some type Y (either Y inherits from X, or there exists an implicit conversion from X to Y). Something like:

    def sample[X <% Y](item: X) = item.callMethodFromY

But these are mostly useful for builtins and deprecated for general-purpose usage in favor of context bounds (type-classes). It's still nice that builtins such as Array[T] is viewable as a Seq[T] and Strings are viewable (in true FP tradition) as sequences of chars, allowing one to do this:

   "some string".map(_.toUpper) // => "SOME STRING"

What's interesting about the above example is that mapping over a string, produces a string, highlighting another Scala feature that goes beyond type-classes:

   "some string".map(_.toString) 
   // => Seq(s, o, m, e, " ", s, t, r, i, n, g)

This is the CanBuildFrom pattern. See this awesome example from M. Odersky himself: http://stackoverflow.com/a/1728140

samirahmed• 13 years ago

Extension methods are a godsent in C#. Really allow you to write extremely expressive code.

I cannot agree enough. This is not new for any C# dev.

Expressiveness is not as great as ruby, but certainly on par with Rust

LINQ extension methods by Jon Skeet - https://code.google.com/p/morelinq/

I would recommend reading this stackoverflow post to see some great extension methods.

http://stackoverflow.com/questions/271398/what-are-your-favo...

eranation• 13 years ago

My personal choice for "statically typed Ruby" is actually Scala or Kotlin. Scala has its drawbacks, especially the compile time, (which is getting better) but both have similar expressiveness when it comes to mind blowing library usage. (Although sometimes arguably in the expense of potentially complexity of the language when it comes to being able to writing such elegant libraries) I found it similar to the OP's argument regarding python vs ruby. Scala as a language might be a very subjective and divided topic, but using it with the right libraries can be very expressive just with added static typing.

enneff• 13 years ago

If I read it right and the article cites the ability to add a method to the primitive number type as "expressive", then that's a pretty narrow view of expressivity. More examples would help.

wycats5• 13 years ago

I wrote the original implementation.

One thing worth noting is that the implementation isn't globally extending `uint` with `.days()`. In order to write `2.days()`, you need to first import the trait that provides the implementation.

From that perspective, it's not much different from importing a function like `days_from_now` that you call as `days_from_now(2)`.

jemeshsu• 13 years ago

So it is a demo that you can use Rust metaprogramming to make Rust look like Ruby. I hope this would not become idiomatic Rust.

jimmyhmiller2• 13 years ago

In clojure you could write this.

(-> 2 days from-now)

The great thing is that you don't have the weird semantic problems that the rust or ruby examples have. There are just two functions here, days and from-now.

wycats5• 13 years ago

That's essentially how traits work in Rust. You need to import the trait into your scope, and 2.days().from_now() is essentially sugar for days(2).from_now() where days() returns a TimeChange object.

jimmyhmiller2• 13 years ago

Don't get wrong, rust looks fascinating. I realize that the syntax is basically sugar, but from what I understand is that you are still adding a method to a type. Here's a snippet from the code.

    fn days(&self) -> TimeChange {
        TimeChange::new().days(*self as f32)
    }

So while you are right, it is basically sugar for days(2).from_now(), but you couldn't call the function that way. It must be attached to an instance of an uint.

Also in order to get the English looking version you have to implement those function specially using traits. Whereas with the clojure version they are just normal functions, but the threading macro gives you that English readability you are looking for.

nwmcsween• 13 years ago

I dislike all these 'expressive' or how abstract rust as a language can be from what it's trying to achieve which is to be a 'systems programming language' on par with c (c++ is not the same as c). Show the resulting assembly for both a C version and a Rust version, now map both the rust version and c version to the resulting assembly.

copx• 13 years ago

Rust is meant to replace C++, not C. The original motivation was that the Mozilla devs were sick and tired of all the subtle ways bugs can sneak into a large, complex C++ code base.

The ultimate aim is to write the nextgen browser engine not an operating system kernel or some embedded code for a system with 4kB RAM.

steveklabnik10• 13 years ago

... though you can absolutely do the kernel stuff too.

maninalift• 13 years ago

The example presented in this post is neither a great example of what Rust can do nor an elegant solution to the particular problem of dealing with dates and times.

For a much further-reaching solution to this problem look at C++ user-defined literals, combined with what Bjarne Stroustrup calls "type rich programming".

now() + 3days + 21s + 102ms

This is not to say that c++ is the only language that can do this (although it does do it very well).

See the following video for a simple overview (apologies for toe-curling introduction): http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...

...also the video above is worth watching just for the vector vs. list comparison.

sklivvz1971• 13 years ago

In other news C# is exactly as expressive as Rust and Ruby...

    void Main()
    {
	Console.WriteLine(2.Days().Ago());
	Console.WriteLine(4.Days().FromNow());
    }
     
    //This can be a library, mmkay?

    public static class Extensions 
    {
	public static TimeSpan Days(this int days){ return new TimeSpan(days, 0,0,0); }
	public static DateTime FromNow(this TimeSpan howMuch){ return DateTime.Now + howMuch; }
	public static DateTime Ago(this TimeSpan howMuch){ return DateTime.Now - howMuch; }
    }

Results in:

    26/12/2013 22:05:10
    01/01/2014 22:05:10

Is there a better example?

mythz• 13 years ago

    public static class Extensions {
        public static void Print(this object o) { Console.WriteLine(o); }
    }

    2.Days().Ago().Print();
    4.Days().FromNow().Print();

allochthon• 13 years ago

Static v. dynamic typing aside, one thing I love about Ruby is the syntactic ambiguity of a local variable versus a method call, in which parentheses are not needed.

RodgerTheGreat• 13 years ago

In Factor:

  2 days hence

  4 weeks ago

etc. http://docs.factorcode.org/content/article-calendar.html

stcredzero• 13 years ago

For the most part, I’d found the complaints about dynamic typing from the static typing camp to be very FUD-y. I very rarely get TypeErrors in my Ruby code. Refactoring generally isn’t very difficult.

But slowly, this has started to change. I think that it’s that I tend to do more infrastructure and plumbing work now. I’ve run into more and more situations where types would be helpful, or picking the mutable state path has caused headaches.

Explaining the attraction of dynamic debugging to static type die-hards is a lot like explaining the attractions of static typing to dynamic programming die-hards. You can only get a sense of what the other side is talking about through lots of hands-on experience. Where it's really valuable is often an edge-case, but often it's a really expensive edge-case! (Goes both ways.)

This from an old Smalltalker. If you do enough Smalltalk, especially in a large established code base, you eventually see situations where you wish there were type specifications. However, you still wish that more statically compiled language people were more open minded and less knee jerk when you talk about the magic you can do. (Which also means that the open minded ones are particularly valuable.)

Rust is surprisingly expressive

Related Stories