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

[mateus]

Thanks for sharing.

For example, I had a totally different experience regarding cargo, rustc and package management in general. I have never had such a pleasant experience with setting up a working environment. Some aspects were tedious at the beginning but as cargo gets new subcommands a lot of boilerplate code becomes straight forward. Dependency management, error messages and incremental compilation are also getting better. Installing in different platforms and with different compilers became really easy when multirust/rustup appeared.

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.

I also think that things are moving. That’s why I’m considering using Rust again in the future.

[eddyb]

or that you cannot return “something that implements SomeTrait”

Speaking of which: https://github.com/rust-lang/rust/pull/35091.

[StefanoD]

Cargo is really nice. I just think that another package manager was unnecessary.

Sorry, but not every one is using (Debian) Linux. cargo is the best I’ve seen so far.

[vadimcn]

It is really easy if you are calling the functions yourself and if you know how to deal with C code. But it is not what is going on. There are libraries for calling C databases, calling C dynamic loading functions, wrapper libraries, everything. The real deal is that you have to have knowledge about how the compiler manages memory to pass data back and fourth to the library and prepare memory structures on the host program, instead of just calling functions. The compiler will try to manage memory automagically to make things easy for you. That process is awfully documented.

The point of all those wrapper libraries is to put a safe interface on top of the external library. This way one developer can spend the time to understand the intricacies of “pass[ing] data back and fourth to the library”, then everybody else can use it and have the compiler worry about correctness. But nothing prevents you from using “raw” FFI bindings if you wish so.

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.

Would you say that C++, C#, Python and Java are functional languages?

[mateus]

Sorry, but not every one is using (Debian) Linux. cargo is the best I’ve seen so far.

The point is to use your own operating system’s package manager. Even if it is Windows. You could use Visual Studio instead of cygwin but I’m not sure if it can do non-Microsoft things.

[mateus]

Would you say that C++, C#, Python and Java are functional languages?

I would say that C#, Python and Java are multi-paradigm including functional (wikipedia it) and closures are new to C++ 11, which makes it kind of functional. Java is not pure imperative. It is know to be mostly object-oriented.

[StefanoD]

The point is to use your own operating system’s package manager. Even if it is Windows. You could use Visual Studio instead of cygwin but I’m not sure if it can do non-Microsoft things.

That makes things really complicated, because I have to package for every package manager out there and I can’t use my build config for every OS.

[mateus]

That makes things really complicated, because I have to package for every package manager out there and I can’t use my build config for every OS.

Actually you are doing it with Cargo and you don’t even know. When you run Cargo on a platform, Cargo itself was built for that platform. When you call Cargo, it will make a binary to the same platform. This is called a native build. You are using the same config file but you are running a different Cargo on each platform you build. The package is just a file. A zip file for example, but it contains more information such as signatures to verify if the package was not tempered. Creating such package is as easy as calling the package manager of the platform you are using.

Now if you wanted to create different packages using the same platform, you could use the same config file but you would have to use a cross compiler. But it is a totally different story and is just a pain.

[StefanoD]

Actually you are doing it with Cargo and you don’t even know.

Well that’s the point: Cargo is doing this for me. I don’t have to do this myself. I can concentrate on coding. I created once a deb packages and no: It wasn’t easy.

[mateus]

Well that’s the point: Cargo is doing this for me. I don’t have to do this myself. I can concentrate on coding.I created once a deb packages and no: It wasn’t easy.

Fair enough. It’s easy to build Rust code. Just keep in mind that Cargo is language-centric instead of operating system-centric. So if you need anything from the operating system like having a library installed, a server, a daemon, you will have to install it manually. I’m not sure to which level Cargo is capable of building packages from other languages. This is a burden that requires man work - the maintainers. Furthermore, Cargo does not seem to distribute binaries, just source.

[rkruppe]

Many of these concerns either don’t ring true to me, or don’t make sense.

I thought the same when reading the post. I will not go and argue why I think @mateus is mistaken about this and that, because it’s ultimately irrelevant. @mateus is part of the target audience, looked at the resources offered, and came out with the opinions and judgements described at the start of this thread. If these opinions and judgements are surprising or arguably incorrect (insofar this predicate can even be applied), then IMHO the best outcome is not arguing against them but to treat it as a case study for why someone might be disappointed in Rust. This certainly does not mean that Rust needs to be changed to conform to exactly what @mateus expected from it, but:

• Some of the things mentioned are known pain points. These are not the most interesting ones here, because we’ve all heard them a couple times already, but that makes them no less important.
• Some things can be traced to a lack of documentation (as other answers have pointed out). Again, not super specific to this post but still important.
• Another aspect is “not using language features”. To some degree this is personal style, the rest of it might be willful avoidance of the functional programming paradigm. Aside from being a sobering reminder that some portion of the programmer population is not sold on FP, this suggests to me that there’s space for a semi-introductory text that discusses program design (at small scale). Specifically, to advertises the various paradigms embodied in Rust and how to choose between them and combine them. (This idea isn’t solely because of this thread, but it adds another angle to it, the angle of “I don’t even like this paradigm why should I use it”.)
• Some issues are related to the ecosystem, tying into the current “Rust Platform” discussion.
• Some things are really just opinions, on contentious and over-discussed topics such as syntax design philosophy. Not much that can be done about that, but a sobering reminder that there are other opinions is probably good for humility

Finally, I am not quite sure if I understand your issue with FFI, @mateus. 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? I’m asking because one criticism I recall hearing from time to time is that Rust’s FFI is not quite as smooth as possible because one has to deal with the ABI and other issues vs. just including a header and being done.

[regexident]

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.

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.

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.

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.

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{} {
    …
}

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.

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.

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.

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:

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.

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.

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.

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.

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*

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.

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

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.

Coding standard should be optional.

Beg to differ.

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.

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: https://doc.rust-lang.org/error-index.html Such a list won’t help you on an airplane or a dead spot though.

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]

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?

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.

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.

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.

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

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.

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?

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]

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]

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?

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]

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]

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]

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]

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]

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.

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.

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

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

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

This.

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

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

Imposing things is authoritarian.

You’re confusing “having reasonable defaults” with what you call “authoritarian” here.

---

Your comparison sucks.

You probably don’t know how it works.

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.