Live data from Hacker News

Rust 0.3 released

github.com

41–50 of 57 posts

Re: Rust 0.3 released

#41
post #36
post #31

Has Mozilla given up on Typestate? I see no mention of it in the release notes.

(Note: not a Rust dev, I just hang out in the IRC channel) Typestate's still there for the time being, but it may not be for much longer. The problem is that it's not being used anywhere in the compiler, so it's not getting exercised nor is it providing any constructive design feedback. Last year there was an attempt to begin using typestate throughout the compiler and standard library, but it proved so clunky to use…

Reformatted:

me: so what were the reasons that nobody ever used typestate? was it just too cumbersome?

graydon: combination of incomplete and wound up not often able to benefit from much code-path-distance between site of check and site of constraint-enforcement.

graydon: I'm still unconvinced that could not be overcome

graydon: but the result is that using it has effectively caused all callers to do checks just before they call, which isn't much of a win

me: graydon: was typestate the whole reason you started rust in the first place? I'd be really interested to read a retrospective :)

graydon: no, I started rust because I was sick of hacking in C++ and wanted something with a saner compilation model, grammar, safety properties, concurrency properties ...

graydon: I'd used lots of other languages and kept not being able to use them in an industrial setting, because they failed to be similar-enough to C++ in important ways, usually.

graydon: typestate was just a property that hermes had that I liked because it looked like a way to statically optimize DBC, which I like in languages that have it

graydon: (sather, eiffel, some of the C# derivatives)

graydon: I tend to program over-defensively when left to my own devices. make copies of every datum to be local. make everything const. run a lot of internal consistency self-checks. etc. etc.

graydon: (the one habit I hadn't picked up yet, which I'm still trying to, is adequate unit testing and fuzzing ... sigh)

me: graydon: so are you confident yet that even if someone was forcing you to write rust, you would't be sick of it? :)

graydon: my experiences writing rust so far have been pretty positive. it has a number of the parts I like in other languages. the grammar is simpler, the compilation model is better, it's AOT and static, it has algebraic types, clear integer types, is eager and reasonably fast, doesn't force OO style...

graydon: and crucially: doesn't need to allocate / GC like crazy, so can close that residual gap on inner loops without having to hit the FFI

graydon: there are still odd bits we need to whittle down

graydon: oh also the safe references are lovely. and getting better.

Re: Rust 0.3 released

#42
post #25

What problem does rust solve other languages (D, SML, OCaml, C++11, Objective C, vala, go etc.) did not -- apart from helping with the NIH syndrome? Does Mozilla actually use a language that still is a moving target with respect to its language specification for some substantial work (or what is the real-world status of that upcoming rendering engine which seems to be the reason why rust was called into life)?

I guess it is the need to explore new ideas, even if the language dies, some of its ideas might be picked up by mainstream languages.

It's precisely not the need to explore a lot of new ideas. Rust is taking tried and true paths to something new :-)

Re: Rust 0.3 released

#43
post #35
post #34

Earlier quoted context omitted.

Why not D?

Because, faced with the fact that C++ makes an octopus by nailing extra legs onto a dog, D decided the right thing to do was to staple-gun them onto a cheetah instead. D, at the end of the day, is C++ with cleaner syntax . Yes, you've gotten rid of headers and some of the syntactic ambiguities, but things that were mutable are still mutable, templates are still templates, hard-to-solve threading problems are just as…

This isn't very relevant to the topic, but I wanted to thank you for the colourful and hilarious metaphor. Cheers.

Re: Rust 0.3 released

#44
post #25

Earlier quoted context omitted.

I guess it is the need to explore new ideas, even if the language dies, some of its ideas might be picked up by mainstream languages.

It's precisely not the need to explore a lot of new ideas. Rust is taking tried and true paths to something new :-)

Ah, but I think it's important to distinguish between ideas that are new in research and ideas that are new in industry. God knows that pattern matching isn't a particularly new concept, but I sure hadn't heard of it before Rust; see also the popularization of list comprehensions due to Python via Haskell. So I think what the grandparent is implying is that even if Rust doesn't end up as a world-shattering language, it still has the opportunity to expose programmers to "new" ideas, even if, in academia's opinion, those ideas aren't so new at all. :)

Re: Rust 0.3 released

#45
post #9

Does anyone know the origin of the name? I did a quick look on wikipedia/github/project site but couldn't find anything conclusive.

TBH the name does make me think of rusty metal, as in dumped cars which are old and broken. Not sure that's the best mental image to create from the name of a new technology...

Re: Rust 0.3 released

#47
post #16

Earlier quoted context omitted.

Rust is being used to implement an experimental new browser engine with a focus on concurrency in order to better take advantage of highly-parallel and power-limited hardware. It's known as Servo,[1] and it's still strictly in research mode; there are no concrete plans to integrate anything into Firefox as of yet. Even if there were, Rust itself won't be at 1.0 until sometime next year, and it would be quite a while…

Still can't build it (llvm fails somewhere) but reading the source code is interesting, very concise.

Please file an issue regarding the build problem if you get the time on our issue tracker: https://github.com/mozilla/rust/issues

We're trying to iron out all of these issues.

Re: Rust 0.3 released

#48

Earlier quoted context omitted.

Interesting. I like many of Rust's language concepts (and I have contributed some small fixes to the Rust runtime), but (to my eyes :) the syntax is snowballing into a hybrid of C++ and APL.

What in particular do you not like? To me the proposed stuff on the roadmap fixes the problems I see (changing "::" to ".", camel case for type names, "alt" -> "match", => after pattern matches, #debug to debug!, removing argument modes -- no guarantees that we implement these of course, they need consensus), but I'm curious as to what your thoughts are.

I hadn't seen the roadmap changes. They address a lot issues I had, especially the argument modes.

I'm sure camel casing will be controversial, but it makes sense given that Rust's primary audience is Mozilla, where camel case is the enshrined naming convention for its C++, Java, and JavaScript code. Python's standard library is an ugly example of what happens when the language community can't settle on one convention.

Also, I wonder why 21st century languages still use "&&" and "||" operators. Python's "and" and "or" operators are easier to read (for English speakers) and type. They don't require shifting of distant keys. "and" has two home row characters. "or" has fewer keystrokes than "||". :)

Re: Rust 0.3 released

#49
post #34

Rust is the most promising up-and-coming programming language, in my opinion. Finally a programming language with decent syntax that does RAII, and understands the need to restrict garbage collection! Thanks!

Why not D?

D's garbage collection is global, and either off or on (and a lot of D libraries leak memory like crazy if it is off, so in practice it has to be on most of the time)

Rust's per task GC seems like it should allow more flexibility, and I'm hoping it would be usable in the High Frequency Trading arena, for example.

Re: Rust 0.3 released

#50
post #21

Earlier quoted context omitted.

What in particular do you not like? To me the proposed stuff on the roadmap fixes the problems I see (changing "::" to ".", camel case for type names, "alt" -> "match", => after pattern matches, #debug to debug!, removing argument modes -- no guarantees that we implement these of course, they need consensus), but I'm curious as to what your thoughts are.

Instead of angled_brackets they should probably try to go with D's style of templates[1], which uses an operater !, to signify its use. Also, I personally believe that camel case for type names would be a net loss; the underscore separates the words nicely, and I think it's pretty clear from the syntax what is and is not a type name (in my extremely limited experience). [1]. http://dlang.org/templates-revisited.html

What I like about camelcase is that it confers the same kind of visual classification to types as to certain other things.

Back in the day, I used ObjectPascal, where we used camelcase for everything: function names, variables, types. Borland set an early precedent by prefixing many class types with the letter T, thus to visually distinguish them from other things: So you had TWindow, TButton, etc. This system makes sense when you see it in practice:

    function GetParent(Window: TWindow): TWindow;
    begin
      ...
While a bit crude, I feel the same kind of visual differentiation is needed for a language like Rust.

Ruby has some syntactic oddities I like precisely because they provide visual classification: "@" for instance variables and "@@" for class variables:

    class User
      @@max_name_length = 32

      def initialize(name)
        raise "Error" if name.length > @@max_name_length
        @name = name
      end
    end
The current "old-style" Rust code quickly becomes a uniform sea of lowercase to me, as does Stroustrup-style C++. It gets worse due to a quirk of mine to name things verbosely. So instead of variables like "u" to represent a user, I spell out "user". With all lowercase it gets odd:

    fn save(user: user) {
      ...
    }
While Rust have types and variables living in separate namespaces, all-lowercase names introduces the possibility of ambiguity and possibly makes some things impossible in the future, I think; consider:

    let foo = user.new();
It looks like a method call "new()" on an instance "user". But what if you could call methods on types? With the discussion about the "::" operator becoming ".", such a distinction would become impossible without introducing a new operator. With camelcase it becomes obvious what's what:

    let foo = User.new();
Post reply on HN