I'm moving away, here's my two cents

[regexident]

@mateus

What made me fed up was that I was getting SIGTRAP when I was trying to make a program that supports plugins. If it was SIGSEGV I would know that a statement is corrupting memory but SIGTRAP terminates the program and leaves me with no clue. No message is printed. I know exactly which statement causes the problem. I was trying to copy a struct into another struct. Copying primitives works fine. To be honest I couldn't even setup gdb to show the source code, I know it is possible though. I don't have to do any setup when I'm programming in C. I just run gdb and the source code is there.

The C language saw the light in 1972. GDB followed in 1986. That's both over 30 years.

Give Rust some time. I'm pretty sure debugging C in 1987 was much more of a PITA than it is for Rust right now, after only 1 year.

@mateus

Rust seriously does not support interfacing with other libraries. People write entire libraries just to call code from another C libraries. If I'm calling code using the C export interface, I know it is unsafe. No need for wraping.

Calling C functions directly from you project's code (as opposed to via some wrapping crate) works against the entire purpose of Rust's safety bounds. The last thing I want to have to think about when writing Rust is segfaults, buffer overflows and the like. I would have to if I was to call C directly.

@mateus

Furthermore, it is C code. Why do you guys depend on C? Call functions using the int instruction in assembly source code.

Rust is a cross-platform language. Rust is using C for FFI for the same reasons that you are using C for programming: platform independence. Abstractions. Letting you get stuff done at the end of the day.

@mateus

The syntax has too many tokens. It makes programming unpleasant.

In that case you might want to consider APL.

Anyway, joking aside, you must no forget that we are humans after all. We're not computational number-crunching machines. Regular expressions are a perfect fit for computers. But most human users struggle with them. Why? Because they are utterly dense in syntax and lack any visual structure (as does APL, one could say, btw). I still love 'em though.

@mateus

A good example of a language with perfect shape is the Go language, very clean.

I wouldn't consider Go a clean language at all. It's small, sure. (Too small even.) But not clean.

func Reduce(
    in interface{},
    memo interface{},
    fn func(interface{}, interface{}) interface{}
) interface{} {
    …
}

@mateus

struct fields end in coma, trait fields end in semicolon and statements end in semicolon too. Why not make everything a semicolon? […] Why the semicolons after the identifiers in struct declarations?

There are no fields in a trait. There are type defs. But those are statements. Semicolons are for statements. Structs list their members. Enums list their variants. Commas are for lists.

Compare Rust:

struct Foo {
    bar: Int,
    baz: Int,
}

With Swift, e.g.:

struct Foo {
    let bar: Int;
    let baz: Int;
}

(Idiomatic Swift omits the semicolons, but for the sake of semantic correctness I'm including them here.)

Notice how Swift has the let in there. The let turns bar: Int into a statement. Thus the semicolon. If Rust had used Swift's let syntax for fields, then you'd be right in expecting semicolons. But as it is Rust is simply consistent with its semantics.

@mateus

What is the -> for before the return type?

The Input -> Output syntax is a common idiom in functional languages. Remember: There's more than just C out there.

Your criticisms sound a bit like C is your hammer and you haven't had a look at the other tools in your toolbox for a while. There are lots of things where C got it right. But even more where it didn't.

@mateus

Rust does not support anonymous structs and they have to be always declared outside of the functions. But functions can be declared inside other functions, what an irony.

Wrong. See Aatch.

@mateus

Closures are something that I never needed. Entirely superfluous. Tuples are completely unnecessary. They are like anonymous structs with anonymous fields. When declaring a new struct instance, the fact that the field name have to be always used is a pain to the programmer. It should be optional as in C.

Different strokes for different folks. I came to Rust for the safety, sure. But most importantly I came for the incredibly strong type system and the expressive power through the use of tuples, pattern matching and closures. It's 2016 after all. Time to leave the cave.

Coming back to your point on verbosity:

@mateus

The syntax has too many tokens. It makes programming unpleasant.

I develop in both Rust and Swift. Their syntax very is similar (due to Swift taking quite a bit of inspiration from Rust). Trivial code is so much more ergonomic in Swift. But as soon as one tries to solve real problems the simplicity (or cleanness as you might call it) of Swift (compared to Rust) comes at a cost: Swift's syntax simply lacks the tools to express more sophisticated types or patterns (things will improve slightly with Swift v3, fortunately).

Rust aims to solve difficult problems. Difficult problems that I wouldn't dare try to solve in C or even Swift, e.g. while Rust makes it fun even.

@mateus

There is a lack of interface standardization for packages. Something like RFCs (Request for Comments) and packages that provide just the interfaces for specific applications. For example one interface for each type of database (table, kv, document).

Did you consider submitting an RFC for this? There are quite a few community-related RFC already.

@mateus

When I visit it I simply have to spend hours to analyze which package does it better and which has the better interface for my program.

This is specifically something that the Platform proposal by @aturon tries to tackle, btw.

@mateus

There is a lack of modularization. Most libraries I used in Rust depend on many other libraries. It is a design failure. Libraries should have no or very few dependencies and the host program makes them interact.

@mateus

Why people keep using names related to metals for the packages? Rust is a family of fungi. If people used names related to biology it would make more sense. Something like "microscope", or "test tube", or even "bacteria" or "lion".

So why then is Rust's logo a cogwheel? *cough*

@mateus

Why not use the debian repository and make deb packages if it is not pushed in time to sid.

Because platforms. Lots of them. Many without a package manager even. Also because there's no need to needlessly hurt oneself.

@mateus

Or maybe produce multiple packages in different formats if you don't use debian.

Now you're just messing with us, aren't you? O.o

@mateus

The fact that crates.io is the default makes Rust less resilient and vulnerable to censorship and surveillance.

No. It makes Rust consistent and ergonomic. Nothing prevents you from setting up your own fork/clone of crates.io. It's open source and one can simply point Cargo.toml to somewhere else.

@mateus

Coding standard should be optional.

Beg to differ.

@mateus

The compiler errors are cryptic and contains language not present in the book. […]

Not sure which book you're referring to, but there's an entire chapter on traits and trait bounds in "The Book" explaining the concept in depth.

@mateus

The compiler embeds help messages with rustc --explain instead of putting them in man pages or maybe just copy pasting the error code on a web page.

There is a list: Rust error codes index - Error codes index Such a list won't help you on an airplane or a dead spot though.

@mateus

The documentation looks like a literature book. It's one of those things that you read laying in bed before sleeping. It teaches the language like a person trying to learn it by trial and error and uses onomatopoeia like the author does not know what she is doing. She is just faking feelings and maybe the reader didn't even understand the matter.

It presents trial and errors and shows the correct way at the end like telling a story. I just want to know the correct version. This causes TL;DR.

This is the part where I have to agree. But then again I'm probably not the target audience anyway. I don't read programming books cover to cover.

What I want from a technical book is to be presented the problem at hand followed by the solution and its reasoning. No fluff. No theoretical proofs. I also don't want to have to build a silly pet project in order to be able to follow the book. Chances are I don't care about your pet project.

Again: that's me. I also can't stand GIFs/memes/jokes in tech talks. So maybe I'm just dead inside or something. ¯\_(ツ)_/¯

From a technical standpoint however I consider "The Book" (and "Rust by Example") one of the best books out there. On any language.

[mateus]

@hanna-kruppe

Are you complaining about the safe wrapper libraries that exist and "hide" the down-and-dirty FFI work from its users? Or is it anything in the core language that could be improved?

@regexident

Calling C functions directly from you project's code (as opposed to via some wrapping crate) works against the entire purpose of Rust's safety bounds. The last thing I want to have to think about when writing Rust is segfaults, buffer overflows and the like. I would have to if I was to call C directly.

Wrappers are fine because they tell additional information about the external functions to the compiler. The core language. std::mem can do some work but the state of the program cannot be predicted. In the example I gave on my post, the signal triggers the compiler if there is a compiler attached. If I just continue, the program runs fine and the output is also fine. The state of the memory is very well know in a C program and so it should be in a Rust. If you really want to go hardcore you could read the gcc internals, something absent in Rust (not talking about LLVM). There are programs from operating systems to web apps in Rust, that's exactly what is expected from a multi-purpouse language. If the Rust developers want to target a programmer that will make a trivial program or a functional language program, It's easy, you are fine. If the developers want to target someone that will go deep in the operating system, the hardware (including the memory) should be described so the programmer knows what to expect.

@regexident

Rust is a cross-platform language. Rust is using C for FFI for the same reasons that you are using C for programming: platform independence. Abstractions. Letting you get stuff done at the end of the day.

If Rust depends on libc, it will never be a replacement for C. It will always be a layer on top of it. libc could be reimplemented little by little by actually using syscalls. Different operating systems need different syscalls but if C can do it, Rust can do it too.

@Aatch

The fact that you cite the existence of closures as unneeded makes me wonder if you tried to program in Rust, or some sort of "safe C" dialect.

@regexident

It's 2016 after all. Time to leave the cave.

@regexident

Your criticisms sound a bit like C is your hammer and you haven't had a look at the other tools in your toolbox for a while. There are lots of things where C got it right. But even more where it didn't.

I know other languages other than C and I'm expecting a multi-purpouse "tool", just like C but better. Your comparison sucks.

@regexident

Now you're just messing with us, aren't you? O.o

It works for every language, for every distribution. Why not Rust? You probably don't know how it works. Windows user?

@regexident

Coding standard should be optional.

Beg to differ.

Imposing things is authoritarian. I will not comment further on your post. Most of your counter-points are based on opinion and some of them I have answered in previous posts.

[steveklabnik]

@regexident

Such a list won't help you on an airplane or a dead spot though.

Tiny note: all the docs come included with Rust when you install it, so you have access to this even when you don't have connectivity.

[retep998]

@mateus

It works for every language, for every distribution. Why not Rust? You probably don't know how it works. Windows user?

Windows users are one of the reasons we have Cargo. Relying on package managers and such is extremely painful. Who is going to go out of their way to support Windows? A lot of crates don't even bother, but because they use Cargo it still usually works just fine on Windows. I appreciate Cargo because it means anyone can publish a crate very easily and it makes it very easy to use it from nearly everywhere. If you don't want things to be easy, what is wrong with you?

@mateus

If Rust depends on libc, it will never be a replacement for C. It will always be a layer on top of it. libc could be reimplemented little by little by actually using syscalls. Different operating systems need different syscalls but if C can do it, Rust can do it too.

On Windows Rust barely depends on libc at all, however it cannot avoid depending on other libraries. The entire system interface to Windows is done via a set of DLLs that export a C interface, there is no stable syscall interface to use, especially since a lot of system functionality is implemented in user mode anyway. Rust uses whatever the system interface is for a given platform. For linux Rust uses libc because it is easier and handles quite a bit of stuff for us, however there is nothing stopping Rust from one day working with syscalls directly and avoiding libc on Linux, it just requires some developers to put time and effort into it, which is in rather short supply at the moment.

[retep998]

@steveklabnik

Tiny note: all the docs come included with Rust when you install it, so you have access to this even when you don't have connectivity.

rustup doc

[leonardo]

@mateus

Imposing things is authoritarian.

This is of course a matter of taste. But taste is important or even essential in all the important crafts. So it's important to talk about taste.

If you look at recently developed languages like Go, Rust, Swift and others, you will see many "imposed things". Too much constraints and your language feels like a cage, too much freedom in your language, and the average code in your language that you find in the wild looks like a blackberry bramble, because most programmers are lazy and untidy.

Go is even more constrained than Rust. C language allows much more freedom compared to Rust. But you pay this freedom later. Most programmers aren't able to handle lot of freedom, so better introduce some constraints. Constraints are also useful to make code more uniform between different programmers, so reading code written by others is less of a pain and it feels less like stepping on the sands of Mars.

Haskell doesn't even let you mutate variables! That's a huge constraint. Yet, well chosen constraints set your mind free in other directions.

I have tried many languages, and I think Go is too much constrained for me for hobby projects (but If I have to write server code with some unusual coworkers, then even Go could be OK), while C gives really too much freedom.

Most of the C code I see is an horrendous soup of types, mutations, implicit and explicit type casting, weird syntax combinations with multiple mutations inside single expressions, undisciplined pointer arithmetic, often against the rules of the C language, often using undefined behaviours, or relying on specific compilers and platforms. Quite often when I translate C code to Rust I find out of bound bugs, integral overflow bugs, and more, even for small C programs. Rust feels just right to me. But I'd like to introduce four or five new warnings/errors in Rust

[eternaleye]

@mateus

I'm expecting a multi-purpouse "tool", just like C but better.

For many people, myself included, "just like C" precludes "better". There are many things in C that Rust does away with, and many things not in C that Rust adds, specifically in the service of being a better multipurpose tool.

Gone:

• Declarators rather than types (which in the end is the reason for -> rather than int foo())
• Trivially unsafe casts (which, incidentally, mean that no, C does not know "the state of memory")
• Preprocessor (which has various horrific knock-on effects in C by its mere existence, but losing it inherently makes FFI more manual)
• Total lack of compiler awareness of aliasing/ownership (Eliminating this is the reason Rust can be safer, but now FFI needs to know what the ownership is on the C side)

New:

• Generics. Oh my Blub, generics. I love them so.
• Trait bounds. If I love generics, trait bounds inspire utterly inappropriate desire in me.
• Closures. Good grief, closures. I never ever ever want to have to call qsort() the C way again.
• Sum types, with total (and pattern-y) matching. My state machines have never been clearer.

[StefanoD]

@mateus

It works for every language, for every distribution. Why not Rust? You probably don't know how it works. Windows user?

Sorry, but you sound like "In my little Debian Linux world, everything works fine. Why don't you guys understand?!"

Look at this tutorial how to create debian packages:

https://wiki.debian.org/Packaging/Intro?action=show&redirect=IntroDebianPackaging

And this only works for Debian based distributions! So this solution doesn't even work for the entire Linux ecosystem!

In cargo it's just

cargo package
cargo publish

Your toml file, which you used as build script, is reused 100%. I really don't understand why someone would preffer not only a more complicated solution, but also a less capable one!

I'm sorry, but your post is too biased in order to take it serious.

[regexident]

@mateus

The state of the memory is very well know in a C program […].

No it isn't. Not with undefined behavior basically all over the place. Once you introduce a single instance of undefined behavior you cannot guarantee for anything anymore. That's exactly what Rust tries to avoid at all costs.

@mateus

I know other languages other than C and I'm expecting a multi-purpouse "tool", just like C but better. Your comparison sucks.

Things aren't as simple as you make them look. You cannot just make a language that's "just like C but better". The things that make C an inherently unsafe language are at the very core of what is C. If you rip those out you end up with a disfunctional mess. One needs to start from scratch. That's what the Rust team did. And very successfully so, if you ask me.

@mateus

It works for every language, for every distribution. Why not Rust?

@StefanoD

Sorry, but you sound like "In my little Debian Linux world, everything works fine. Why don't you guys understand?!"

@StefanoD

I'm sorry, but your post is too biased in order to take it serious.

This.

@mateus

You probably don't know how it works. Windows user?

Mac/Linux user. I do know how it works, thanks.

@mateus

Imposing things is authoritarian.

You're confusing "having reasonable defaults" with what you call "authoritarian" here.

---

@mateus

Your comparison sucks.

@mateus

You probably don't know how it works.

@mateus

If the Rust developers want to target a programmer that will make a trivial program or a functional language program, It's easy, you are fine.

You might want to not talk down on others or belittle their knowledge (on which you both clearly don't have enough insight) if you want any constructive answers. Just saying.

[burntsushi]

Moderator note: This thread is getting out of hand. Please remain polite and be cordial and constructive. I’ll repeat our advice from earlier: If you have responses to this criticism, please remember to be polite. Adding information is fine, but let’s not start any big fights over opinions, especially since the author has apparently made up their mind already. Don’t feel obliged to respond to every single point.

[withoutboats]

@mateus

Closures are usually useful in functional languages like Haskell. They are absent in imperative languages. The fact that Rust is multi-paradigm language makes closures useful only if you like them.

@mateus

I knew that Rust is multi-paradigm I expected closures to be present as well as other features from other paradigms. I never said they should be removed. I just said anonymous functions are absent, something that I use frequently but closures are there. Closures are unneeded, sorry. You can use them though.

This is the most interesting part of your post to me. First, a nit - closures which don't capture any variables from the environment are anonymous functions.

I don't think a "multiparadigm" language means the language will be equally optimized for writing code in the variety of styles which have been reified into the "imperative paradigm," the "functional paradigm," and so on. I think it means the idiomatic style of the language takes influences from these paradigms. But any language, whether squarely within a paradigm or taking from multiple, has its own idioms which it optimizes for.

If you try to write C in Rust or Haskell in Rust you will have a bad time. There's not much anyone can do about that.

[notriddle]

I'm not sure to which level Cargo is capable of building packages from other languages.

It can, by shelling out to other tools, but comparing Cargo to DPKG isn't quite Apples/Oranges. Cargo is a build system with first-class support for external dependencies. It's intended to be used during development, or as part of making an installer. DPKG is an installer system with first-class concept of dependencies. There's overlap, but they're not the same thing.

Unless, of course, you actually apt-get localinstall your programs while you're still working on them.

[PeteVine]

@mateus

Call functions using the int instruction in assembly source code.

I sense longing for something like lrs...

[troplin]

@mateus

Cargo is really nice. I just think that another package manager was unnecessary.I still prefer apt-get and cygwin/mingw Writing a small Cargo.toml is as simple as writing a small Makefile.

IMO cargo and apt-get (system package manager) have a different target audience:

• apt-get is more an end user/sysadmin tool and mainly used to install executables/programs. Sure, those also depend on libraries, but in the end, the user usually installs a program.
• Cargo is more developer/language centric and usually used for libraries.

I believe that popular end-user applications developed in Rust will also be made available in the distro package managers including all necessary dependencies. OTOH I don't think it's useful to include every single package on crates.io (and every single version of them) in the distro package managers.