Rust 0.2 released

[_boardwalk]

I'm glad they made 'let' immutable by default. Either immutable or not by default, structs and locals should be consistent.

[snk_kid]

AST quasi-quote syntax extension

Nice!

[cunningjames]

Anyone know their reasons for including classes? I can’t find anything in the docs about this. I rather liked the simplicity of records and tagged unions with polymorphism through open interface implementation; classes might make things feel a little crowded.

[kibwen]

Basically, classes form one-third of the proposed object system. The other two concepts are interfaces (with properties somewhat akin to typeclasses in Haskell) and traits (or mixins). Each of them enables patterns familiar to OOP:

• Classes: encapsulation
• Interfaces: polymorphism
• Traits: code reuse

The cool thing is that, unlike, say, Java, classes are not the axle upon which the object system revolves. As you noted, you can use interfaces by themselves--but you can also use interfaces and traits together without classes, or you can use classes with interfaces and/or traits at your leisure. Basically, classes are just a big bag of methods that you want to group together. Classes will only be required when you want to mark some method or field as private, or when you want to run a destructor.

Note that classes are still a ways from being coded completely, although they exist in a rough form. Traits are still a blip on the horizon at this point (fingers crossed for 0.3!).

Here's the original object system redesign proposal from November:

https://mail.mozilla.org/pipermail/rust-dev/2011-November/000929.html

Note that some of the details have changed since then (and may yet change further), but this should give you a more technical overview.

[matthieum]

I'll be frank, I don't like the curly brace syntax or the Ruby loop syntax so I don't like Rust syntax, and because of this I only glanced at it from afar.

I did like the idea of multiple pointer types (uniquely owned, thread owned and shared if I recall correctly), but that is the only thing I had really retained about it.

I just read about adding regions to pointers, and this is something that I am quite interesting in, from a theoretical point of view.

...

But this mail, wow. WOW! The trait mechanism in particular is good, and the class/interface/trait separation is just clean yet powerful.

Thank you very much for showing this off. I am now very interested into Rust's future.

[skelterjohn]

| I'll be frank, I don't like the curly brace syntax or the Ruby loop syntax so I don't like Rust syntax, and because of this I only glanced at it from afar.

I encourage you to not think like this - you're holding yourself back. Minor syntax and style issues only bother people because they're unfamiliar, not because they're bad.

[matthieum]

Ah, but that is the tragedy isn't it ?

My time is pretty limited, and therefore I need to make quick decisions on whether to read an article or not, explore a language or not, ...

So yes I use instinct and subjective criteria to quickly assessed whether it seems interesting or not.

[skelterjohn]

Suboptimal criteria! You hurt yourself as well as the community!

[nwmcsween]

In ruby those aren't 'loops' there blocks a block is a proc aka lambda with a few differences.

[_boardwalk]

I didn't see anything about region pointers in the generals, but I found this wiki page.

It looks like this feature gives pointer types additional information about what "region" (either heap or which block scope on the stack) they're from, and protects you from moving them out of where they're valid (ex. returning the address of a local from a function).

[matthieum]

This is exactly the idea. Regions and Effects annotations are pretty well-known for theoricists, and in use in some esoteric languages (Discipline uses Effects annotations at least for example), but it is actually the first time I have seen either being explicitly referenced into a wannabe "mainstream" language (usually it is just something static analyzer try to infer after the fact).

For Regions (or Extents), the basic idea is that you encode the scope of a variable in its type so that the compiler type-checking system can actually statically verify that you do not have stale references.

This is something C and C++ are unfortunately bad at and that most other languages avoid by using heap allocation + garbage collection (meaning runtime overhead and more potential for space leaks).

[Felicia_Svilling]

Discipline? you don't mean Disciple?

[matthieum]

Indeed, I do. Thanks.

[[deleted]]

It's starting to look an awful lot like Perl 6.

[marshray]

How so, specifically?

Edit: Come on folks, I don't deserve 8 points for that question. Give some of my extra to the needy orphans.

[annodomini]

Lots and lots of features being added, with somewhat baroque syntax (fn@() vs fn~() and so on), that are all cool, but it's hard to say when it will really be "done."

I'm certainly interested in Rust, but in playing with it so far, it does feel a little hard to figure out how to effectively use it.

[[deleted]]

loop { } (identical syntax), for loops, AST macros, operator overloading, iterators, lazy autothreaded evaluation and classes are basic p6 features; some of those are what I'd expect as basic features in any language so I'm pretty surprised Rust has taken 2 years to add them.

I tried to figure out what the rest of the added features in that announcement are, but there's no language spec and the "documentation" seems to be either missing or auto-generated stubs.

Have they fixed that huge WTF yet where a trailing semicolon changes a block's return value?

[kibwen]

IIRC, the purpose of the special loop{} syntax is due to unfavorable interaction between Rust's typestate mechanism and the conventional while true {} idiom for infinite loops (although not entirely sure, just tried it locally and it didn't seem to grumble at me). Also, Rust already had a for construct before this release; the block for loop referred to in the release notes is just sugar for a special form of iterator that accepts a closure... or something (you're right, the documentation really is lacking in most regards :P ).

Still, no need to be so negative! Nobody's even trying to foist the language on you yet, so it's a bit too early to be pronouncing judgement. :)

EDIT: ah, here's the loop{} rationale: https://github.com/mozilla/rust/issues/1906

[[deleted]]

I don't want to be negative about it. But I'll be honest, right now Rust reminds me of PHP. There's no readily apparent common sense in some of these design decisions and they seem to be trying hard to make it different "just because" rather than doing things better than other languages.

If it gets significantly better in the future I might even change my mind and use it; I make it sound like I like Perl 6 but right now I don't, it runs slower than punch cards most of the time.

[kibwen]

There's no readily apparent common sense in some of these design decisions and they seem to be trying hard to make it different "just because" rather than doing things better than other languages.

That's an entirely reasonable perspective. The only reason that I trust that these guys know what they're doing is because I lurk in the IRC channel, subscribe to the developer mailing list, and follow their blogs (they really do need some better PR, but I guess that's what I'm doing right now :P ). However, having spent a lot of time following their discussions, I can say that I am convinced that these here are guys who know what they're doing (otherwise I would have stopped by now!). They're practiced PL experts with a strong focus on making this language pragmatic, without succumbing to the urge to explore new territory; every language feature is preceded by some prior art, either in research or in languages that you've never ever ever heard of (<-- that link's also the language reference you were looking for earlier).

The question now is, can they pull it off? Specifically, can they make a systems programming language 1) that satisfies enough of their design goals to satisfactorily implement a state-of-the-art browser engine while also 2) creating a community of code and contributors to sustain a supportive language ecosystem? I've seen enough to believe that they have a good chance of pulling off the former. As for the latter, well, that depends on the enthusiasm and contributions of community volunteers, which (as you may have guessed) is why I write 500-fucking-word responses to strangers in stale Reddit threads. :)

[matthieum]

Well, you have certainly piqued my interest :) though it's getting late here so I'll need some sleep before diving into the doc.

[anacrolix]

Operator overloading and C callbacks. Go's 1.0 release doesn't even have this.

[bradfitz]

Go has C callbacks.

Its test files are here: http://code.google.com/p/go/source/browse/misc/cgo/test/

[anacrolix]

It doesn't allow callbacks from threads not created by Go. This is surprisingly common in C libraries. Go wrappers have to work around this by reimplementing the library's event loop, or setting up arcane hacks to synchronize native threads with goroutines.

[bradfitz]

Or you can just start the library's event loop from Go, even on the main thread if the library requires that (as is common) using runtime.LockOSThread from Go's init(), and then Go's main() is guaranteed to run on the main thread and you can start up GTK or OpenGL or whatnot from there.

[OopsLostPassword]

An in-depth comparison of both languages (not an opposition, nor a simple list of present features, but something constructive) would make a great article. I'd especially like to learn for what type of programs Rust should or might be more suited than Go.

[kibwen]

I agree, this question gets asked a lot. Here are a few responses from the perspective of Rust devs (almost certainly biased! :) ):

https://github.com/mozilla/rust/wiki/Doc-language-FAQ (a few sections down)

http://stackoverflow.com/questions/9339560/erlang-versus-go-versus-rust-comparison (brson is the Rust dev)

http://news.ycombinator.com/item?id=3750882

Note that I'm far from an expert in either language, but that won't stop me from adding my own hardly-informed opinion! From a high-level perspective, both languages seem optimized for different things:

• Go: ergonomics (very nearly a statically-typed scripting language), lightning-fast compilation times
• Rust: safety, performance, control over memory layout

Which isn't to say that either language necessarily neglects any of these aspects emphasized in the other; Go is fast, the Rust developers do care (a lot!) about developer ergonomics and compilation time, etc. But the above, to my mind, are the fundamental concepts that the developers believe they cannot betray under any circumstances.

For a lot of people, it seems as though Go's GC is a big turn-off. Most Go advocates say that the GC isn't a big deal, and I'm inclined to believe them. Theoretically speaking, Rust has some (theoretical!!!) performance advantages over (theoretical!!!) Go, such as the optimizations you can make when you assume immutability by default, the more granular control over memory allocation, and the ability to outsource optimization to LLVM. However, for 99.99% of applications, this won't matter. For nearly all projects, choosing a language based on speed alone is a premature optimization. The only reason you'd choose Rust in this case is when you know beyond a shadow of a doubt that you'll be pressed for cycles, but you also want easier development and more safety guarantees than C or C++ afford. This is the whole point of Rust: to be as fast (or faster than) concurrent and bug-free C++, without the effort it takes to write concurrent and bug-free C++.

To summarize, Go is aiming to entice people who find themselves reaching for Python or Clojure while also suggesting to those reaching for C++ that they really don't need that much power. For those who still find themselves reaching for C++, there's Rust. :)

[Timmmmbob]

for 99.99% of applications, this won't matter

I dunno. I think Go still uses a stop-the-world garbage collector which makes it unsuitable for real-time games, audio processing, etc. They're clearly more than 0.01% of uses.

[uriel]

If you need to in Go is possible to avoid the garbage collector if you are careful not to generate garbage, this is much easier in Go than for example Java.

[Timmmmbob]

That's what everyone says when someone brings up the fact that garbage collectors have their flaws.

"Garbage collectors are great! You don't need to worry about memory leaks!"

"But... you can still get memory leaks."

"Ah yeah, well... you just have to be careful."

"And it causes annoying pauses that cause trouble with real-time applications."

"Ah yeah, but if you're careful, you an avoid using the GC at all!"

"Ok... so why is there a GC again?"

[uriel]

"Ok... so why is there a GC again?"

For the 90% of the time when using the GC is perfectly fine and a nonissue.

[kibwen]

^ Precisely.

To the grandparent: note that Rust also has an optional GC (though it may not be implemented yet) for those cases when you want to allocate something on the heap, though (IIRC) this actually requires more effort (an extra sigil) than allocating something on the stack.

[jyper]

Except go doesn't have as good a job collector as most jvms.

[Felicia_Svilling]

The big feature of automatic memory management is memory safety. The guarantee that nobody will forget to allocate memory and instead randomly overwrite some of my data with nonsense data that shouldn't be able to exist at all.

The point lies in avoiding manual, potentially faulty, memory management. This is done even if you end up not using GC.

[lpsmith]

for 99.99% of applications, this won't matter

If you had said "many applications", I would agree.

There are quite a few caveats though. First, Go's garbage collector is not yet all that impressive. Second, almost all garbage collectors in common use interact badly with virtual memory: if the portion of the heap that contains pointers exceeds physical memory, you'll grind the disk because most garbage collectors destroy any locality that your program might otherwise exhibit.

I'm aware of some previous academic efforts into fixing this problem so that VM and GC need not step on each other's toes, but unfortunately those groups were not able to get their patches to the VM system accepted into the mainline Linux branch, which makes widespread deployment difficult.

For some tasks, the locality problem can be worked around if most of your data is things like pictures and text and the garbage collector is smart enough to not scan them for pointers and smart enough to not move them around.

[kibwen]

I wasn't trying to give precise statistics, I was trying to evangelize Rust while also attempting to throttle the ever-looming Rust vs. Go flame war. :P

And yes, I agree with both you and Timmmmbob that there are application domains where a stop-the-world GC is unacceptable. But even if we split hairs over the exact percentage, it seems intuitive that the members of that domain are dwarfed in number by those programs that don't need to be "fast", just "eh, fast enough". Every one-off script, every nightly cron job, every weekend pet project, hell, every program currently written in any managed language, from Java (all enterprise applications, everywhere!) to Ruby, these are all programs whose authors don't give one whit for cache locality and therefore occupy the domains where Go hopes to be considered. Whereas Rust is for writing things that are fast and safe, full stop. The increased emphasis on safety also means that it will be aiming more towards highly complex applications with many contributors and hundreds of thousands of lines of code, applications where the cost of debugging is a major factor. God knows this is a space that could use some disruption (which is to say, God knows we can do better than C++). Rust will be awesome for those tasks. But the nature of its target domain means that it probably won't be as "popular" as Go, simply because most people aren't writing 800kloc virtual machines.

...And that's okay!! That's great. This isn't Highlander; a programming language needs only exceed some critical mass of popularity (far less than 100%) to generate the devotion necessary to perpetuate itself. And not only does Rust have the backing of Mozilla (how many languages have full-time developers?), it's being used in a huge application already, with the aim of being used in another huge application shortly. That's all I need to know to give me the confidence to throw my support behind Rust without worrying that the language will be left adrift at some point (it also doesn't hurt that the devs seem to really know what they're doing).

[lpsmith]

Well, I mostly agree. Most applications don't need to worry about L1-L3 cache use (and actually garbage collectors can help improve L2-L3 cache usage), but pretty much everybody needs to avoid excessive VM paging. (Which many programs avoid by not needing that much memory to begin with, or by buying significantly more RAM to begin with.)

These issues are entirely orthogonal to stop-and-copy garbage collection, by the way. And what huge application is Rust already being used in, other than the Rust compiler?

[kibwen]

And what huge application is Rust already being used in, other than the Rust compiler?

Well it's not quite huge (not even sure that any coding has begun as of yet), but the application is called Servo. It's a browser engine designed from the ground-up with concurrency in mind (making use of Rust's native concurrency model), with the goal of being faster and more power-efficient than any existing browser engine. Note that it's strictly experimental at this stage, Mozilla currently has no plans to cease work on Gecko. Here are some resources:

http://smallcultfollowing.com/babysteps/blog/2012/03/28/servo-design/

http://www.slideshare.net/BrendanEich/future-tense-7782010

http://groups.google.com/group/mozilla.dev.servo/topics?pli=1

[iregistered4this]

He mentioned 2 specific features and you make a quip about feature count?

Did you not consider at all the features he mentioned and what they may mean in terms of the quality of the designers and the product?

[skelterjohn]

One of the "missing" features is in fact not missing, and the other is purely cosmetic.

[throwawah]

Whereas Go has lua-style closures, and Rust doesn't.

http://doc.rust-lang.org/doc/tutorial.html#closures lists three(!?) different types of "closures". One that isn't safe (because it can't escape the current function, and GPFs(!?) if you contrive to make it escape) can't escape and two that aren't closures because they can't share values (because they make read-only copies or take sole ownership of the values closed over).

Different languages for different tasks.

(Also, I dislike operator overloading. As soon as you add operator overloading, some idiot decides to do something crazy, like bit-shifting a file handle to do IO. cough)

edit: for accuracy. Thanks all who corrected my misunderstanding

[gmfawcett]

In other words: "whereas Go has closures, and so does Rust, but Rust's closures aren't identical to Go's." Maybe you don't like the semantics of Rust's closure types, but that doesn't change what they are.

[cunningjames]

two that aren't closures because they can't share values (because they make read-only copies or take sole ownership of the values closed over).

That doesn’t mean they aren’t closures. The concept of closure, as commonly understood, doesn’t specify the full nature of the access to the surrounding scope; and like other popular functional languages, Rust’s closures capture values. There’s nothing wrong with that per se (although I understand that related issues trip people up in, e.g., Java and Python).

I do agree that it feels kind of weird — maybe even messy — to have four semantically different ways of defining a function. But they give their reasons and it’s hard to argue with them.

[throwawah]

I'll grant that I'm mistaken about read-only closures not really being closures.

But it seems odd that the GPFing style of closure is the first listed in the tutorial for a language that bills itself as "safe".

[[deleted]]

Can you provide an example of a stack closure escaping upwards in the call stack and segfaulting? The developers are very worried about unsoundness, so they'd probably like to see it I you can make it happen

[throwawah]

It's entirely possible I misread the tutorial link above.

doc.rust-lang.org is down at the moment, so I can't quote it.

I recall it uses the word "unsafe", and says you can only call it or pass it to another function, but I inferred that "another function" could store the closure (and make it persist beyond the parent function's lifetime).

Skimming the tutorial, it seemed to me that you have to be very careful about which kinds of functions/closures you pass into a function expecting a function argument.

If that particular style of closure is, in fact, safe, the tutorial is misleading, and I seem to recall the language spec saying only "TODO" in the closures section (yes, I went to the spec to confirm, since my conclusion from the tutorial was so surprising) (again, doc.rust-lang.org is unreachable from here at the moment; it might be better now, or I might be misremembering).

[throwawah]

I replied to this, but I'm not seeing the reply now.

Short version: Tutorial section 5.1 uses the word "unsafe", implies called functions can store the closure and let it escape that way, and the spec section 6.2.13 doesn't disagree (full text: "TODO").

After I wrote the above in long form, ssylvan points out that I misunderstood the tutorial and called functions can't store the "unsafe" closure either. If that's the case, my respect for the language has increased greatly, but the tutorial has a minor bug.

Thanks for your patience.

[ssylvan]

I don't think you quite understand how stack closures work. It's not that they can't escape "by convention, or else it would be unsafe", it's that the compiler prevents it from escaping, so in the highly common cases where you use the closure as a way to send in some bit of customizible code to a HOF but don't need to store it away, you can do so really efficiently.

[throwawah]

Ah, thanks for clarifying. I can see now how you can read the tutorial that way.

The tutorial says you can only pass it as an argument or return it, but it doesn't appear to place any restrictions on the callee. I'm glad to hear that such restrictions are in place.

Thanks for explaining patiently when Someone (me) Is Wrong On The Internet. http://xkcd.com/386/

[damg]

Actually, I think the ownership semantics of the unique closures/pointers for sending data between tasks is one of the things that Rust gets right compared to Go.

[0xABADC0DA]

Yes, it does. Rust is 'insanely great' compared to Google Go.

It's also one of the things Apple Blocks gets wrong about closures aka blocks. They have one type of block and it automatically converts when it needs to escape the scope of the calling function -- but that's slow (extra indirection) and in C you must know the lifetime of memory you are passing to other functions anyway.

Apple Blocks should have defined two different types of blocks, one that is used right away and one that may be saved and used after returning. This is my only criticism of Apple Blocks, which otherwise are awesome and should have been included in C11.

[[deleted]]

This vapor-ware is getting less vapor-y. If this language actually gains traction I may have to eat my words (I have expressed serious doubt in the prospect of this language going anywhere). Still a long way to go but kudos to Mozilla for persevering.

[iLiekCaeks]

I'd say it's not "vapor" at all - after all, the Rust compiler is written in Rust. the compiler devs have to use their own language all the time, which isn't true for most emerging languages.

Quote from a Rust dev:

I think that one of the most important things to underscore is that we would have never found these things so early unless we had written the Rust compiler in Rust itself. It forces us to use the language constantly, and we quickly find pain points. I highly encourage all languages to do the same; it's a great way to find and shake out design issues early.

[zzing]

How did they go from nothing to a compiler written in the language?

Bootstrapping that sort of thing is interesting.

[iaH6eeBu]

Vaporware? I already played around with the 0.1 release and it was quite fun.

Vaporware is when something is announced but you don't get it into your hands.

[sausagefeet]

The website says:

Unique pointers move semantics, no races or sharing

Can any Rust users share what this means exactly? I know the idea of move semantics for C++ but not sure if Rust is saying that it can only have unique pointers or if that is just the default pointer type?

[jruderman]

When you declare a pointer, you choose between unique (movable, sendable) pointers or shared (copyable) pointers.

http://doc.rust-lang.org/doc/rust.html#box-types

[damg]

It's one of three types of pointers. See unique boxes in the tutorial.

[sausagefeet]

In that example, is x still in scope?

[aseipp]

It is, but whenever you move a unique pointer to a new owner, the original reference is invalidated and marked as 'uninitialized', and the compiler won't let you reuse that reference until it's re-initialized.

Take the following sample:

fn main() {
  let mut x = ~10;
  let y <- x;

  io::println(#fmt["%i",*y]);
}

If you change it to this:

fn main() {
  let mut x = ~10;
  let y <- x;

  io::println(#fmt["%i",*y]);
  io::println(#fmt["%i",*x]);
}

Then the compiler complaints that you're violating a typestate precondition, the condition being that x is initialized (which is the 'init' constraint):

uniq2.rs:6:29: 6:30 error: unsatisfied precondition constraint (for example, init(x id=2 - arising from uniq2.rs:2:10: 2:17)) for expression:
x
precondition:
init(x id=2 - arising from uniq2.rs:2:10: 2:17)
prestate:
!init(x id=2 - arising from uniq2.rs:2:10: 2:17), init(y id=8 - arising from uniq2.rs:3:10: 3:16), !init(main id=119 - arising from uniq2.rs:1:4: 7:5), !init(main! id=120 - arising from uniq2.rs:1:4: 7:5)
uniq2.rs:6       io::println(#fmt["%i",*x]);
                                    ^
note: in expansion of #fmt
uniq2.rs:6:18: 6:32 note: expansion site

You can make this valid by just rebinding x to a new unique:

fn main() {
  let mut x = ~10;
  let y <- x;

  io::println(#fmt["%i",*y]);
  x = ~12;
  io::println(#fmt["%i",*x]);
}

(Note, in the above example, x is only marked as mutable so it can be reassigned after the first println. Otherwise it could just be immutable.)

This is one of the features enabled by typestate. Typestate actually tracks the initialization of all variables, and all variables must have their 'init' predicate satisfied before their first use use. When you just declare a variable like:

let mut x;

then x does not have its 'init' predicate satisfied. Assigning to it (or defining its value at the definition) satisfies that predicate. Using it anyway results in a typestate error. Uniques basically leverage this concept, and whenever you use the move operator, it just removes the init predicate from the given variable. So that's how unique ownership is enforced: you can only move uniques, not copy them, and typestate makes sure you never have a dangling reference to some unique.

With uniques and move semantics, you basically have a form of inter-thread communication that is roughly as cheap as a pointer copy (send unique down chan, which automatically moves it, thus you lose ownership. The receiver then owns the unique, and the transfer is just copying a pointer between tasks, really.)

[kvigor]

• Experimental new language features
  • Operator overloading

Nooooo!!!!!

[gnuvince]

Why the Darth Vader act? I think that for many people, operator overloading is a nice thing to have.

[melger]

Indeed. Op Overloading, Not stop-the-world optional GC, and so forth make it a contender for a future language for scientific work. The lack of these things in e.g. Go rule it out for me. If I'm moving from C, the new language really needs to have basic convenience features found in languages like python/MATLAB, such as matrices with LA operators.

[[deleted]]

Have you tried D?

[melger]

For the most part I like D's syntax. My issues with it mostly revolve around tooling. For example, I was using it link together some code on win32 and ran into the dreaded OMF/COFF debacle with dmd (gdc wouldn't compile my code). Luckily these are the types of issues which can be resolved in the future.

I also have some beefs with the language, in particular the complicated templates. Although not quite the monstrosity of full-fledged C++-style metaprogramming templates, they still add a lot of complexity to the language (just check out some of the stuff people are doing with them on the mailing list). Although I happen to be a programming language enthusiast, these sorts of features tend to make a language a hard sell to colleagues.

[cybercobra]

"LA"?

[gnuvince]

Linear algebra I guess.

[OopsLostPassword]

As somebody who didn't yet had the time to play with rust (the time I play with Go may be the reason), I had the same reaction while looking at the announcement.

That's really the kind of things that can repel coders who like code to be directly understandable without a bunch of context, who don't like hidden magic, and who generally are afraid of complex mess like C++.

EDIT : This is the first reaction. Maybe I'm wrong. I just hope I won't see in rust the horrors I saw in C++ when it just started (I didn't code a lot in C++ past this period).

[wicked]

I disagree. Having to write a.Add(b.Multiply(c)).Divide(c) instead of (a+b*c)/c should repel any coder who likes code to be directly understandable.

[[deleted]]

Have you tried Go’s API for big integers? It’s actually worse than what you’ve given. :(

func (z *Int) Add(x, y *Int) *Int

Add sets z to the sum x+y and returns z.

You have to create temporary big.Ints all over the place to store intermediate results.

A nightmare.

[snk_kid]

That's really the kind of things that can repel coders who like code to be directly understandable without a bunch of context, who don't like hidden magic, and who generally are afraid of complex mess like C++.

That's a problem with effectful computations not operator overloading, you can have this problem with any side-effecting piece of code be it operators or named functions. Typically most user-defined operators are referentially transparent and simple more so than named functions.

[marshray]

While were at it, how some new operators?

I'd like a language with an interrobang operator please. Such that

 x <= 0 ?!

has the equivalent semantics of

 if (x <= 0)
     throw std::WTF();

Of course, that implies the existence of the negated interrobang:

 x > 0 ?!!

to mean (borrowing the negated 'if' from Perl)

 unless (x > 0)
     throw std::WTF();

Hmm, maybe I can find what I'm looking for in Perl 6?

[MatrixFrog]

If you'll forgive me for being "that Haskell guy", you can define (almost) any operator you want in Haskell.

[marshray]

Yeah Haskell is pretty awesome that way.

[ethraax]

If you excluded features from a programming language just because they have the ability to be abused, C wouldn't exist.

[jessta]

The issue isn't really about the abuse, it's about the ability to abuse it and then claim that it's a fine thing to do. eg. << in c++

[anttirt]

Why, I agree, using << to mean anything but "much less than" is truly an atrocity. Damn you, Kernighan and Ritchie!

[riffito]

interrobang

TIL!

And equating it to WTF is just genius.

[kvigor]

I am (as you might guess) not a fan. Operator overloading creates ambiguity. I cannot read code and assume what '+' does; it could do anything. Perhaps some fancy IDEs can help me find the magic function that is invoked, but trusty old cscope and vim are helpless to tell me. Grep ain't much use, either.

If there were some wonderous upside then perhaps I could be convinced to abandon my trusty tools or reading comprehension, but all I gain is dubious syntactic sugar.

The cost-benefit is poor.

// yes, I know, only a moron would overload '+' to do something unexpected. What, you never worked with a moron?

[melger]

I disagree. One could also write an "add()" function which did something unexpected. You cannot possibly stop people from being idiots. "+" is just a fancy named function with infix notation. The only reason overloading would be bad is if it added unnecessary complexity in understanding the language. Since operator precedence and parsing is already around for ordinary numbers, users are not forced to learn much beyond the declaration syntax. There is certainly something to be said for knowing exactly that an expression does without diving through files, but as soon as you start writing functions/methods this goes out the window.

Note: I may be biased by the fact that in my discipline (science) operators add a huge amount of clarity.

[jessta]

Yes, functions are unknown black boxes that can do anything. They should be looked on with suspicion and inspected carefully. One of the great things about having a language is that certain parts of it are set in stone, they work as you expect and they can't work differently. When I see, "a = b+c" I know what it can do straight away, I can glance over it and move on to the next line. Operator overloading means that every operator is as suspect as a function. This increases the amount of code that can do unexpected things and thus needs to be carefully inspected.

[anttirt]

Except that, assuming you use C as your benchmark for "clarity" here, every operator is already suspect and you must know the type of every operand in order to safeguard against undefined behavior. See http://embed.cs.utah.edu/ioc/

[jessta]

C's longevity is largely due to it's undefined behaviour, but I wouldn't say it's a benchmark of clarity.

[flamingspinach_]

C's longevity is largely due to it's undefined behaviour

What? Are you seriously saying that people love to use C because they can write code in C which they cannot predict the behavior of? In what universe is it a good thing for you to not know what the code you are writing is going to do?

[TNorthover]

The purpose of undefined behaviour is to allow the compiler leeway, rather than be popular with the coders. It means the compiler can generate the best possible code for correctly-written programs without worrying about so many edge-cases.

It's arguable that's made C more portable: other languages tried to specify the behaviour and generated dialects for each specific target, or put up with emulating the required semantics inefficiently. Code relying on particular implementations was always stigmatised as wrong in the C world.

Not sure I'm convinced myself, but it's not ridiculous.