Rust vs C Pitfalls
garin.io
garin.io
* Great Tooling ( IDEs )
* Great Libraries ( Everything and a kitchen sink )
* Better Documentation
Blog posts wont pull me away from C, tooling and docs will.
If I look at everything I used to write in C, I'd say 80% is well suited for Go and the rest I would fallthrough to Rust for. For the stuff where having a GC and slightly less control is OK, I don't see why I would want to use Rust. Rust is just much more complex and I prefer to keep it simple stupid (KISS).
Basically, Go is good for 90% of what I used to use Java for and 80% of what I used to use C for... trying to understand where it makes sense for Rust to fit in.
(I've used Go and Rust daily for the past few years. I love them both.)
Go that is?
To be even clearer: I don't think Rust's value proposition depends on whether you absolutely must avoid GC or not.
If you don't know anything about rust, you shouldn't respond to a question about rust.
PS. Pozdrawiam rodaka.
It had GC as core part of language, about six or more years ago?
Still, the fact that all those languages are in the top 10 of programming languages kind of says that people don't really care.
I was going to say that rust has performance advantages over Go (due to GC), but look at benchmarks:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
Go wins some and looses some, but it's all in the ballpark (except Binary trees [1] which it loses even to Java(!)).
It's true that rust is a new language, but so is Go.
[1]: I assume it's because it's a test of GC, but Go loses to Java (which, like Go, is a GC language)
Btw. this site is extremly bad for benchmarks since it also measure's the startup time of the runtime in java/go/rust.
For example, many of the Java/C/C++ benchmarks are using custom optimizations that should be illegal for the benchmarking. Case in point, some are featuring custom hash maps that feature hashing algorithms that, while fast, would never be useful as they provide no protection against collisions. You'll see a hashing algorithm in a C preprocessor, for example, that just fakes having an actual algorithm whereas Rust examples are sticking to the tried and tested production-grade algorithms shipping in the standard library.
http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
Imagine you got a million strings of variable length such that the last 4 bytes are guaranteed to be unique value between 0 and 999999. Lopping off the last four bytes is a perfectly good hash function for that kind of data.
So yeah, if you can come up with a tailored hash algorithm that works correctly and is DoS-immune for all possible input for the program, go ahead and use that tailored hash algorithm. But if your hash algorithm is only correct for the specific input data the benchmark game uses, and would not be collision-resistant under real world conditions, then you really shouldn't use that hash as it does not demonstrate anything useful.
Your argument seems to be that that's not the intent of the benchmark which may be true but it's not clear from the rules provided at all. To me, it looks like the opposite is true - they talk about using a standard hash table and most of those allow user-specified hash functions.
They are useful in this case, aren't they? Custom hash map implementation can be also useful in other scenarios. This is feature of the language that allow you to do that so it's not "illegal" to use it. If Rust doesn't allow you to do something while other language does, it doesn't mean it should be illegal.
I don't see any tricks in Go and it's faster than Rust and more memory efficient in almost half of the benchmarks. So what's your excuse for those cases ?
I still can't get all the moral over this.
The best thing here for Rust would be to achieve the best performance on this game and nothing else.
To me this game is important and winning on it is more yet. So, if Rust don't have better result by "morals" this is so wrong that hurts. But each time I read these responses I ask myself if there is not a real problem there.
I like Rust, but performance is decisive. It is really sad to see that Rust keeps going down on this game and that makes me question myself when trying to invest time on Rust.
If, on the other hand, you're just treating the benchmarks as a fun competition akin to code golf, then by all means, hacks ahoy!
I don't know the background of these people, but they couldn't be more wrong. So that looks like "morals" or just they don't ever saw real C code out there.
For example https://github.com/haipome/fnv/blob/master/fnv.c
That's absurd. The benchmarks game doesn't measure real-world performance in any sense whatsoever. And many of the implementations are written in ways that you'd never ever put into production code (for example, the laughably bad hashing functions that are mentioned elsewhere in this thread). From what I understand, the Rust implementations tend to not get up to those shenanigans, which makes them appear worse than the implementations from other languages that do.
It's not the goal of a programming language to be the top on a silly benchmarks game. The goal is to be an excellent language for real-world use.
That is, I think I'm thinking of this:
> k-nucleotide will explicitly require built-in / library HashMap.
https://alioth.debian.org/tracker/?func=detail&group_id=1008...
Since C doesn't have a standard library hashmap, you can write an entirely custom one just for the benchmark. But since Rust has a built-in hashmap in the standard library, you cannot. Even though you could write Rust code that's the same as the custom C hashmap.
http://benchmarksgame.alioth.debian.org/u64q/knucleotide-des...
But they say 'don't write a custom hash table', not 'don't write a custom hash function'. Maybe the problem is that the data in this benchmark is just not a good way to exercise the hash tables in a given language the way the benchmark intended. That probably means the benchmark should be modified; the complaint that some implementations use 'laughably bad' hash functions that seem to be measurably decent hash functions for the data at hand seems really strange.
> Since C doesn't have a standard library hashmap, you can write an entirely custom one just for the benchmark.
NOT TRUE!
#315195 states the opposite!
"k-nucleotide will explicitly require built-in / library HashMap"
Am I allowed to use a custom HashMap for the game, or am I required to use the one in std::collections? My understanding is that it's the latter, and so that penalizes Rust or any other language that includes a map in their standard library.
In fact, the current Rust k-nucleotide DOES use a custom Hash function with a library Hash map.
No one is allowed to -- in your words -- "write an entirely custom [hashmap] just for the benchmark".
(This was all discussed to death, in early December on https://www.reddit.com/r/rust/ ).
Meanwhile, from the task description: Please don't implement your own custom "hash table" - it will not be accepted.
If you want an additional Rust hashmap implementation then you need to persuade the Rust community to provide one in std::collections.
No one is allowed to -- in your words -- "write an entirely custom [hashmap] just for the benchmark".
Again, this means that for Rust, it _has_ to be in the standard library. But C doesn't have one in the standard library. So C gets to write their own, and Rust doesn't.
Another factor could also be that the GC in the Go examples just never runs since it doesn't allocate enough memory. It's hard to say exactly what's happening without tracing the runtime, which would also affect the benchmarks a bit.
It's important to note that while both languages are natively compiled (and I suspect Rust would inch out in that category due to LLVM's backing) most of the overhead would probably be from memory, whether allocations, or cache usage, which makes comparing them in microbenchmarks a little inaccurate.
This is an allocator feature independent of garbage collection; jemalloc does this for example. GCd languages have the potential to do this better since they can do additional analysis whilst tracing for little additional cost, but non-GCd languages can still benefit from this.
I don't speak Rust, so I can't quite tell what's going on here:
http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
But the C hash function is very simple, and probably not at all collision-resistant:
#define CUSTOM_HASH_FUNCTION(key) (khint32_t)((key) ^ (key)>>7)
I am sure that the Rust could be made to do the same thing, but I am not sure that, as-is, this is an apples to apples comparison.
[1] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...
Quote?
Feature-wise, Rust features generics and functional programming via higher-order functions and iterators, which is something that Go especially lacks in. Go doesn't have nice concepts like `Option`, `Result`, or `Iterator`. That's not something I'd personally want to live without today. The Go method is effectively writing boiler plate code everywhere, which leads to much room for error prone implementations that require more testing.
I haven't felt that Rust was more complex than Go, at least when you're actually writing software in Rust. Rust libraries feature semantic versioning and are automatically downloaded and verified at build time based on the contents of your `Cargo.toml` and `Cargo.lock` files. No importing of Git repositories directly required. Go does not provide an equal on that front.
There are a lot of great libraries out there to bring you extreme performance, simply, such as the bytecount crate, which is just a library that features a single function, a function that counts the occurrence of a specific byte, 32 bytes at a time with AVX, with additional SSE/SIMD implementations depending on what the processor supports.
All there is to truly know about Rust is the borrowing and ownership mechanism and how to implement a custom `Iterator`. If you have a solid understanding of both then you've pretty much mastered all you need to know about Rust.
The borrowing and ownership mechanism can be simplified down to: - Passing a variable by value will move ownership, dropping the original variable from memory - Passing a variable by mutable reference will keep the original variable, but allow you to modify the variable. - You may only borrow a variable mutably once at a time, and you may not immutably borrow while mutably borrowing. - You may have as many immutable borrows as you want, so long as you aren't modifying that value. - You may mutably borrow a field in a struct, and then mutably borrow a different field in the same struct simultaneously, so long as you aren't also mutably borrowing the overall struct. - You can use `Cell` and `RefCell` to allow for mutably modifying an immutable field in a struct. - You may mutably borrow multiple slices from the same array simultaneously so long as there is no overlap. - Safe memory practices means that instead of mutably borrowing the same variable in multiple places, you queue the changes to make in a separate location and apply them serially one after another.
Then for the `Iterator` trait, you would know that all traits have required methods, whereby as long as you implement the required methods for your type, you will automatically gain all of the other methods associated with the trait. For the `Iterator` type, you only need to implement the `next` method, and that looks something like so:
``` struct DataIterator<'a> { data: &'a [u8], index: usize, }
enum Token<'a> { One(&'a [u8]), Two(&'a [u8]) } impl<'a> Iterator for DataIterator<'a> { type Item = Token<'a>; fn next(&mut self) -> Option<Token<'a>> { let start = self.read; for element in self.data.iter().skip(self.read) { self.read += 1; // if next value is found then return Some(&value[start..self.read]) } None } } ```
The leaders of Go foster an attitude of exclusiveness (just like a month ago they wanted to get rid of the Go subreddit in favor of a solely Google owned option of Google groups).
The leaders of Rust are very receptive and helpful to new people. They are on IRC / Reddit and many other channels.
I'd much rather invest my time into a truly open language and to me, that is not Go.
Wow, really? Do you have a link to that discussion? That's wild.
It should be a good summary of the event.
To be fair, this was a proposal by a single person on the Go mailing list, and it was in reaction to Reddit's CEO publicly admitting to editing other users' comments. The person who proposed closing the Go subreddit was also under the mistaken impression that the subreddit was hosted by the Go team, which wasn't the case. In the end, there was a lot of discussion, and nothing was deleted. Tempest in a teapot, as usual.
Go has a serious culture problem, but that's not a good example of it.
In my experience, there's a lot of hostility and arrogance. More than in any other community, I've seen Go developers shut down discussion by closing comment threads on Github; reject pull requests and refuse to debate the merits of the change; castigate people for "not following proper procedure"; and being dismissive or contemptuous instead of humble when they fail to understand a problem that is being discussed (on, say, the official Go Slack channel).
My very personal hypothesis is that this is a case of mirroring. The Go development team may be said to have a laconic, authoritarian style, which is, of course, their prerogative, and which befits their position; unfortunately, a lot of Go developers seem to be under the impression that they, too, can behave like demigods. In particular, Go developers, more than other cultures, seem to get an ego boost out of telling people "no".
But this is a generalization. There are lots of friendly Go devs around, to be sure (I hope I'm one of them). I'm particularly happy with the Kubernetes team. At the same time, I do think it's an issue and one that the community needs to be aware of.
This is very misleading. There is no official Go slack channel. The slack channel you are referring is just a slack channel and is by no means official.
> In particular, Go developers, more than other cultures, seem to get an ego boost out of telling people "no".
This is misleading as well. Go was designed from the start to exclude certain features e.g. inheritance and many others. There are usually very good reasons for those decisions that people who've been following Go from its creation know and understand very well.
Now what happens when someone who does not understand those design choices comes to Go? They want their favorite feature obviously! When Go members attempt to explain them why something like that does not exist in Go (and probably will never be included) it starts feeling like "no". And people do not take "no" well. They get emotional and fail to see reason. If they had bothered to explore the language or at least read the official documentation and FAQ, that state of mind might have been avoided.
Including everyone's favorite feature does not make a language better.
Go has created a community around a certain school of programming. Nobody claims that it is better than other schools but it is a fact that it exists. But who is the one that is close-minded in this case? The new person that doesn't bother with the teachings of the school or the school that dismisses the ideas of the new person? Who is really the one that says "no"?
From my experience, the Go developers always carefully consider every new idea that is brought to the table. But it is also a fact that after the 10th time you've seen the same idea, you are not going to sit down and spend time considering it. You are just gonna link a previous discussion and say "Sorry this has been brought up before, please check these". How does that feel to a new person? I bet it feels like "no" again.
I find it pretty terrible that Kubernetes develops on Slack/Github/Videochats. For being an Open Source project, it rejects open source tooling and makes it difficult for people with poor english skills to participate (text-based meetings are much better for inclusiveness). Even if you do listen in on the video meetings, they give you a feeling as an outsider that many of the decisions have already been made elsewhere (some obscure github issue conversation, a google doc comment on a 1 year old doc, etc). It seems the only way to meaningfully participate in the k8s community is to be a known insider... :(
In Go I can only write libraries for Go programs. In Rust I can write libraries for any program.
i.e. Rust can easily produce static and dynamic libraries that are linkable with C programs and any language with a C FFI. I can write Rust code that works for programmers using C, C++, C#, D, Go, Swift, Python, PHP, Java, etc.
That's not true. It's quite simple to create a loadable shared object in go and call it using anything with a c ffi.
As proof, notice that it barely happens, and only as an oddity in Go, yet in rust there are actual uses (e.g. ruby and python library optimization)
[1] https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...
http://www.darkcoding.net/software/building-shared-libraries...
Go is good, even great, at many things. But it's a language largely defined by its limitations, usually intentionally. It's an engineering language, not made for big abstractions. For me, the largest frustration is that the language gets in the way, and the pain increases with the scale of the problem. Which is to say: I think Go scales to large projects just fine, but there are problems where you'd like to build big building blocks on top of smaller blocks on top of smaller blocks, and Go doesn't lend itself to certain kinds of big, composable, data-oriented abstractions. It's small building blocks all the way.
I've bumped into several very real problems recently where Go's coarse, not-very-data-oriented imperative approach has revealed itself as a liability, and where I found myself fantasizing how I could have done it in just a few elegant lines in Haskell. Sometimes they're about expressing things simply in a composable manner, and sometimes these problems simply manifest themselves in immense blobs of boilerplate/repetition (for example, because you have to implement the same method a few dozen times on different data structures, which in a different language could be solved with a generic implementation), where Go's solution is to either eschew type safety, use slow reflection APIs, or programmatically generate the Go code as part of the build process.
Go's is also frustrating in its selective pragmatism. Where Go has chosen to automate and sugarcoat some complicated things (memory management, goroutines), it's stubbornly unpragmatic about other things (error handling, working with polymorphic data, memory safety). Go has been ridiculed for its simplistic error system, but I'm not an extremist here; I'm all for errors being values, and not a fan of exceptions. But if you look at actual Go code, a huge amount of code has to interact with errors. When nearly every function is riddled with "if err != nil", you should know that your language is crying out for just a little syntactic sugar. Or a solid type-system solution for that matter. Enums (Rust-style) and pattern matching wouldn't go against Go's grain at all, but since Go is "done", we're stuck with how it is.
I think Go's focus on simplicity is very important (I'm a big fan of the Wirth school of languages), and my worry about Rust and Swift is that they never learned this lesson. To me, both Rust and Swift looked more promising early in the design process than in their current state; Swift looks increasingly like Scala every time I visit it, whereas Rust often feels lost in a sea of punctuation. That said, my annoyance with Go is acute enough that I'm willing to deal with a few downsides if I can get a language that better matches the kinds of projects that I build.
FWIW the Rust team does consider simplicity to be important. However, it's not the only goal, which means that sometimes it has to be sacrificed to be able to make something possible. But most new language features do get discussed in the context of a "complexity budget".
So Rust tries pretty hard to ensure it doesn't get more complex than it has to; but it doesn't put simplicity as the overriding goal and hang all else to get it.
> Enums and pattern matching wouldn't go against Go's grain at all
I've said this many times before -- I don't miss generics from Go; I understand why they're not in the language. I miss ADTs and pattern matching.
I've tried learning C/C++ at several times but I just don't have the inclination to have to bother about null-terminating strings, etc in 2016. I don't mind spending a little more time getting something to compile if it prevents silly mistakes.
Having said all that, it's obviously too early for me to say whether I like Rust. I'm picking it up pretty quickly since I know FP thanks to Scala, but I'll see how much time I spend fighting the borrow checker.
(I think it's even better, but I'm biased)
One I can note is that I really like the new sections. I've never quite liked that the current book is just a bunch of chapters all in a row. Not that that's necessarily bad in and of itself, but I do think the new way is better.
!(event.ctrlKey || event.shiftKey ||
event.altKey || event.metaKey)
I've written C-like programs in Rust, and that goes very well. But I really like function overloading, generic operators that I can overload from the left and the right, integer parameters for my templates/generics, copy semantics as the default (opt-in for moves), placement new, explicit destructors, and maybe a few other niceties. Rust does none of these things the way I want, and so I'm stuck with C++.
There are a few other things where I think Rust just made the wrong choices and didn't improve over C++. I've always hated the dichotomy in C++ strings between const char* pointers and an actual string class. Rust had the chance to make strings feel as comfortable as integers, but instead they introduced their own dichotomy with String and &str.
Speaking of integers, Rust's choice of 32 bit integers as the default for literals is painful given that every machine most of us will ever care about is now 64 bit. I routinely deal with arrays and files that are too large for a 32 bit integer. This means I have to remember to suffix all of my integers in for loops etc... C++ has this wrong too (backwards compatibility), but Rust had a chance to make a clean start and did not.
I do too, and I'd like to think that rust needs all those things to be a replacement, but realistically I think that the only killer feature that rust is still missing is reasonable interoperability with C++ (which admittedly might require implementing a few of those features).
Disclaimer: I have been following rust since Graydon initial announcement, but I have yet to write a single line of code in it.
Arrays are indexed by usize, so if you're on a 64-bit machine, then you shouldn't need a cast. It's _unconstrained_ numbers that default to i32, not anything without a suffix.
I would prefer a str be a str be a str, regardless of how you got it. Lowercase type-name and fundamental like an integer.
I'm fairly certain I understand why Rust made the choice they did. I've read the forum threads at HN, Reddit, and users.rust-lang, and I've seen previous replies by you and other Rusties, so I hope you won't try to educate me about the performance advantages of having slices as references and another string type as an ownership class or why we need OsStr and friends.
If strings are the fundamental processing concern in your application, then I think you should be able to opt-in to that kind of micro-optimization and complexity, but it would've been better to spare the rest of us who have different concerns. I don't want to become a string expert to build a filename, and the default implementation could (at least conceptually) be always on the heap for all I care. Go one step further and implement the "small string optimization" (Alexandrescu's fbstring), and you'd probably get back most of the performance without nearly the complexity.
> Arrays are indexed by usize
I've spent the last half hour trying to troubleshoot why this line hangs:
let aa = vec![1u8; 10e9 as usize];
Anyways, I wanted to test the commented out line, but I'm stuck for now. If that line would work, I'll admit I was wrong, but I think the uncommented line shows a similar complaint.
for ss in 0..63 {
//print!("{}\n", aa[1<<ss]);
print!("{}\n", 1<<ss);
}
Looking at the present and the future, why is that a sensible default? Both x64 and ARM are going to use a 64 bit integer register for the operations, and many of those operations are going to be 1-clock throughput. You can probably find a counter example, but 32 bit integers aren't generally faster than 64 bit ones.
No, I'm interested in what tradeoffs you would have made differently. I now understand. Thanks! (I disagree, but at least I understand.)
> why this line hangs:
It compiles and runs effectively instantaneously for me on Ubuntu under Windows as well, so that's very strange. Maybe file a bug?
> I think the uncommented line shows a similar complaint.
Yes, there's no constraint on that literal, so it's going to be an i32. When we made this decision, we did some analysis, basically no numbers in real world programs weren't constrained, it was often tests, toy programs, and documentation. It should be a rare thing. YMMV.
> why is that a sensible default?
Your assertion about the speed was the opposite of what was asserted while we had the discussion, basically. And not everybody is running on 64-bit hardware, so it's a broader default.
The fact that C and C++ compilers generally chose to leave int at 32 bit on 64 bit platforms, combined with the standards requiring "usual promotions" for smaller types to go to int bites me all the time. I'm very happy that Rust dodges the promotions problem altogether, and I'm sorry if I'm wrong about the array subscripting thing (does the snippet I provided panic at 1<<32 or 1<<34?).
> And not everybody is running on 64-bit hardware, so it's a broader default.
That argument could be used to justify 8 or 16 bit integers... :-)
Overflow is a "program error", and in debug builds, is required to panic. In other builds, if it does not panic, it's required to two's compliment overflow. Rustc currently just overflows, but in the future, we'll see.
That's true except our 16 bit support is nonexistant at the moment :)
If you pay attention to your usage statistics, I'll bet you drop 32 bit support before the May 2025 deadline we were discussing in the other thread.
Follow-up: I tried it with -O (don't know why I didn't think of that earlier), and it runs fine. So maybe the debug version is just generating terrible code, initializing by iterating through 10 billion bounds checks or something?
Anyways, more importantly, it works as I would like and does not behave as a 32 bit integer. I think I understand what you mean by "constrained" now. And clearly, I was wrong.
However, if most un-suffixed integers in real-world programs will become constrained (as you claimed), this further confuses me why i32 is the unconstrained choice. It doesn't seem like something so rare could be enough of a performance problem to justify being anything but the largest supported size.
I remember installing it by cut and pasting one of the "curl ... | sh" commands there.
> Nothing about that code should be doing bounds checks, as it's just allocating an array.
I didn't dive into the macro definition for vec!, but I assume there is a loop in there to Copy the initialization element 10 billion times. I think you guys do bounds checking on the lower level reference to a slice that Vec uses. But I really don't know. If it's not that, then it was hanging or spinning doing something else. (Debug version of your memory allocator?)
The lowercase type names are reserved to primitives. The String type is not a primitive but a comprehensive data structure, hence the capital S. The String type contains an `str` primitive though, along with size information.
> I don't want to become a string expert to build a filename, and the default implementation could (at least conceptually) be always on the heap for all I care.
Is it that hard to understand that when you create a string, you will create it as either a `String` or `PathBuf`? File methods are designed to automatically convert input parameters into a `&Path` so it doesn't matter what string structure you provide.
There is also no way (currently) to create a stack-allocated string with the standard library out of the box. You can do this with crates like `arrayvec` though. It's very much opt-in for that performance.
let path = String::from("/tmp/file");
let mut file = File::open(&path).unwrap();
> Looking at the present and the future, why is that a sensible default? Both x64 and ARM are going to use a 64 bit integer register for the operations, and many of those operations are going to be 1-clock throughput. You can probably find a counter example, but 32 bit integers aren't generally faster than 64 bit ones.
No need to use a 64-bit integer when you only need a 32-bit integer. You can fit two 32-bit integers into a single 64-bit integer and perform a calculation on both simultaneously with a single cycle, versus spending two cycles to calculate two 64-bit integers. There's also no need to pay that memory cost either.
It makes perfect sense when you understand the differences and reasoning behind it. A `String` is a heap-allocated string that can grow in size. On the other hand, a `str` is basically a fixed-size string array, but you'll never interact directly with this type because there's no point in it. It's tucked away inside the `String` that created it.
Meanwhile, an `&str` is a slice of that fixed-size `str` array that's hidden within the `String`. You can think of a `str` as an `[char]` with it's own special `str` methods, and an `&str` as an `&[char]` which has access to all of the `str` methods as well.
> Speaking of integers, Rust's choice of 32 bit integers as the default for literals is painful given that every machine most of us will ever care about is now 64 bit. I routinely deal with arrays and files that are too large for a 32 bit integer.
I'm pretty sure the default integer is a `usize`, which is 32-bit on 32-bit systems and 64-bit on 64-bit systems.
Rust will type error if you try to use u32s with an array so it's all good though. Just means that you need to specifically `: usize` things.
If you need an integer type for counting stuff, u32 is fine. If you actually need to talk about memory, use usize. The compiler will force you to do it.
Maybe I'm missing something, but it seems to be i32: https://play.rust-lang.org/?gist=c79d4afef7fa20c81ba14de61f5...
If you're stuck with C++, might as well do it safely:
(shameless plug) https://github.com/duneroadrunner/SaferCPlusPlus
I might be wrong though. What happens with your vector in this code?
using namespace mse::mstd;
vector<double> data(10);
double& dangling = data[0];
data.resize(100000);
double crashing = dangling;
The problem here is there is only one operator[] for both reading and writing. This is a simple contrived example, and taking a reference like that looks artificial, but there are a lot of other ways in real programs to stumble on to this. (I don't think it's as bad as the Rusties do, but I stumble into this bug once or twice a year...)
The Rust folks seem to believe you need a borrow checker to solve this problem, but I think that a different container library in C++ could do the trick. For instance, favoring value copies instead of references, and returning a proxy object from operator[] instead of a reference.
double& dangling = data[0];
auto not_dangling_iter = data.begin();
// not_dangling_iter += 0;
And while I can overload the & (address of) operator to "prevent" you from getting a native pointer to a "safe" object, I don't know if there's a way to prevent you from getting a native reference. If you wanted to somehow enforce a prohibition on the use of unsafe C++ elements (like references), that would probably require some sort of static tool that is not yet available. But should be fairly straightforward to implement, I think.
But if you just want some confidence in the safety of the code you write, it doesn't take much effort to reliably avoid using C++'s unsafe elements.
Oh yeah, maybe. But that would still require the ability to overload the dot operator, wouldn't it? And how would you know when to deallocate the proxy object? And presumably there would be some run-time overhead. Hmm, I don't know if it wouldn't be more practical to create a static tool (or "precompiler") to automatically convert references to (safe) pointers (or iterators).
mse::mstd::vector<mse::TRegisteredObj<std::string>> data(10);
data[0] = "some text";
mse::TRegisteredRefWrapper<std::string> dangling = data[0];
data.resize(100000);
try {
std::string crashing = dangling;
}
catch (...) {
// expected exception (not a segfault)
int q = 3;
}
[1] https://github.com/duneroadrunner/SaferCPlusPlus#tregistered...
Yes, the language is supposedly not undergoing breaking changes without strict deprecation and feature-gating. However, as new features are added to the language, libraries are usually updated to leverage them, and suddenly you are also forced to keep up with that rapid release cadence to ensure your project still builds.
Meanwhile, C code from the mid-80s still compiles with modern compilers, often without any changes whatsoever, and without any feature gates.
Don't get me wrong. I like Rust and what the project is trying to do. But I see two major problems that are preventing me from using it for anything major at the moment: 1) the extremely rapid rate of change, and 2) difficulty of implementation (both of which, taken together, lead me to expect no serious alternative implementations any time soon).
Before I will be willing to adopt Rust as a C replacement in full, there needs to be a solid, stable language definition that compiler writers can target and programmers can rely on for a good chunk of time. I have a feeling we'll get there eventually once the number of new, useful features that are missing from the language starts to dwindle and it begins to stabilize naturally.
In the meantime, I'd settle for an "LTS" release or something. That could work.
> In the meantime, I'd settle for an "LTS" release or something. That could work.
This is something we've discussed. I imagine it will happen. At first, I would expect six month LTSes, then longer ones as time goes on.
The company that employs me just upgraded to a C++11-capable version of GCC three months ago. Even C++'s three year cadence seems like it might be too fast! Thing is, the company wants to vet our entire platform, which itself only changes yearly. They want to know they can get bug fixes, and vetting/upgrading the compiler is a lot of work regardless, so they tend to do one and stick with it for a while. OpenBSD does the same thing for security reasons. If Rust wants to replace C and/or C++, these are things that will need consideration eventually. I don't see my company allowing Rust any time soon, unfortunately.
As a compiler-writer, I'm more concerned that Rust is a quickly-moving target at the moment. I think that as Rust becomes more mature, it will naturally begin to stabilize feature-wise, in which case something akin to the Haskell model would work well, with innovation happening in the flagship compiler and "snapshots" of the language being taken as standards periodically. That's just a matter of time, though.
And why should one invest time for such a low-level component in their toolkit every 6 months?! I want to build software and solve problems, not spend my time keeping up with programming languages and library updates.
You seem to come from an experience where software updates are kinda sorta mostly backwards compatible. Rust works very hard to actually be backwards compatible. There is infrastructure to check for regressions across the entire package ecosystem, which is run regularly on HEAD and on any commit we think might potentially be breaking before we even land it.
Your dependencies don't upgrade themselves. Its true that if you upgrade your dependencies, they may depend on a more recent verison of rustc, in which case you need to upgrade rustc as a part of upgrading that dependency. But if you are using rustup this is not harder than upgrading those dependencies - probably easier in fact.
In exchange for downloading a tarball at most every six weeks, you get a language that is developing new features.
You say that like it's a good thing that with C, you can ignore 30 years of progress in software development. Colour me unconvinced.
That's not a responsible metric. 30 year old software was written against 30 year old APIs vulnerable to known attack vectors, and with 30 year old notions about security. The belief that this software is suitable for modern use is absurd IMO.
And if the types of programs you're talking about are small UNIX-like utilities, well then they're small and easily updated aren't they?
Except most people don't consider those as criteria at all. The only criteria considered are "does it run and produce the output I want".
Lots of software we use day-to-day is old. For example, a couple years ago I fixed a 20-year-old bug in netcat, which itself hadn't been updated since the mid 90s. After I fixed the bug, I didn't need to fish out an old compiler or any compatibility libraries; I just compiled it with the latest GCC and glibc, and carried on with my day.
Don't get me wrong, I like Rust a lot and I'm excited that there's finally a real contender for the systems programming throne after all these years. I'm just less enthused about the prospect of refactoring my codebase once every few months to stay current. This is something that I think will level out with time, though. C itself was almost 20 years old before it was standardized, after all. I don't think it will take Rust that long, and I look forward to the day my copy of the Rust standard arrives on my doorstep.
Let's assume this is true, brand-spanking new software will be written against 30 year old APIs that have survived 30 years of attacks and audits, but will avoid the ones that have proven vulnerable.
> I'm just less enthused about the prospect of refactoring my codebase once every few months to stay current.
The perception that you need to do this is false. You might feel pressured to refactor simply because of new syntactic improvements that make code clearer (like switching try!() macro to infix ?), but that pressure is a fiction. There's no real need to do it.
Could you show me an example where post-1.0 you wouldn't be able to do this with Rust?
What the rapid releases do affect is the rate at which new releases of libraries stop working on older compilers, which absolutely has to do with ignoring progress.
The actual Rust API has changed very little since the 1.0 release. All the changes that have occurred have been mere additions to the language -- nothing breaking. Hence why the 1.0 release was termed as a 1.0 release. There won't be anything happening that causes breakage until a 2.0 release.
You'll find that C compiler and library development is also rapid like Rust. There's new versions of LLVM/Clang and GCC being released on a regular basis. There are constant updates to musl and glibc. These changes tend to break far more often than Rust, which is developed in Rust and can be guaranteed to be much safer.
That Rust is being openly developed on GitHub with a significant number of developers, with an official compiler + library + doc + comprehensive suite of resources collectively being maintained, that's a significant incentive to work with Rust. There's a solid RFC process to prevent anything silly from entering the language. No random decisions by random people -- it takes a lot of convincing to add a new feature to Rust.
Anyway, I don't think that's a problem with my concept at all. What I want for Rust, and what I think will eventually be feasible for Rust as the language matures, is a standard that can be shared by compiler writers and Rust programmers. A standard is worthless if it's inadequate (see ISO Pascal or ISO Basic, for example), so it's a good thing that right now Rust is iterating quickly and improving rapidly. But eventually, there's going to need to be a stationary target for compiler writers to aim for, and for Rust programmers to be confident that the code they write today won't be littered with deprecated features, anti-patterns, and worst practices tomorrow.
Frankly, I don't see wide adoption happening in the corporate world until there's an LTS compiler at the very least.
The fact that someone says on HN "we're backwards compatible" doesn't quite offer the same level of trust as an ISO standard. Especially when there are some conflicting reports out there i.e. there are many super-awesome libraries that only work with nightly (I think it's called), because many of those maintainers are early adopters that love to try out new features.
Programming languages and libraries are building blocks, I don't want them to change under me in the middle of a project. This is why I dropped Swift, the 1.0 -> 2.0 migration was a very painful, and from what I hear recent major version changes aren't running smooth either.
This is totally orthogonal to whether or not Rust stable is backward compatible, which it is. People put a lot of work into making sure it is, and this sort of FUD is very frustrating to read.
Then you shouldn't take the word of a random person but from the Semantic Versioning guidelines. If you're not following the semantic versioning guidelines then you're doing it wrong.
> Especially when there are some conflicting reports out there i.e. there are many super-awesome libraries that only work with nightly (I think it's called), because many of those maintainers are early adopters that love to try out new features.
Totally irrelevant. Very few libraries, if any, require a nightly compiler. The libraries that do offer features that require a nightly compiler have those features as optional. Anyway, once the new Macros update releases, the need for that nightly compiler will go away. These libraries are just taking advantage of compiler plugins.
What you're describing is the spec and not the implementation. An implementation would be glibc (GNU Libc with open source proprietary extensions) and musl (MIT implementation that strictly adheres to spec). These libraries are updated often.
Meanwhile, Rust offers more than just a specification. It offers an implementation. This is libcore-rust + libstd-rust. This is what receives updates each 6 weeks. It also offers a compiler that comes with it, rustc, which is also what receives updates each 6 weeks.
Rust strictly adheres to semantic versioning, so changes to the API are not allowed without a major version bump. Code that was written for Rust 1.0 will still compile on Rust 1.15. Code written for Rust 1.15 may not compile for a Rust 1.0 compiler though because bumping the second version implies adding new features. Rust doesn't yet utilize a patch version though. There's never been any critical issues discovered in each stable release.
> Frankly, I don't see wide adoption happening in the corporate world until there's an LTS compiler at the very least.
Can't say that I understand why a LTS compiler would be required for adoption. Many in the corporate world are already using Rust, either publicly as an official friend of Rust or privately in smaller projects. There's nothing a LTS compiler would provide that would be beneficial to the corporate world. Semantic versioning and the ease of managing Rust toolchains with rustup has everything pretty well covered.
As to my own concerns (rather than corporate concerns), here's where I'm coming from:
When I wind up choosing C for a particular project, I don't use it because I like it (I don't particularly like C). Typically, I use it because there are three factors I've considered: 1) This particular project needs the low-level access or performance characteristics provided by a systems language, and 2) C is such a language, 3) C is ubiquitous.[1]
The thing is, every platform for the last 25 years or so has had a reliable ANSI C compiler. If the goal of my project is to be cross-platform, then a carefully-written application in standard C is guaranteed to be able to reach the widest number of users, many of whom won't have to do or install anything to build my application, since many environments already include a C compiler without any additional installation necessary (think Unix, BSD, a shrinking number of Linux distros, ...). Using C puts my application on the path of least resistance for potential users.
Similarly, if I'm writing a library, every language with an FFI can trivially access a library written in C. Even without an FFI, most languages can interface with C code through some kind of bindings (like the Lua-C API, for example). Again, choosing C is a path to wide adoption.
Again, I don't particularly like C as a language. However, right now, it has an undeniable advantage as a platform. I do like Rust, however, and I would love to see Rust give C the boot. In order to do that, it needs to eventually (one day when the rate of additions/changes to the language has slowed and it has grown more stable/mature) offer a platform that can be relied on to "just work" on any given platform with minimal fuss and without any sudden changes. As such, both the "end-programmer" and the compiler-writer in me would like to see some version of Rust (again, eventually) that is "set in stone" and widely available, which really would solidify that notion of stability/maturity.
I'm not advocating for Rust to stop innovating. For all I care, the "standard" can be a simple snapshot of some state of the language, the way the Haskell Reports seem to be nowadays: GHC keeps on iterating and innovating the language, yet there's still a standard updated every x years that provides a static target. But for that designated snapshot, I want to see a compiler (or two, or several) and a bunch of libraries that are supported for the long haul.
It's simply a matter of "C has this, it's an important property thereof, and any replacement will need it, too".
[1]: Some other projects demand C because they constitute contributions or extensions of other projects that are already written in C; e.g., kernel code for an existing OS that is written in C.
Or stop using other peoples' code and just use core language features and build everything from scratch. Which is what I end up doing, and it has some benefits. But it definitely slows you down.
It can do (roughly) everything C can, i.e. it's natively compiled, gives control of memory layout, and doesn't depend on a GC runtime.
Previous C killers were either dependent on a fat runtime (which isn't a big problem in general, but is a problem for some of niches dominated by C), or didn't offer meaningful improvement in safety/concurrency/expressiveness.
Note: Rust executables can be trimmed down by stripping them (not done by default, even for release builds) and using libc malloc instead of jemalloc. But even then, C wins by a lot.
Relevant blog post: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...
C links dynamically to its libraries. Rust does not (by default).
This overhead is a constant overhead so it rarely matters. When it does, you can strip it down further and get it to the same level as C.
This is not evidence of a fat runtime, just a different default compilation strategy that prodces larger binary executables. jemalloc is (an optional) part of the runtime, but the rest isn't.
I suspect rust hello world using those libraries is due to a lack of LTO? Hello world doesn't need any of those.
You'll get different results if you compile them with musl for truly static and fair binary size comparisons.
if I remember correctly you should compile with --nostd flag and provide _start function for loader to load your executable!
you can do same with rust too (But I think you should provide a special flag for compiler). You can find all of it on documentation.
* "First viable replacement for C" - C++ was invented decades before Rust.
* "Well-written C programs translate almost 1:1 to Rust" - C programs can be compiled with minimal changes as C++.
* "or didn't offer meaningful improvement in safety/concurrency/expressiveness." - C++ offers major improvements in all of those areas.
A lot of C programmers don't want to switch to C++ and they won't want to switch to Rust either, because they favor simplicity and neither Rust nor C++ are simple. They'll probably switch to golang for some stuff if anything and just stick to C for the rest.
Rust is complex because it's powerful.
C++ is complex because it's a mashup of overlapping features from different eras.
I don't write C++, because whatever I write will crash for subtle reasons and I'll be told it's my fault, because of course you don't do this when you use that feature.
I can write Rust with all its complexity, and as long as I get it to compile, I'm confident it works more reliably than any C++ that I could have written.
Blog posts are one way to showcase tooling, perhaps not this one, but they have their place.
Which is undersold in the propaganda! Safety, ehhh I'll take it but I'm not jonesing for it. A package manager that works and has adoption? Thank you! I've wasted far too much time wrangling C++ dependencies by hand...
What do you feel is actually missing from Rust? Nothing has stopped me from replacing C entirely on the low end, and even the high end for application software development.
A solid NumPy-like library, for one.
Fast and easy to use are UI tricks that can't be handled by a server.
Edit: I just realized that this may be read in a negative connotion and I didn't mean it like that. I just mean that I'm not the person who should be looking at those. I just know it doesn't exist yet and I'd like it to. Telling me of the Rust Server thing gives me no information as to how close the IDE is to being done.
- There's Atom with Tokamak, which you must also install racer and clippy via cargo to get rapid in-line linting.
- Then there's Visual Studio Code with RustyCode which you can also integrate with racer and clippy, that provides faster code completion and hovering over items will show a tooltip that documents that items.
- Some people like IntelliJ Rust, but I've not tried it myself.
As for installing racer and clippy, it's been made a lot easier recently via rustup:
rustup component add rust-src
rustup component add rust-docs
rustup toolchain install nightly
rustup run nightly cargo install clippy
rustup run nightly cargo install racer
Now you're good to go.
As for NumPy, there's official crates like the `num` family, which provides a plethora of useful numerics capabilities. It's not my forte though so others would know more about the best numerics crates outside of the `num` family. If you know what functionality you are looking for, it may already be created and is searchable at Crates.io.
Most Java/C# IDEs will get you:
- Type-based autocomplete (racer/YCM/etc have this for Rust)
- Jump-to-definition / documentation (YCM/etc has this)
- Autoimport
- Non-grep-based refactoring
- Auto-boilerplating: for example, type `impl Trait for MyType` and have it tab-complete to a skeleton trait impl
- Some error integration (not just fileline jump-to), with tooltips and stuff asking you how you want the IDE to auto-fix the error
- A bunch of other smaller useful things which I can't remember at the moment
Now, autocomplete is a major chunk of this, but nowhere near being all of it.
The way I see it there are two camps on this issue. There's the "text editor" camp who use vim/emacs/sublime and when they are asking for IDE support they just mean autocomplete and jump-to that works from their editor. Then there's the camp coming from Eclipse or VS who want the whole deal.
The Rust Language Server project (https://github.com/jonathandturner/rls) is working on exposing this info from the compiler in a structured form so that IDEs and "text editor"s alike can get IDE features.
Rust does have lots of numeric crates. Too many. I took a look at matrix multiply functions recently.(See [1], below "Here is what the Rust compiler actually does", for some notes on the effectiveness of Rust's subscript checking optimization.) "algebloat" wouldn't compile on stable. "matrixmultiply" is all unsafe code, with C-type raw pointers. "ndarray" has unsafe indexing. "scirust" has more raw pointer manipulation. "matrices" is an empty project.
In the "num" crate, there are bigints, along with rationals and complex numbers, but no matrices. "numeric" has matrices, but it's just a wrapper for some common C libraries. (Also, calling "panic" for a singular matrix in SVD is kind of drastic.[2])
Each of these matrix crates has its own representation for multidimensional arrays. You can't mix them easily.
Matrices in Rust really need some standardization.
[1] https://news.ycombinator.com/item?id=13230551 [2] https://github.com/numeric-rust/numeric/blob/master/src/lina...
Every matrix package I've seen so far in Rust turns off subscript checking with unsafe code.
[1] http://graphics.stanford.edu/courses/cs148-10-summer/algebra... [2] https://docs.rs/crate/nalgebra/0.10.1/source/src/linalg/deco...
The whole point of Rust is to put an end to that.
We've had this discussion before. ndarray exposes both a safe and unsafe API for indexing, just like the stdlib vector (or core arrays). That is not problematic.
I agree that the lack of standardization is a problem, though. I think that mostly folks use ndarray or nalgebra (and num if they need bigints). Anyone can upload a crate, the question is if the crate is the main one used by the community. There are some efforts to make it easier to choose crates amongst alternatives on crates.io, however.
I suspect most of the issue here is just that no group (only individuals) is using Rust for scientific computing yet, so there's no large driving effort behind getting good libraries here. When I needed this in Rust I just picked the library that I thought would work best with very little thought, with no thoughts on writing my own or improving the lib because I didn't have time. When larger groups work on things generally attention gets paid to stuff like this and better solutions come out on top. Rust isn't quite there yet in adoption for this to happen, maybe soon :)
For 1D, though, the optimization of checking is pretty good. "get_unchecked" for Vec may be obsolete. There's an amusing Stack Overflow question [1] from someone who complains that he changed an access from "[]" to "get_unchecked()" and his program didn't get faster.
Maybe it's time to deprecate some of the legacy "unsafe" stuff. Preferably before the first CERT advisory involving a buffer overflow in a Rust program.
[1] http://stackoverflow.com/questions/39196594/why-dont-i-get-p...
Sometimes you don't want to rely on LLVM, and sometimes the size invariants aren't as easily available to LLVM.
I'm not even sure if this would be that necessary outside of the library itself; unchecked indexing would be useful to implement ops like matrix multiplication within the library, once, and probably never used after that.
The API exists mostly to mirror the stdlib one and its use cases. I don't think it's supposed to be the API you reach for usually. Just because the API exists doesn't mean it's the one you're supposed to reach for.
> That may improve, especially if there's some standard idiom for declaring multidimensional arrays and the compiler handles that idiom well.
I mean, multidimensional arrays do exist in the language. I'm not sure what you're getting at here.
These libraries provide support for treating multidimensional arrays as matrices, with the semantics of matrices (multiplication, addition, etc). You seem to be arguing for making this a first-class compiler feature? I'm not sure how that's very different from just implementing it with some unsafe code -- the bug-prone-ness of the unsafe code is about the same as the bug-prone-ness of a compiler optimization that replicates it. There is a case to be made for moving it into the stdlib itself to avoid the "10 ways to do it" issue, but Rust wants to keep the stdlib small so that's not going to happen.
This is the point of unsafe code. You use it to implement a few safe abstractions like matrix multiplication and iteration in libraries, verify that, and use them. There's a stigma attached to unsafe code; rightly so; because there be nasal demons. But we shouldn't take it to its extreme and conclude that all unsafe code is bad.
> "get_unchecked" for Vec may be obsolete.
Wouldn't count on it. A single datapoint doesn't really mean much here.
I mostly see get_unchecked being used in the context of other unsafe code. Rust's stdlib uses it for the internals of CString and for implementing iterators. It also uses it in an optimization for the rand crate; which does some trickyness with bitmask indexing that LLVM might optimize but I suspect the authors didn't want to rely on LLVM optimizing.
Servo doesn't use it at all, though. Going through my cargo cache dir the crates that use it are those which implement abstractions. Some, but not all, of the use cases there probably get optimized out anyway. The regex stuff also uses it but the invariants there are complicated enough that llvm won't optimize it (there are some decent comments listing out these invariants and explaining exactly how to use it safely, though).
IDE support is easily better for java. IDEs have total type knowledge since they directly integrate with the compiler, including in long chains of type-inferred code, usually even while you're in the middle of typing and your code is in a syntactically invalid intermediate state. They also automatically manage imports where needed.
Similarly, IDE-integrated debuggers can do a edit-code, recompile, hot patch into running application while you're stepping through the code.
CPU Profilers seem about en par, but memory profilers in java are again better because they offer a combination of taking heap dumps, allocation recording and diffing dumps at the same time. While also offering good GUIs for exploring object graphs.
What are they going to teach in school? What are new systems programmers going to start with? I suspect it'll be rust and go, not c.
Do you have any data to support this claim?
To recap this has been my life as a programmer: Java -> JavaScript -> PHP -> Python/C/Assembly
This dream that most people have made up about programmers not switching languages is a dream. I switch whenever one language can do a task better then another. I don't get caught up in "best language" fights.
I play with a lot of languages but I've invested a lot of time into learning python and getting a nice python workflow going. It would take a lot for me to switch to another primary first language.
I work at a tech company that's been around since the 90s and the guys that were writing perl and java in the 90s are still writing perl and java. You'd have to drag them kicking and screaming into using a different language.
What may look like "bah humbug I'll use X because I like it" may just be picking a language on concerns not limited to features. Looking at social concerns is important as well. Who is maintaining your code after you're gone? Company tooling for certain languages? Will I get fired for using it (AI winter)?
Lots of big questions
Or is it?
I regularly use six different languages of three paradigms and various abstraction levels, and this doesn't count DSLs nor Turing-complete tools like make. Of my colleagues from current job, half of the more experienced set write in at least three languages as well. Of the team from my previous job, all of them are polyglots. And of course none of us started with all the languages, we picked them up as needed and wanted.
It crosses boundaries.
I'd say the greatest part about Rust is the community, which realizes all of the issues you've listed, and especially the really tough learning curve for beginners.
Generally, use the right tool for the job. I don't think I'd really want to use Rust in production yet, but it's really great for side-projects and other more experimental things.
Why not out of curiosity? I've already been showing off to people at work how much shorter Rust code is than our corresponding Java, how much easier it is to build and deploy, and how much more stable it is.
Granted I've been using it at small micro service scale at the moment, but I see no reason not to go into production at the moment (well, except for the fact that I'm the only one that will be called at night if it fails... luckily it hasn't, and I'm not worried).
I don't really get this attitude, it means that nothing new will ever overcome anything that's been established.
> Anything that can be done easily in C or C++ will need to be easier in Rust for everyone to move
You don't even need folks to move from C. Rust has had lots of success when it comes to folks completely new to systems programming learning it through Rust. Predominantly python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues.
> Blog posts wont pull me away from C, tooling and docs will.
Then you are not the right audience for this blog post :) I find that such blog posts are extremely helpful in convincing people who have a choice between starting to use C and starting to use Rust, not folks who are already invested in C or C++. But I have seen such overviews to have impact on invested C/C++ programmers too; everyone is different!
> I don't really get this attitude, it means that nothing new will ever overcome anything that's been established.
I think he's trying to quote Dan Saks' "extern c: Talking to C Programmers about C++" when he said "If you're arguing, you've lost." Saks, at least, meant that if you're striving with someone, you've already lost because your partner is already in a "frame" of mind set against your arguments that is unbreakably strong, even by logic. The talk is really good just for that aspect.
But that's a valid point.
http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend...
http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_i...
The most popular(hotspot/openjdk) is written in c++/assembly
Java is safer than C, but it's a long way behind a modern functional language like Rust.
(Java also has a not so great reputation about speed. That one also comes from the Java plugin, which often took minutes to start up, while keeping the Netscape browser UI locked up.)
Unless you need guarantees that can't be offered by garbage collection.
Edit: Check out https://dzone.com/articles/understanding-sunmiscunsafe
Hardly, compared to anything that takes user input and aims at 60/120 FPS (where you inevitably end up bypassing GC if you can't force it to run when you want to).
https://www.quora.com/Is-Java-overtaking-C++-in-the-HFT-worl...
> One thing about HFT is that the speed of the language oddly doesn't matter much. You are talking about latencies of 20 milliseconds, and any language can do 20 milliseconds since CPU times are measured in nano-seconds rather than milisecond.
and
> If you are playing in the sub 10 microsecond range doing everything in C++ helps a lot. [..] A lot of high frequency strategies run in the 20-30 microsecond time frame. I think this is where a lot of diversity in terms of setup occurs.
and
> To lower execution costs, we need a low latency system that has good determinism in response times. You cant pause for hash table rebucketing or garbage collectors or the OS taking away your time slice or moving you to a diferent processor or whatever. There are guys who try this in Java, and spend most of their time trying to make Java work deterministically. Good luck
and
> If you are in ultra HFT then C++ is the only answer (besides custom hardware - FPGA & ASIC). You just can't afford garbage collector.
Context is pretty important to the original comment:
> python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues.
they're not looking for a fast language in isolation, they're looking for a fast language in the broader context of their existing technological stacks. Java doesn't help that much when you're looking into ways to speed up your Ruby application, at least not easily.
Furthermore, Java has the issues that it's only fast when memory is plentiful and it has a long startup/running time, it's "eventually fast" if you will.
Although there's JNR and JNA and it might become a standard feature at some point in the future[0]. But for a good FFI experience you also need arrays-of-structs, which means you need value types in java. So it's a long journey to get there.
This resonates well with me. I came from PHP and I decided to learn C in order to contribute to an existing PHP extension. I was doing well following a C tutorial. Until I arrived at string manipulation at which point I said, f* this sh.
So looked for an alternative systems programming language to learn, and found Rust. And its a pleasant language to work on. Its a low level language that feels like a high level language.
My only fear is that, if Rust becomes a popular language, the community will end up as toxic as the JS and PHP community. Right now, the Rust community is filled with the smartest and friendliest devs I know of among open source communities, and I kinda like it to stay that way.
I have yet to find a community that has gotten popular and hasn't turned into a sewage plant. I think it's just a reflection on what the general population is like... :(
Emily Dunham of Mozilla has a talk about this Community Automation: https://www.youtube.com/watch?v=dIageYT0Vgg
Name a large programming community that is pleasant to interact with for newcomers and insiders alike.
It's a level of purposeful design that only the .NET and Go ecosystems approach, and because it's unusual and largely unobtrusive, it's not obvious that this really good, highly productive community is not at all accidental.
I would say that most large programming communities split into multiple communities, so different kinds of folks don't interact as much: the people on the core developer mailing lists are mostly not the same people as on IRC, or on user mailing lists, or working on issues for 3rd party frameworks in GitHub. I can't think of a sub-community that I've had experience with that I would characterize as unpleasant.
I'd love to read tutorials or books that assume Rust is someone's first programming language, period. What would that look like?
There isn't any good "first programming language" material using Rust yet, IMHO.
This is a must for me. I often give up on compiled languages because libfoobar isn't yet available on the language and I have no interest in writing (and maintaining) language bindings for third party libraries I use.
My dream is that one day I'll be able to do something like:
Foobar = link_cimport({"headers": ["foobar.h"], "packages": [ "foobar" ], "prefix": "foobar_"});
Foobar.do_something(); // would call foobar_do_something();
Foobar.hidden_function(); // would call hidden_function();
Foobar = loadable_cimport({"headers": ["foobar.h"]});
foo = Foobar.load("/path/to/foo.so");
bar = Foobar.load("/path/to/bar.so");
It converts C headers to a Rust module containing the relevant type/function/etc. definitions. On stable you need to either pregenerate the module (not too bad if you're pinning particular versions of libraries anyway) or add a build script to autogenerate it. On nightly, there's also a compiler plugin that does all the work for you, and looks not-too-dissimilar to what you wanted. The only thing it lacks is the prefix removal stuff.
As far as I am aware, the Rust compiler has not been proved correct. So whether or not your code is correct still depends on the correctness of the compiler. Of course this is probably correct, but still not 100% guaranteed.
Edit: Relevant discussion - https://github.com/rust-lang/rust/issues/9883
If there were as many blown off feet as comments on HN suggested technology even as it currently is simply wouldn't function.
Do you even understand how much mission and safety critical software is written in C? I think if you did you'd either have a constant panic attack (given your apparent belief that it's impossible to write "safe" C) or else have to adjust your world view a little bit.
(I still agree that results at that point will be more interesting then speculating today.)
I don't think you get to play on both sides of that fence. Some of your team has been working on Rust for that long, but I doubt any code with sigils compiles, and I doubt there were many large projects using it then. I started my stopwatch at May 2015.
> Ten years is not that long a time.
Totally agree.
> I still agree that results at that point will be more interesting then speculating today.
We'll see on May 2025. :-)
My response was to a commenter who, as far as I can tell, represents the mainstream Rust community's view: that it's impossible to write safe C or, worse, that infallibility is a reasonable standard to apply. The latter is especially vex-some from my point of view, because Rust is not infallible, I happen to find it (so far) much more pleasurable to use than either C or C++, and I would very much like to see it have broader adoption.
Rust is a great language, but people have to stop "marketing" it by saying things like: no matter how great you are with C, you're going to fuck up at some point, so that's why you should be using Rust. Like Go or whatever other language, the main grab needs to be a positive: you know what you're doing, and here's how (a, b, c... etc.) Rust will make you even better at what you do.
Another point, it's safe to say C isn't going away anytime soon, it sits nicely at the next approximately natural level (in abstraction) above assembly. That was a design point in the language. Yes it can be a rough tool to use, but that's a reality when you get closer to the metal. You get tremendous flexibility and that comes at a price, as all things do.
To me, modern tools like Rust are supposed to relieve part of the burden. In the common case, if I can be reasonably certain that I can't make certain classes of errors, my brainpower is freed to focus on other things and I can work with significatly less stress.
Rust is interesting because it allows you worry less without actually compromising much in capability. In the cases where I would need to be able to bypass the tooling, it is explicitly possible.
The tooling seems nice, but far from unique (D, Go and other languages are quite competitive there). It would be far more interesting to hear more about, say, traits (can it compete with C++ in compile time polymorphism?) and other technical aspects that make Rust stand apart from its competitors.
Seriously. However, I've seen a lot of comments to that effect from C and C++ programmers who don't want memory safety.
I come at it from a different angle: I'm a Java developer, so I already have memory safety. Pointer arithmetic, dangling pointers, and buffer overflows are not allowed, there is a garbage collector, and so on. In fact, most of the currently popular languages other than C and C++ are memory safe in similar ways. So, in terms of memory safety, Rust does not give me anything critical that I don't already have.
When choosing among the memory-safe languages for a real-world project, I'm going to need a pretty compelling reason to choose Rust instead of Java, Scala, Go, Ruby, Python, etc. -- especially when it is so much easier to hire developers for more popular languages.
I'll take a shot at some of the advantages:
Algebraic datatypes: Seriously. These are amazing. C++ has them with Boost's variant (and now std::variant), but they're awkward to use, making them somewhat a niche instead of the very central place they take in Rust programming. Till now ADTs were mostly the domain of functional languages, so I'm very happy that Swift and Rust giving them first class support and making them essential.
ADTs in Rust work with the enum keyword:
enum Shape {
Rectangle(Point, Point),
Circle(Point, u32)
}
let some_shape = Circle(Point::new(1, 2), 5);
match some_shape { // like switch, but with pattern matching
Rectangle(p1, p2) => println!("Rect from {} to {}", p1, p2),
Circle(p, radius) => println!("Circle at {} with radius {}", p, r)
}
Traits: I mention this elsewhere in the thread, but Rust metaprogramming via generics cannot and will never beat C++ TMP's level of expressivity. Rust is going to get procedural macros which make it easier to fill in that gap of metaprogramming in a less hacky way, but if you just compare generics and templates then templates can do a lot more. However, that's not necessarily a good thing. The way templates are structured; they basically get "monomorphized" at something akin to parse time. This means that the error messages can be atrocious, and an API can never be self-documenting since you have to explain what kinds of types can be passed in. On the other hand, in Rust, if you get a function from a library you can pretend that it's a black box. The error messages will never mention the contents of the box. You can adequately figure out how to not make the compiler error out by looking at the type signature. The way Rust traits work is that you first define them:
trait Frob {
fn frob(&self, frobbee: &str);
}
impl Frob for SomeType {
fn from(&self, frobbee: &str) { println!("{} frobs {}", self, frobbee) }
}
fn frob_something_10x<T: Frob>(frobber: T, frobbee: &str) {
for _ in 1..10 {
frobber.frob(frobbee)
}
}
Moving: I personally find the lack of copy/move constructors and default construction to be very nice. In Rust, uninitialized types aren't a thing; initialization is always explicit. Copies are just copies, moves are also just copies, and moving is the default (except for POD types). There's no unknown overhead to deal with when I push to a vector, for example. Move-by-default and affine types IMO make it very easy to think about the program.
On first glance, I can see some utility in the ADT matching, but not necessarily something I miss in C++ (std::variant + templates gets me most of the way, although there are some issues with that approach). On the other hand, the clean separation of concerns and clear syntax of the traits example looks very useful indeed, and quite tempting.
I am also extremely fond of pattern matching and algebraic data types (first class tagged unions). It is a style of data modeling borrowed from ML/Haskell and is quite distinct from OOP. The key distinction is that by making a datatype with multiple variants closed to extension, you can clearly see and handle all possible cases for a particular purpose (with checking from the compiler) which is often more natural then having fragments of implementation across many child classes.
Safety is a cool feature, but Rust is more than just safety, and pitching it as 'rust is safe' when it's not (and, often, it's not...) and when people dont care about that, doesn't convince people.
There are a lot of people who blog about rust, and almost invariably the 'killer feature' they come up with is safety.
It's not the killer feature; it's the side effect of strong memory management without a GC on an excellent general purpose programming language.
We could certainly do with more posts about how great and practical rust is, what the state of rust tooling is, and what great rust libraries there are with no mention at all of safety.
(... because safety is a cool technical feature; but the others; tooling, libraries and productivity are active barriers to adoption)
If you have to know a lot about Rust to find out why you're using it in the first place, you certainly do have a chicken-or-the-egg problem. And, if the promotion doesn't leave you with a clear idea of why you might want to use Rust, that promotion couldn't have been very successful.
In any case, it's true that one shouldn't attempt to make an opinion about a technology without first being well informed with that technology, and that requires spending time with it to determine the validity of one's own hypothesis about it. Speaking down about it without having tried it is rather offensive to those who have spent the time to learn it.
Rust is strongly about memory and thread safety, which is a major plus. I don't see how that would cause it to be ignored by large swathes of developers when, in fact, that's what is causing large swathes of developers to make the transition. Even long time C houses like GNOME and Red Hat are calling out to stop writing future software in C, and to instead use Rust. GNOME's put their money where their mouth is and they are beginning to migrate their C codebases to Rust. librsvg, for example, is now written fully in Rust.
Rust's safeness allows me to feel comfortable working with really heavy optimizations that make extensive use of fat pointers everywhere to mitigate memory costs and keep everything on the stack. I can feel confident that if my solution compiles, it works. That Rust features test-driven development built into the language by merely adding a #[test] line above a test function to ensure that my logic is correct is even more comforting.
Yet there are many more arguments to make for Rust besides the memory safety. The memory safety is a side effect of the type system. The type system allows for more kinds of safety than just memory safety alone. It allows for compile-time checking of state machines, eliminating a large number of runtime checks at compile-time when you know how to take advantage of it.
Graphics APIs like OpenGL and Vulkan, for example, exhibit much cleaner APIs without the need for performing runtime checks to ensure that instructions are called in the right order, enabling faster execution out of the box.
Basically, taking a state by self will drop the original state, whereby you can return a new state in its place. Code completion will additionally aid the developer in only displaying methods that the current state supports. You can find examples in the hyper and vulkano crates.
In addition, Rust is heavy on the concept of data-oriented programming via protocol-oriented programming: traits featuring ad-hoc polymorphism akin to the likes of Haskell. This encourages more efficient programming practices than the object-oriented approach found in higher level languages like C++. Traits allow for a powerful form of generics whereby you can specify a range of input/output type parameters for all types that support the included traits.
The Iterator trait is by far one of my favorite features of Rust, and it is available without the standard library where it is absolutely vital. Basically, by implementing the Iterator trait for a type, which entails merely implementing the Iterator's next method, you gain access to all of the Iterator's adapters, which opens the door to all of Haskell's best features -- lazy functional programming, but without requiring a garbage collector and without using the heap. It boils down to very efficient machine code compared to if you had written it using a loop.
The sum types and pattern matching is also one of my favorite features of Rust. It's also key in the creation of powerful custom Iterators that may return multiple possible outputs, and it's one of the best parts of Rust's error handling strategy.
If a function may or may not return a value, then the return type is an Option which may either by Some(value) or None. Iterators return Options. If a function has a possibility of an error, then the return parameter is a Result which defines either Ok(value) or Err(error).
Enums may have their own parameters too, so pattern checking can become quite comprehensive to cover every possible result, which may have completely differing input parameters. One enum field could return an &str, another could return a usize, another could return an &str and a usize, and they can contain other enums with their own fields as well.
match result {
Ok(Token::Argument(string) => (),
Ok(Token::Placeholder => (),
Err(TokenErr::IO(why)) => (),
Err(TokenErr::NoArguments) => (),
_ => (),
This then allows concepts like CoW smart pointers to be represented as an Cow::{Borrowed, Owned} enum in the standard library.
Anyway, language features aside, of which there's many more important features that Rust has to offer that'd take too long to explain, there's also the tooling that makes Rust powerful.
The rustup toolchain is one of my favorite things about installing and managing Rust on a system. It's trivial to install, and yet makes installation and updating stupid simple, regardless of your platform. I can easily tell others how to compile my software without them having to know anything about Rust or finding packages in a software repository.
rustup toolchain install nightly
rustup update (updates all toolchains)
rustup target add x86_64-unknown-linux-musl
rustup target add x86_64-pc-windows-gnu
rustup component add rust-docs
rustup component add rust-src
rustup run nightly cargo install racer
rustup run nightly cargo install clippy
cargo build --release --target x86_64-unknown-linux-musl
cargo build --release --target x86_64-pc-windows-gnu
rustup docs (opens offline version of Rust documentation website)
All from the same box. Cross-platform development made easy.
Then there's the powerful capabilities that cargo provides itself. It has a plethora of built-in subcommands, and exports a public API so that you may create and distribute additional subcommands. It automatically creates project hierarchies for you, even initializing git for you.
The Cargo.toml file allows you to define conditional compilation features for your project and libraries that you are importing. It allows you to define what dependencies that you want to pull and from where you want to pull them. Merely specifying a dependency name with a version number will have Cargo search Crates.io for the corresponding library and compile it when you build your project.
For binary projects, a Cargo.lock is provided which notes the exact version and hash of each library that you built to ensure that others that build your software will build it with the exact version libraries that you did when you released it. You only need concern yourself with dependencies on user systems when importing C libraries. If you build on Linux with the MUSL target, you can even build fully static binaries with zero dependencies, so long as you either don't use any C libraries, or build those libraries with MUSL.
Subcommands may even use their own tables in the Cargo.toml file to specify extra behavior, such as my cargo deb subcommand, which requires a few more fields to package Rust projects into Debian binary archives. Cargo provides many interesting subcommands, such as:
cargo build
cargo install
cargo run
cargo check
cargo update
cargo publish
cargo search
cargo doc
cargo edit
cargo test
cargo bench
cargo flame
cargo profile
cargo watch
cargo deb
cargo rpm
and probably more that I'm not yet aware of..
There's much to be said of Rust's community and documentation as well. Never before has a language had such comprehensive and ambitious effort as Rust into establishing an official community with a wide range of community resources. There's an official Rust Docs team that's continuing to add more documentation and examples for Rust and top crates in the Rust ecosystem; then there's a team dedicated to authoring official markdown-based books to teach Rust as the go-to free, printable book for Rust; there's an official Reddit thread, an internals discourse forum, a users forum, multiple IRC channels, and apparently quite a number of key developers browse through and comment on this domain as well.
That is how we end up with the miserably insecure state of affairs of today :)
Avoiding security related issues based on a whole class of problems prevented in Rust by design is a huge benefit. It's better for compiler to prevent that, than to rely on levels of experience, while anyone can make a mistake in reality.
That's not saying that borrow checker is worthless but it does add overhead and frankly in a lot of scenarios that's just not necessary, even with all that fancy compile time checking you still need to do testing and there are many applications where "working for the stuff tested" is enough. Obviously when you're writing a browser that people will try to exploit and you need to execute third party code and load content from entrusted sources things will be different.
So I get where OP is coming from, Rust safety is oversold IMO - it's nice but it's not the only thing that's interesting about Rust - just the fact that it has modules, an official build system and a package manager that's used by everyone is enough for me to consider it over C++. It's lacking IDE like tooling and meta-programming capabilities (in stable at least)
It's important to emphasize out that this is compile time overhead, not run-time overhead.
For example, consider a simple thread-local counter. In C this would be e.g. an object in the tdata section, accessible via thread-local addressing. But in Rust, you have to use something like RefCell, which requires runtime tracking of mutable borrows. So Rust's borrow checker inflicts runtime overhead in this case.
Now, to be fair, this is only one example and I'm sure you could come up with a better one. But this isn't especially controversial. Rust's entire standard library is living proof that you need unsafe to do some things efficiently. The value proposition is that such things can be bundled up behind an abstraction barrier.
In sum, I think "the borrow checker forces runtime overhead" is an incomplete picture. I think a better picture is, "if you completely ban explicit use of unsafe from your code, then you may miss out on some optimization opportunities." i.e., When the borrow checker fails you, you're given a choice: 1) accept safety and the possible performance loss or 2) accept the onus of proving safety and do the fastest thing possible.
I think the fact that those choices are available is an excellent thing. I choose (1) all the time because not every line of code is relevant to performance. But sometimes I get to choose (2), and I'm thankful that such a choice is always very explicit.
For good measure, here's the unsafe version without atomics: https://is.gd/V1K6nD
(It's a hack that plays on the GP's specific example of a counter. It doesn't generalize arbitrarily to removing use of RefCell for thread locals in safe code.)
Edit: Zero overhead as compared to C, that is. Cell has a slight overhead in Rust because it prevents certain optimizations that aren't the default in C.
I've been programming in Rust and C++ codebases for a while now. In general I find that Rust lets you dance close to the line of unsafety without worrying, resorting to Arc/RefCell only when you have to. In contrast, most C++ codebases I have worked with make use of shared_ptr (or its equivalent) quite often, because the language doesn't give you the tools to thread scoped borrows safely through a chain of functions and have it stay safe in the face of future code changes.
I've also encountered severe flaws in libraries written by experienced programmers working for companies like Google and Red Hat that the Rust compiler caught during translation to Rust.
That's not counting the immense amount of tooling and features that make managing large projects a breeze in Rust. Managing a 100K Rust project with a large team is easier than managing a 100K C++ project with a large team. You can't guarantee that no one will ever make mistakes.
I find segmentation faults to be common place in C/C++ projects from experienced developers, and it's quite difficult to debug them at times.
According to steveklabnik, about 50% of Firefox's critical security bugs were due to memory safety issues (source: <https://www.youtube.com/watch?v=_-fweBvtifA&t=27m20s>)
Presumably you don't think mozilla exclusively hires shitty developers.
VMS had a feature called CLE (Common Language Enviornment) [1] which defined calling conventions for computing primitives (functions, registers, stacks...you get it) independent of any language. You could call bits of code from all sorts of languages like COBAL, FORTRAN, C, and some others I'm not really familiar with. Because the calling conventions were specifically designed for language interopperability in mind, VMS was implemented in several different languages. Different components were coded in whatever language best expressed them. This directly contrasts with Unix, which we all know champions C.
I'm not too familiar with Unix calling convention specifics, but as I understand, it revolves around C and its memory model. I believe this is what gives some languages difficulty "talking" with each other; if a language doesn't have a memory or execution model close to C's, it needs to translate through a FFI (Foreign Function Interface) [2] before exchanging execution routines efficiently.
[1](https://en.wikipedia.org/wiki/OpenVMS#Common_Language_Enviro...)
[2] (https://en.wikipedia.org/wiki/Foreign_function_interface)
Reactions vary.
I believe GNOME was originally envisioned as providing a GNU framework for this kind of functionality (whence the "Object Model Environment" in the original acronym expansion), but I think those particular ambitions have mostly been abandoned.
As a simple example, consider the JSON string
{"a": 36893488147419103232}
>>> import json
>>> >>> json.loads('{"a": 36893488147419103232}')
{'a': 36893488147419103232}
>>> json.loads('{"a": 36893488147419103232}')["a"]
36893488147419103232
json: cannot unmarshal number 36893488147419103232 into Go value of type int64
For bonus points, it's worth pointing out that while the JSON specification itself provides no limits on the size of numbers, it is generally unwise to use JSON numbers that can't be represented as IEEE 64-bit floats because there's a lot of languages that will get that wrong. I can also cause issues by sending large ints out of Python or Go into a language that expects floats to actually be floats, and then lossily decodes them in the process. The JSON spec theoretically doesn't have a problem here but the "real world" JSON spec is quite messy in this area.
My point here is not that these problems can't be solved. They all can be solved, at least on a case-by-case basis (two specific programs communicating with JSON). My point here is A: these problems exist B: these problems generally don't admit of practical generalized solutions (for instance, you'll find "programs must use BigInt libraries and programmers must understand all implications of that to use any JSON parser" isn't going to fly, and that would still be ignoring issues I could go on about for some paragraphs) and C: these issues are belligerent and numerous.
This is one minor issue in a corner of the JSON spec between two languages I happened to pick. This is not the exhaustive listing of such issues, this is merely one of thousands of examples you could construct between Python and Go alone. (In fact, it isn't even necessarily a mismatch between "the two languages" so much as "the two languages and the particular JSON parsing library", which means it's even worse than it sounds; I could rotate JSON libraries in either language and potentially get other issues!) Here's another thing that isn't really an issue so much as a meta-issue between all sorts of language pairings: How do you pass a value across different memory recovery types? That is, how do you pass a value from a GC'ed language and back to a non-GC-ed language? Bearing in mind that "GC'ed language" and "non-GC'ed" language are both themselves categories, and the details of both of those things matter a lot. Python and Go are both garbage collected, but you still can't pass values back and forth between them even if you jam them both into the same OS process!
You die the death of a thousand cuts trying to fix these issues between even two languages, then it gets worse if you try to pull more into the fold.
So what you end up with in practice is a protocol that is set at the OS level, writes into stone a whole lot of semantics that deeply, deeply affect the sort of code that can use them, and then those semantics bend the design of every language written on top of them. Right now, on Linux that language is C, Windows has C++ and a .Net runtime, and other people can pipe up with the base language of other OSes. So Linux has a ton of languages that, for all their glory and features and libraries, are ultimately just C with really, really pretty wrappers: Python, Perl, Lua, PHP, etc. Then these languages can communicate on the "C bus". The biggest exception I know of is Java, which is biggest runtime that become its own ecosystem without having an OS to go with it, so you get languages that are ultimately just Java (or JVM if you prefer) with really, really pretty wrappers: Scala, Groovy, Clojure, etc. This is the only solution that I'd say has every achieved any sort of scale, but you still get islands between the languages, the .Net island, the C island, the Java island, a lot of little islands from languages that have their own runtimes which are really cool but can't be expressed on "the C bus" very well, etc.
Personally I think one of UNIX's major problems right now is managing to escape from the "C bus". Back on the original topic, Rust is one of the most interesting stories I've seen in a while there; it can operate on that bus and even provide functionality, while using its type system to escape from the fundamental weaknesses that being on the "C bus" usually entails with memory unsafety, use of dangerous pointer semantics, etc. I think there's a distinct possibility Rust may be able to "bootstrap" us out of there in a way no other language has yet managed to.
Combining languages is likely to circumnavigate those prohibitions, defeating the purposes of the thrown-together languages. Your polyglot tower of babel is likely to fail.
See https://news.ycombinator.com/item?id=11830958.
-----
Now I'd love to see a deep Rust<->Haskell bridge. But getting this right by not breaking the interesting invariants of either langauge is research-level work.
Also, some things are just easier to write in an imperative language. I expect that the performance and memory use of Rust programs is also easier to predict and understand, though generally I think Haskell gets a lot of unfair criticism in that department.
I haven't used Haskell in a while so some of the things I mentioned may have been improved upon since then. In particular, Stack may have grown up a bit.
I know you left out performance, but it's very nice to have code that can be easily profiled.
A stand-out difference is that Rust put a lot of work into the borrow checker. But if a borrow checker is irrelevant (i.e. GC is fast/small enough), there isn't a huge reason.
(To be clear, there are a number of differences, e.g. strict vs. lazy evaluation, but whether one is better than another is debatable.)
https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-...
https://github.com/Microsoft/GSL
I watched his talk -- wondering if anyone is using it. https://www.youtube.com/watch?v=1OEu9C51K2A
Using GSL gives adds some safety to pointers and memory allocation -- while providing the bare-metal performance that C is known for. (It still feels very low-level.)
I have a fully static binary that includes futures, nix, tokio, uuid, and more. Even statically compiled with Muslims it's less than three megs.
And if I didn't use the nix package for a setsockopt call, it would be perfectly capable of running on Windows (and I could easily make it cross platform if I wanted to invest the effort in adding Windows support). Further, there are an abundance of great resources out there for extremely painless cross compilation.
So far I've not heard of problems with multiplat or bloat so I'm hoping you'll elaborate.
See https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...
Rust statically links to libstd by default because it's not there as a dynamic lib on most platforms. On top of that, it links in jemalloc. This makes small Rust binaries look larger than they need to be. The overhead dwindles as you start looking at larger Rust programs. If you actually need to get rid of that overhead, the option is there, it's just not default.
Addition to popular package managers is being worked on.
That laughably hashing functions are highly specialized implementations for a proposed problem. There is NO MORAL there.
I code C for living and if we can use "laughably hashing functions" to gain performance we WILL DO.
This comment breaks the HN guidelines by being uncivil. Please express your point substantively. If someone else is wrong, show them (and the rest of us readers) how. Then we all learn something. Also, please don't use uppercase for emphasis—that's in the site guidelines too.
https://news.ycombinator.com/newsguidelines.html
We detached this comment from https://news.ycombinator.com/item?id=13269145 and marked it off-topic.